(57)【特許請求の範囲】
【請求項１】
１以上のコンピュータを含むコンピュータ・システム上で１以上の記憶媒体を含む階層化ストレージを管理するファイルシステムのバックアップ方法であって、前記１以上の記憶媒体は、それぞれ、インデックスから分離され、かつ、更新された情報が追記保管されるデータ部を含み、前記ファイルシステム内の複数のデータは、それぞれ、前記１以上の記憶媒体の少なくともいずれかに移行されるよう管理されており、
前記バックアップ方法は、前記コンピュータ・システムが、
前記ファイルシステム内の移行された前記複数のデータのメタデータをバックアップするステップと、
前記メタデータと略同時点に、前記複数のデータが移行された前記１以上の記憶媒体各々の前記インデックスをバックアップするステップと
を含み、前記メタデータおよび前記インデックスのバックアップされたデータは、前記１以上の記憶媒体と共にリストア時に用いられる、バックアップ方法。
【請求項２】
前記コンピュータ・システムが、
前記メタデータおよび前記インデックスをバックアップした後、前記階層化ストレージの前記ファイルシステムの運用を再開するステップ
をさらに含む、請求項１に記載のバックアップ方法。
【請求項３】
前記１以上の記憶媒体各々の前記インデックスが、前記階層化ストレージの管理記憶領域に記憶されており、
前記インデックスをバックアップするステップは、前記インデックスのバックアップされたデータとして、前記管理記憶領域に記憶されたバックアップ時点の各インデックスを複製するステップである、請求項１または２に記載のバックアップ方法。
【請求項４】
前記１以上の記憶媒体各々の前記インデックスが、前記１以上の記憶媒体各々が含む前記データ部上に追記されており、
前記インデックスをバックアップするステップは、前記インデックスのバックアップされたデータとして、前記データ部上に追記されたバックアップ時点の各インデックスを特定する特定情報を記憶するステップである、請求項１または２に記載のバックアップ方法。
【請求項５】
前記コンピュータ・システムが、
前記ファイルシステムへデータが追加され、または前記ファイルシステム内のデータが変更された場合に、該データの移行先である記憶媒体のデータ部に該データを追記するとともに、該データの移行先である記憶媒体のインデックスに、該データのデータ部上の位置情報を書き込むステップと、
前記ファイルシステム内のデータが削除された場合に、該データの移行先であった記憶媒体のインデックスから、該データのデータ部上の位置情報を消去するステップと
をさらに含む、請求項１〜４のいずれか１項に記載のバックアップ方法。
【請求項６】
前記１以上の記憶媒体は、１以上のテープであり、前記階層化ストレージは、前記１以上のテープの上位に、１以上のオンラインストレージ、１以上のニアラインストレージ、またはこれらの組み合わせを含む、請求項１〜５のいずれか１項に記載のバックアップ方法。
【請求項７】
前記ファイルシステムの前記メタデータは、データが移行された記憶媒体を識別する媒体識別情報を属性情報として含み、前記記憶媒体の前記インデックスは、移行されたデータのデータ部上の位置情報を属性情報として含む、請求項１〜６のいずれか１項に記載のバックアップ方法。
【請求項８】
１以上のコンピュータを含むコンピュータ・システム上で１以上の記憶媒体を含む階層化ストレージを管理するファイルシステムのリストア方法であって、前記１以上の記憶媒体は、それぞれ、インデックスから分離され、かつ、更新された情報が追記保管されるデータ部を含み、
前記リストア方法は、前記コンピュータ・システムが、
前記ファイルシステム内の複数のデータのメタデータを、バックアップされたデータからリストアするステップであって、リストアされた前記メタデータにおいて前記複数のデータを前記１以上の記憶媒体の少なくともいずれかへ本移行された状態に設定する、ステップと、
前記１以上の記憶媒体各々のインデックスを、前記メタデータと略同時点にバックアップされたデータからリストアするステップと
を含み、前記１以上の記憶媒体は、前記メタデータおよび前記インデックスのバックアップが取得されたものである、リストア方法。
【請求項９】
前記コンピュータ・システムが、
バックアップが取得された前記１以上の記憶媒体のうちの１つをマウントするステップと、
前記マウントがリストア後初回であるか否かを判定するステップと、
初回であると判定された場合に、マウントされた記憶媒体の現存のインデックスを無視して、リストアされたインデックスを用いるように構成するステップと
をさらに含む、請求項８に記載のリストア方法。
【請求項１０】
前記コンピュータ・システムが、
マウントされた記憶媒体への書き込み時、またはマウントされた記憶媒体のアンマウント時に、該記憶媒体が含むインデックス部を、リストア後の最新のインデックスで上書きするステップ
をさらに含む、請求項９に記載のリストア方法。
【請求項１１】
前記インデックスのバックアップされたデータは、前記１以上の記憶媒体各々のバックアップ時点の各インデックスを含み、
前記インデックスをリストアするステップでは、前記バックアップに含まれる各インデックスが、前記階層化ストレージの管理記憶領域上に複製されるか、または、前記階層化ストレージの管理記憶領域上のインデックスとして組み込まれる、請求項８〜１０のいずれか１項に記載のリストア方法。
【請求項１２】
前記インデックスのバックアップされたデータは、前記１以上の記憶媒体各々のデータ部上に追記されたバックアップ時点の各インデックスを特定する特定情報を含み、
前記インデックスをリストアするステップでは、前記バックアップに含まれる特定情報に基づいて特定されるデータ部上の各インデックスが、前記階層化ストレージの管理記憶領域上に複製される、請求項８〜１０のいずれか１項に記載のリストア方法。
【請求項１３】
前記コンピュータ・システムが、
前記ファイルシステム内の所定のデータへのアクセス要求を受領するステップと、
前記所定のデータのリストアされた前記メタデータから、該所定のデータが本移行された記憶媒体を特定するステップと、
前記所定のデータが本移行された記憶媒体のリストアされた前記インデックスから、該記憶媒体のデータ部上の該所定のデータの位置情報を取得するステップと、
該記憶媒体のデータ部上の該所定のデータにアクセスするステップと
をさらに含む、請求項８〜１２のいずれか１項に記載のリストア方法。
【請求項１４】
前記１以上の記憶媒体の少なくともいずれかへ本移行された状態は、前記１以上の記憶媒体の少なくともいずれかに存在するが、前記階層化ストレージを構成する他の上位の記憶媒体のいずれにも存在しない状態である、請求項８〜１３のいずれか１項に記載のリストア方法。
【請求項１５】
階層化ストレージを構成し、それぞれインデックスから分離され、かつ、更新された情報が追記保管されるデータ部を含む１以上の記憶媒体のうちの少なくとも１つをロードする１以上の記憶ドライブ装置と、
前記階層化ストレージを管理するファイルシステムであって、当該ファイルシステム内の複数のデータがそれぞれ前記１以上の記憶媒体の少なくともいずれかに移行されるように管理する、当該ファイルシステムを稼働させる１以上のコンピュータと、
前記ファイルシステム内の移行された前記複数のデータのメタデータをバックアップするよう制御するとともに、前記メタデータと略同時点に、前記複数のデータが移行された前記１以上の記憶媒体各々のインデックスをバックアップするよう制御する、前記１以上のコンピュータに含まれるかまたは前記１以上のコンピュータとは別に設けられる管理コンピュータと
を含み、前記メタデータおよび前記インデックスのバックアップされたデータは、前記１以上の記憶媒体と共にリストア時に用いられる、ストレージ・システム。
【請求項１６】
前記管理コンピュータは、前記メタデータおよび前記インデックスをバックアップした後、前記階層化ストレージの前記ファイルシステムの運用が再開されるように制御する、請求項１５に記載のストレージ・システム。
【請求項１７】
階層化ストレージを構成し、それぞれインデックスから分離され、かつ、更新された情報が追記保管されるデータ部を含む１以上の記憶媒体のうちの少なくとも１つをロードする１以上の記憶ドライブ装置と、
前記階層化ストレージを管理するファイルシステムを稼働させる１以上のコンピュータと、
前記ファイルシステム内の複数のデータのメタデータを、バックアップされたデータからリストアするよう制御するとともに、前記１以上の記憶媒体各々のインデックスを、前記メタデータと略同時点にバックアップされたデータからリストアするよう制御し、かつ、前記メタデータにおいて前記複数のデータを前記１以上の記憶媒体の少なくともいずれかへ本移行された状態に設定する、前記１以上のコンピュータに含まれるかまたは前記１以上のコンピュータとは別に設けられる管理コンピュータと
を含み、前記１以上の記憶媒体は、前記メタデータおよび前記インデックスのバックアップが取得されたものである、ストレージ・システム。
【請求項１８】
前記管理コンピュータは、バックアップが取得された前記１以上の記憶媒体のうちの１つをマウントした場合であって、該マウントがリストア後初回であると判定された場合に、マウントされた記憶媒体の現存のインデックスを無視して、リストアされたインデックスを用いるように構成する、請求項１７に記載のストレージ・システム。
【請求項１９】
１以上の記憶媒体を含む階層化ストレージを管理するファイルシステムであって、前記１以上の記憶媒体は、それぞれ、インデックスから分離され、かつ、更新された情報を追記保管するデータ部を含み、当該ファイルシステム内の複数のデータは、それぞれ、前記１以上の記憶媒体の少なくともいずれかに移行されるように管理する、当該ファイルシステムのバックアップを管理するための管理コンピュータを機能させるためのプログラムであって、前記管理コンピュータを、
前記ファイルシステム内の移行された前記複数のデータのメタデータをバックアップするよう制御する手段、および、
前記メタデータと略同時点に、前記複数のデータが移行された前記１以上の記憶媒体各々のインデックスをバックアップするよう制御する手段
として機能させるためのプログラムであり、
前記メタデータおよび前記インデックスのバックアップされたデータは、前記１以上の記憶媒体と共にリストア時に用いられる、プログラム。
【請求項２０】
１以上の記憶媒体を含む階層化ストレージを管理するファイルシステムであって、前記１以上の記憶媒体は、それぞれ、インデックスから分離され、かつ、更新された情報が追記保管されるデータ部を含む、当該ファイルシステムのリストアを管理するための管理コンピュータを機能させるためのプログラムであって、前記管理コンピュータを、
前記ファイルシステム内の複数のデータのメタデータを、バックアップされたデータからリストアするよう制御する手段であって、前記メタデータにおいて前記複数のデータを前記１以上の記憶媒体の少なくともいずれかへ本移行された状態に設定するよう制御する手段、および
前記１以上の記憶媒体各々のインデックスを、前記メタデータと略同時点にバックアップされたデータからリストアするよう制御する手段
として機能させるためのプログラムであり、
前記１以上の記憶媒体は、前記メタデータおよび前記インデックスのバックアップが取得されたものである、プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ファイルシステムのバックアップおよびリストアに関し、より詳細には、階層化ストレージのファイルシステムのバックアップ方法、リストア方法、ストレージ・システムおよびプログラムに関する。
【背景技術】
【０００２】
災害などによるデータ消失に対する対応として、データのバックアップおよびその保管が必要不可欠である。実際の災害時は、バックアップデータを利用してリストアを行うことになる。リストアの所要時間は、事業再開時期を大きく左右するものであるため、可能な限り短縮されることが望まれる。しかしながら、近年、ビッグデータと呼ばれるように、取り扱うデータ量は増大する傾向にあり、バックアップデータも膨大なものとなり、リストアの所要時間は長期化する傾向にある。このような、ファイルシステムの迅速な復旧を目的としたバックアップ技術として、例えば、特開２０１３−２５４５１３号公報（特許文献１）が知られている。
【０００３】
また、安価なバックアップメディアとしては、テープメディアがよく用いられる。一般的には、運用時には、ディスク上にデータを保持しつつ、バックアップデータをテープに保存する。災害時には、テープからバックアップデータをすべて読み出して、ディスクからアクセス可能な状態に復旧する方法がとられる。しかしながら、このような方式では、データをすべてのテープから読み出すまで業務を再開できないため、復旧まで非常に時間がかかってしまう。
【０００４】
ファイルシステムのバックアップおよびリストアにおいては、復旧時間を短縮するとともに、バックアップ後もファイルシステムの運用が可能であることが望ましい。また、システムへの負荷を軽減し、移行先となる記憶媒体の利用効率を高めることも望まれる。したがって、復旧時間を短縮することができるとともに、バックアップ後もファイルシステムが運用可能であり、かつ、システムへの負荷が小さく、かつ、移行先となる記憶媒体の使用効率を高めることができる、階層化ストレージのファイルシステムのバックアップおよびリストア技術の開発が望まれていた。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２０１３−２５４５１３号公報
【特許文献２】特表２０１０−５２２９１４号公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本発明は、上記従来技術における不充分な点に鑑みてなされたものであり、本発明は、復旧時間を短縮することができるとともに、バックアップ後もファイルシステムが運用可能であり、かつ、システムへの負荷が小さく、かつ、移行先の記憶媒体の使用効率を高めることができる、バックアップ方法、リストア方法、ストレージ・システムおよびプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００７】
本発明では、上記課題を解決するために、下記特徴を有する、ファイルシステムのバックアップ方法を提供する。本ファイルシステムは、１以上のコンピュータを含むコンピュータ・システム上で構成され、１以上の記憶媒体を含む階層化ストレージを管理する。上記１以上の記憶媒体は、それぞれ、インデックスから分離され、かつ、更新された情報が追記保管されるデータ部を含む。上記ファイルシステム内の複数のデータは、それぞれ、上記１以上の記憶媒体の少なくともいずれかに移行されるよう管理される。
【０００８】
本バックアップ方法では、コンピュータ・システムが、ファイルシステム内の移行された上記複数のデータのメタデータをバックアップするステップと、上記メタデータと略同時点に、上記複数のデータが移行された１以上の記憶媒体各々のインデックスをバックアップするステップとを含む。得られたメタデータおよびインデックスのバックアップされたデータは、上記１以上の記憶媒体と共にリストア時に用いられる。
【０００９】
さらに、本発明では、下記特徴を有した、１以上のコンピュータを含むコンピュータ・システム上で階層化ストレージを管理するファイルシステムのリストア方法を提供することができる。本リストア方法では、メタデータおよびインデックスのバックアップが取得された１以上の記憶媒体が準備される。本リストア方法では、コンピュータ・システムが、ファイルシステム内の複数のデータのメタデータを、バックアップされたデータからリストアするステップであって、リストアされたメタデータにおいて複数のデータを１以上の記憶媒体の少なくともいずれかへ本移行された状態に設定する、ステップと、上記１以上の記憶媒体各々のインデックスを、メタデータと略同時点にバックアップされたデータからリストアするステップとを含む。
【００１０】
さらに、本発明では、下記特徴を有するストレージ・システムを提供することができる。本ストレージ・システムは、階層化ストレージを構成する１以上の記憶媒体のうちの少なくとも１つをロードする１以上の記憶ドライブ装置と、上記階層化ストレージを管理するファイルシステムを稼働させる１以上のコンピュータと、上記１以上のコンピュータに含まれるかまたは別に設けられる管理コンピュータとを含むことができる。
【００１１】
管理コンピュータは、ファイルシステム内の移行された複数のデータのメタデータをバックアップするよう制御するとともに、略同時点に、複数のデータが移行された１以上の記憶媒体各々のインデックスをバックアップするよう制御することができる。あるいは、管理コンピュータは、ファイルシステム内の複数のデータのメタデータを、バックアップされたデータからリストアするよう制御するとともに、１以上の記憶媒体各々のインデックスを、上記メタデータと略同時点にバックアップされたデータからリストアするよう制御し、かつ、上記メタデータにおいて上記複数のデータを本移行された状態に設定することができる。さらに、本発明では、上記バックアップまたはリストアを実行する管理コンピュータを実現するためのプログラムを提供することができる。
【発明の効果】
【００１２】
上記構成により、復旧時間を短縮することができるとともに、バックアップ後もファイルシステムが運用可能であり、かつ、システムへの負荷が小さく、かつ、移行先となる記憶媒体の使用効率を高めることができる。
【図面の簡単な説明】
【００１３】
【図１】本発明の実施形態による階層化ストレージ管理システムの概略構成図。
【図２】本発明の実施形態による階層化ストレージ管理システムのクラスタを構成するノードのハードウェア構成図。
【図３】本発明の実施形態による階層化ストレージ管理システムのソフトウェア構成図。
【図４】ファイルシステムにおけるバックアップ処理およびリストア処理を行う際の課題を説明する図。
【図５】本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理およびリストア処理を担当するバックアップドライバ２３０の詳細な機能ブロック図。
【図６】本発明の実施形態による階層化ストレージのファイルシステムのバックアップ方法を示すフローチャート。
【図７】本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理を説明する図。
【図８】本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理後に引き続き運用を再開した状態を説明する図。
【図９】本発明の実施形態による階層化ストレージのファイルシステムのリストア方法を示すフローチャート。
【図１０】本発明の実施形態による階層化ストレージのファイルシステムのリストア処理を説明する図。
【図１１】本発明の実施形態による階層化ストレージ管理システムで用いることができるテープメディアのフォーマットの模式図。
【図１２】本発明の実施形態による階層化ストレージのファイルシステムにおけるリストア後のファイルアクセス方法を示すフローチャート。
【図１３】本発明の実施形態による階層化ストレージのファイルシステムにおけるファイルアクセス方法を説明する図。
【図１４】書き込み禁止にする他のバックアップ方法およびリストア方法を説明する図。
【図１５】書き込み禁止にしかつリクラメーションを行う他のバックアップ方法およびリストア方法を説明する図。
【発明を実施するための形態】
【００１４】
以下、本発明の実施形態について説明するが、本発明の実施形態は、以下に説明するものに限定されるものではない。なお、説明する実施形態では、階層化ストレージを管理するファイルシステムのバックアップおよびリストアを実現するストレージ・システムとして、階層化ストレージ管理システム１００を一例として説明する。
【００１５】
図１は、本発明の実施形態による階層化ストレージ管理システム１００の概略構成を示す図である。図１に示す階層化ストレージ管理システム１００は、１以上のノード１１２から構成されるクラスタ１１０を含み、階層化ストレージを管理するファイルシステムをクラスタ１１０上で実現する。
【００１６】
階層化ストレージは、図１に示す実施形態では、１以上の共有ディスク１２２を含む共有ディスクアレイ１２０を含み構成される。クラスタ１１０のノード１１２は、それぞれ、共有ディスクアレイ１２０の共有ディスク１２２各々と、ＳＡＮ（Storage Area Network）ファブリック１０２を介して相互に接続される。ＳＡＮファブリック１０２は、特に限定されるものではないが、ファイバチャネル（Fibre Channel）スイッチを含み構成されるファイバチャネル・ネットワークを基盤としたＦＣ−ＳＡＮ、ＬＡＮ（Local Area Network）スイッチを含み構成されるＴＣＰ／ＩＰネットワークを基盤としたＩＰ−ＳＡＮ、またはこれらの組み合わせで構成することができる。
【００１７】
複数のノード１１２は、共有ディスク１２２各々を共有する。ノード１１２は、ＳＡＮファブリック１０２を介して共有ディスク１２２に直接アクセスするとともに、ＳＡＮファブリック１０２に接続されていない他のクライアントノードに対し間接的なファイルアクセスを提供する。このような、クラスタ１１０を構成する１以上のノード１１２に分散され、複数のノード（クライアントノードを含む。）からアクセスが可能なファイルシステムは、分散共有（並列）ファイルシステムと参照される。分散共有ファイルシステムは、グローバルな名前空間を提供し、また、複数のノードをまたがった入出力のストライピング機能や情報ライフサイクルマネジメント（ＩＬＭ）機能などを提供することができる。
【００１８】
分散共有ファイルシステムとしては、説明する実施形態では、ＧＰＦＳ（登録商標）を用いるものとするが、特に限定されるものではなく、ＧＦＳ（Global File System）、ＯＣＦＳ（Oracle（登録商標） Cluster File System）、Ｌｕｓｔｒｅ、ＧｌｕｓｔｅｒＦＳなどの他の分散共有（並列）ファイルシステムを採用することを妨げるものではない。
【００１９】
階層化ストレージは、図１に示す実施形態では、共有ディスクアレイ１２０に加えて、さらに、テープライブラリ１３０を含み構成される。テープライブラリ１３０には、１以上のテープドライブ１３２と、１以上のテープメディア１３４とが含まれる。テープドライブ１３２は、本実施形態における記憶ドライブ装置を構成し、テープメディア１３４は、本実施形態における移行先となる記憶媒体を構成する。クラスタ１１０のノード１１２は、それぞれ、ＳＡＮファブリックを介して、あるいは、ＦＣ、ＬＶＤ（Low Voltage Differential）ＳＣＳＩ（Small Computer System Interface）、ＳＡＳ（Serial Attached SCSI）などのケーブルを介して、テープライブラリ１３０と接続される。
【００２０】
テープライブラリ１３０は、複数のテープドライブ１３２を含むことができ、１または複数のノード１１２から同一のテープメディア１３４のセットにアクセスが可能に構成されている。一方で、テープドライブ１３２は、交互に使うことも可能であるが、典型的には、ある時点で１つのノードに占有され、ノード１１２間で共有されず、テープライブラリ１３０にアクセスするノード１１２は、自身のテープドライブ１３２を有することになる。
【００２１】
テープライブラリ１３０は、ＬＴＦＳ（Liner Tape File System）といったテープライブラリ用のファイルシステムにより管理されるが、上述した分散共有ファイルシステムに統合される。所定のポリシーに従って、共有ディスクアレイ１２０から移行されるファイルが、１以上のテープメディア１３４内に記憶される。分散共有ファイルシステムと、テープライブラリ１３０のファイルシステムとの統合は、特に限定されるものではないが、ＬＴＦＳ  ＥＥ（Linear Tape File System Enterprise Edition）などのパッケージを用いることにより行うことができる。テープメディア１３４は、特に限定されるものではないが、ＬＴＦＳがサポートされたＬＴＯ（Linear Tape-Open）５以降のテープカートリッジを好適に用いることができる。
【００２２】
図１に示す階層化ストレージ管理システム１００は、さらに、管理端末１４０を含み構成される。管理端末１４０は、階層化ストレージ管理システム１００の管理者が操作する端末であり、管理者から、階層ストレージのファイルシステムのバックアップおよびリストアの指示を受け付ける。あるいは、管理端末１４０は、管理者からのバックアップおよびリストアのための事前に取り決める基準またはスケジュールを受け付けることもできる。この場合、所定の基準を満たしたことを契機として、または、スケジュールされたタイミングが到来したことを契機として、自動的にバックアップまたはリストアが開始される。
【００２３】
なお、図１に示す例では、ノード１１２−１〜１１２−Ｍが、共有ディスクアレイ１２０上の共有ディスク１２２−１〜１２２−Ｎと接続され、ノード１１２−１〜１１２−Ｌが、それぞれ、テープライブラリ１３０のテープドライブ１３２−１〜１３２−Ｌと接続されるものと示されている。しかしながら、図１は例示である点に留意されたい。
【００２４】
例えば、共有ディスクアレイ１２０をさらに、１以上のオフラインストレージ（高速ディスク）および１以上のニアラインストレージ（中速ディスク）に分けて３層（tier）構成としたり、フラッシュストレージを追加したりすることができる。また、例えば、１つのノード１１２に複数のテープドライブ１３２が接続されるよう構成してもよい。さらに、例えば、ＬＡＮ（Local Area Network）を介して接続されるクライアントノード、管理端末と通信して専らファイルシステムの管理を行う管理ノードをクラスタ１１０に含めてもよい。
【００２５】
図２は、本発明の実施形態による階層化ストレージ管理システム１００のクラスタ１１０を構成するノード１１２のハードウェア構成を示す図である。図２に示すように、ノード１１２は、シングルコアまたはマルチコアのＣＰＵ（Central Processing Unit）１０と、ＳＤＲＡＭ（Synchronous Dynamic Random Access Memory）などのメモリ１２と、ＲＯＭ（Read Only Memory）やＨＤＤ（Hard Disk Drive）、フラッシュメモリなどの記憶装置１４と、ネットワーク・インタフェース１６と、入出力インタフェース１８とを含み構成される。
【００２６】
ネットワーク・インタフェース１６は、ＮＩＣ（Network Interface Card）などのネットワーク・アダプタとして構成され、ノード１１２をＬＡＮ１０４に接続する。入出力インタフェース１８は、ＮＩＣなどのネットワーク・アダプタ、ＦＣなどのＨＢＡ（ホスト・バス・アダプタ）などとして構成され、ノード１１２をＳＡＮファブリック１０２に接続する。ノード１１２間は、ＩｎｆｉｎｉＢａｎｄ（登録商標）などＨＣＡ（ホスト・チャネル・アダプタ）でインターコネクトしてもよい。
【００２７】
ノード１１２は、ＣＰＵ１０の制御の下、記憶装置１４に格納された各種プログラムを読み出し、メモリ１２に展開することにより、自身が担当する後述する機能および処理を実現する。
【００２８】
なお、管理端末１４０について、特にハードウェア構成を図示しないが、同様に、ＣＰＵ、メモリ、記憶装置、ネットワーク・インタフェースを備え、さらに、ディスプレイ、キーボード、マウスなどのユーザ・インタフェースを備えて構成することができる。共有ディスクアレイ１２０およびテープライブラリ１３０についても、特にハードウェア構成を図示しないが、プロセッサ、メモリ、ＲＯＭ、ネットワーク・インタフェース、入出力インタフェース、その他適切なハードウェアを備えて構成することができる。
【００２９】
図３は、本発明の実施形態による階層化ストレージ管理システム１００のソフトウェア構成図である。図３に示す階層化ストレージ管理システム（以下、単に管理システムと参照する場合がある。）２００は、ソフトウェア構成として、分散共有ファイルシステム２１０と、拡張ファイルシステム２２０と、バックアップドライバ２３０とを含み構成される。
【００３０】
分散共有ファイルシステム２１０は、上述したように、例えばＧＰＦＳ（登録商標）によって提供されるソフトウェア・コンポーネントである。分散共有ファイルシステム２１０は、内部の機能として、ファイルシステムのメタデータ（説明する実施形態においてはｉｎｏｄｅ情報である。）をバックアップおよびリストアするバックアップ／リストア部２１２を含む。バックアップ／リストア部２１２は、ＧＰＦＳ（登録商標）を用いる特定の実施形態では、ＳＯＢＡＲ（Scale Out Backup and Restore）と呼ばれる機能を担当するコンポーネントとして提供される。
【００３１】
拡張ファイルシステム２２０は、分散共有ファイルシステム２１０にテープライブラリ１３０を統合し、拡張するソフトウェア・コンポーネント群を提供する。拡張ファイルシステム２２０は、そのようなコンポーネントとして、階層化ストレージ管理部２２２と、ライブラリ制御部２２４と、テープ用ファイルシステム２２６とを含み構成される。
【００３２】
階層化ストレージ管理部２２２は、所定のポリシーに基づいて、適切なファイルを分散共有ファイルシステム（共有ディスク１２２）からテープライブラリ１３０（テープメディア１３４）へ自動的に移行（マイグレーションと参照される。）する制御を行う。階層化ストレージ管理部２２２は、また、移行されたファイルがアクセスされた際に、そのファイルをテープライブラリ１３０から分散共有ファイルシステムへ自動的に呼び戻す（リコールと参照される。）する制御を行う。
【００３３】
ライブラリ制御部２２４は、テープメディアの選択およびリソースの状態を制御する。ライブラリ制御部２２４は、所定のポリシーに基づいて、テープメディアの選択をして、移行および呼び戻しの要求のスケジュールおよび処理を行う。
【００３４】
テープ用ファイルシステム２２６は、テープライブラリ１３０を１つのファイルシステムとしてテープメディア１３４にマウントすることを可能とする。テープライブラリ１３０内のテープメディア１３４は、典型的には、テープライブラリ内のサブディレクトリとしてアクセスされる。テープ用ファイルシステム２２６は、移行先となるテープドライブに接続されたノード上で稼働し、ＬＴＦＳのファイルシステム・インタフェースを介して、テープメディア１３４上の記録領域にアクセスする。なお、説明する実施形態では、テープライブラリを１つのファイルシステムとしてテープメディア１３４にマウントするものとして説明するが、テープライブラリを構成せず、単一のテープドライブを１つのファイルシステムとしてテープメディアにマウントする態様としてもよい。
【００３５】
ＧＰＦＳ（登録商標）を用いる特定の実施形態では、拡張ファイルシステム２２０は、ＬＴＦＳ  ＥＥと呼ばれるソフトウェア・パッケージにより提供される。その場合に、階層化ストレージ管理部２２２、ライブラリ制御部２２４およびテープ用ファイルシステム２２６は、それぞれ、階層化ストレージ・マネージャ（ＨＳＭ，Hierarchical Storage Manager）、マルチテープ・マネジメント・モジュール（ＭＭＭ，Multi-Tape Management Module）、およびＬＴＦＳ  ＬＥ（Liner Tape File System Library Edition）＋と参照される。
【００３６】
図３に示す分散共有ファイルシステム２１０に、テープライブラリ１３０の拡張ファイルシステム２２０（あるいは、テープ用ファイルシステム２２６）を統合したものが、本実施形態における階層化ストレージを管理するファイルシステムを構成する。この統合により、ディスクおよびテープを統合した１つの名前空間を有するファイルシステムにおいて、ファイルの自動的なテープへの移行、および、ファイルへのアクセス時のテープからの呼び出しなどのファイルスペース・マネジメントが可能となる。
【００３７】
バックアップドライバ２３０は、この統合されたファイルシステムのバックアップおよびリストアを制御する。バックアップドライバ２３０は、管理者からのバックアップ要求およびリストア要求を受け付けると、統合されたファイルシステムのバックアップ処理およびリストア処理を実行する。バックアップドライバ２３０については詳細を後述する。
【００３８】
なお、図３に示すコンポーネントは、クラスタ１１０および管理端末１４０を含む管理システム１００としてのソフトウェア構成を示すものであり、典型的には、管理システム１００を構成する１以上のコンピュータ上に分散実装される。ノード１１２などの各コンピュータ上では、対応するソフトウェア・コンポーネントが協働して動作することとなる。
【００３９】
以下、まず、本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理およびリストア処理について詳細を説明する前に、図４を参照しながら、上述したファイルシステム内のファイル管理構造を概説するとともに、バックアップ処理およびリストア処理を行う際の課題について説明する。
【００４０】
図４には、図１に示したものと同様なシステムであって、運用側のシステムが運用サイト５００として、復旧側のシステムが復旧サイト５２０として示されている。運用サイト５００および復旧サイト５２０は、それぞれ、クラスタ上で動作する分散共有ファイルシステム５０２，５２２と、共有ディスク５０４，５２４と、テープライブラリ５０６，５２６とを含み、略同一の構成となっている。
【００４１】
分散共有ファイルシステム５０２上で、クラスタ上のノードからアクセスできる共有ディスク５０４上のファイル（ディレクトリを含む。）を、テープライブラリ５０６のテープメディア５１２に複製し、ディスクおよびテープの両方にデータが存在する状態を、予備移行（pre-migrated）状態と参照する。時間が経過すると、すぐには読み出す必要がなくなったファイルは、ファイル本体データが共有ディスク５０４から削除されて、テープメディア５１２上のみとなり、分散共有ファイルシステム５０２にはファイルの属性情報を含むメタデータ（ｉｎｏｄｅ情報）が残される。このテープのみにファイル本体データがある状態を、本移行（migrated）状態と参照する。
【００４２】
ファイルのメタデータ（ｉｎｏｄｅ情報）には、サイズ、時刻情報などの基本的なファイル属性情報のほか、ファイル本体のデータが存在するテープを識別の媒体識別情報（テープＩＤ）が保存されている。この媒体識別情報により、ファイルへのアクセス要求に対応して、テープメディア５１２からファイルを読み出すことが可能となる。ＧＰＦＳ（登録商標）は、上述したＳＯＢＡＲと呼ばれる機能により、このｉｎｏｄｅ情報のみをバックアップする機能を備える。
【００４３】
メタデータ（ｉｎｏｄｅ情報）をメディア５１０にバックアップし、運用サイト５００の分散共有ファイルシステム５２２を再現しようとする場合は、まず、運用サイト５００のテープライブラリ５０６のテープメディア５１２と、メディア５１０とを復旧サイト５２０に移動する。そして、復旧サイト５２０において、メディア５１０から各ファイルのメタデータ（ｉｎｏｄｅ情報）をリストアし、各ファイルの状態を本移行（migrated）状態とする。こうすることで、テープ上のファイルデータにアクセスせず、ファイルシステムを再現することができる。
【００４４】
しかしながら、（１）運用サイト５００でメタデータ（inode_v0）のバックアップを取得した後、（２）ファイルが更新されると、（３）共有ディスク５０４上のファイルが更新される（file_v1となる。）とともに、その変更がテープメディア５１２上のファイルに反映されてしまう（file_v1となる。）。そのため、その後、（４）復旧サイト５２０にメディア５１０およびテープメディア５１２を移動するとともに、（５）バックアップしたメタデータをリストアしたとしても、バックアップを取得した時点のメタデータ（inode_v0）が復元されるのに対して、テープ上のファイルは、バックアップ取得後の変更が反映されている（file_v1となる。）という矛盾が生じる。そのため、（６）リストアしたメタデータ（inode_v0）に基づいて、テープメディア５１２からファイルを読み出そうとしても、テープＩＤの変更やファイルの削除により、読み出すことができない場合がある。
【００４５】
このような不整合を避けるために、メタデータのバックアップ後、バックアップを取得したテープを書き込み禁止にすることが考えられる。書き込み禁止にすれば、整合性のとれたファイルシステムを復旧できるが、テープの未使用部分を残して書き込み禁止にすることになるため、テープの容量を効率的に使うことができなくなる。また、テープ上のデータを別のテープに隙間なく詰めて書き換えるリクラメーションを実施し、テープの使用効率を改善することも考えられるが、書き換えには時間がかかる上、システムに負荷がかかる。
【００４６】
そこで、本発明の実施形態による階層化ストレージ管理システム１００は、バックアップした分散共有ファイルシステムのメタデータ、およびテープメディアのフォーマットを利用して、テープ容量を効率的に使いながら、データの書き換えに時間をかけずに、かつ、システムに負荷をかけずに、階層化ストレージのファイルシステムの復旧を図る。特に、テープメディア１３４が、それぞれ、インデックス部と、インデックス部から分離され、かつ、更新された情報が追記保管されるデータ部とを含むという、ファイルシステムのフォーマットの特徴を利用する。
【００４７】
以下、図５〜図１１を参照しながら、本発明の実施形態による階層化ストレージ管理システム１００におけるバックアップ処理およびリストア処理について、より詳細に説明する。
【００４８】
図５は、本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理およびリストア処理を担当するバックアップドライバ２３０の詳細な機能ブロック図である。図５に示すように、バックアップドライバ２３０は、メタデータバックアップ制御部２３２と、インデックスバックアップ制御部２３４と、メタデータリストア制御部２３６と、インデックスリストア制御部２３８とを含む。
【００４９】
図５に示すバックアップドライバ２３０は、クラスタ１１０を構成するノード１１２、クラスタ１１０にＬＡＮ１０４などを介して接続される他の管理ノード、または管理端末１４０上で実現される。バックアップドライバ２３０は、特に限定されるものではないが、例えば、管理者による管理端末１４０の操作に基づくバックアップ要求またはリストア要求を受信し、バックアップ処理またはリストア処理を開始する。あるいは、バックアップドライバ２３０は、管理者により事前に設定された基準が満たされたことを検知して、または、管理者により事前にスケジュールされたタイミングが到来したことを検知して、バックアップ処理またはリストア処理を開始することができる。
【００５０】
メタデータバックアップ制御部２３２は、バックアップが要求された時点で、分散共有ファイルシステム２１０内の移行済みの複数のファイルのメタデータをバックアップするよう制御する。メタデータのバックアップ機能は、例えば、分散共有ファイルシステム２１０のバックアップ／リストア部２１２によって提供される。この場合、メタデータバックアップ制御部２３２は、管理者からのバックアップ要求に対応して、分散共有ファイルシステム２１０のバックアップ／リストア部２１２を呼び出すことができる。
【００５１】
インデックスバックアップ制御部２３４は、上述したメタデータと略同時点に、上記複数のファイルが移行された１以上のテープメディア１３４の各々のインデックス・ファイルをバックアップするよう制御する。テープメディア１３４のインデックスは、本管理システム１００においては、共有ディスクアレイ１２０上の所定の管理記憶領域に記憶されている。インデックスバックアップ制御部２３４は、共有ディスクアレイ１２０上に記憶されたバックアップ時点の各インデックスを複製して、インデックスのバックアップデータを生成する。
【００５２】
なお、バックアップされるファイルは、テープライブラリ１３０に予備移行（pre-migrated）または本移行（migrated）された管理状態にあることが前提となる。つまり、予備移行または本移行状態で管理されたファイルがバックアップ対象となる。あるいは、バックアップ対象としたいファイルを事前に少なくとも予備移行状態にしておく必要がある。
【００５３】
また、メタデータおよびインデックスのバックアップ先メディアは、特に限定されるものではなく、テープメディアやハードディスクなどの磁気メディア、ＣＤ（Compact Disc）、ＤＶＤ、Ｂｌｕ−ｒａｙ（登録商標）などの光学メディア、ＭＯ（Magneto-Optical disk）などの磁気光学メディア、フラッシュメモリやＳＳＤ（Solid State Drive）などの半導体記憶メディアなど、如何なる記憶媒体を用いてもよい。
【００５４】
メタデータリストア制御部２３６は、分散共有ファイルシステム２１０内の複数のファイルのメタデータを、バックアップ先メディアのデータからリストアするよう制御する。メタデータのリストア機能は、例えば、分散共有ファイルシステム２１０のバックアップ／リストア部２１２によって提供される。この場合、メタデータリストア制御部２３６は、管理者からのリストア要求に基づいて、分散共有ファイルシステム２１０のバックアップ／リストア部２１２を呼び出すことができる。メタデータリストア制御部２３６は、さらに、リストアにかかる複数のファイルを、テープメディア１３４へ本移行された状態（migrated）に設定するよう制御する。
【００５５】
インデックスリストア制御部２３８は、１以上のテープメディア１３４各々のインデックスを、上記メタデータと略同時点にバックアップされたバックアップ先メディアのデータからリストアするよう制御する。インデックスは、管理システム１００においては、共有ディスクアレイ１２０上の所定の管理記憶領域で管理されている。インデックスリストア制御部２３８は、バックアップ先メディア内の各インデックスのバックアップを共有ディスクアレイ１２０上の管理記憶領域に複製する。あるいは、バックアップ先メディアが、共有ディスクアレイ１２０に組み込める形で提供される場合は、それを組み込むことにより、複製なしに、管理記憶領域上のインデックスとして用いてもよい。
【００５６】
図６は、本発明の実施形態による階層化ストレージのファイルシステムのバックアップ方法を示すフローチャートである。図７は、本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理を説明する図である。
【００５７】
図７には、運用側のシステムが運用サイト３００として示されている。運用サイト３００は、分散共有ファイルシステム３０２と、共有ディスク３０４と、テープライブラリ３０６とを含む。あるファイル（file-a_v1）を本移行状態または予備移行状態にすると、移行先のテープメディア３１２を識別するテープＩＤがメタデータ（inode-a_v1）に保存される。ＬＴＦＳフォーマットのテープメディア３１２は、インデックス・パーティション（以下、ＩＰと参照する。）と、データ・パーティション（以下、ＤＰと参照する）とにパーティショニングされており、インデックス（Index_v1）は、テープメディア３１２のＩＰに存在する。また、説明する実施形態では、インデックス（Index_v1）は、共有ディスク３０４にも存在する。インデックス（Index_v1）には、テープメディア３１２のＤＰ上のいずれのブロックに上記ファイル（file-a_v1）本体データが保存されているかの情報が書き込まれている。このような状態で、図６に示すバックアップ処理が呼び出されたものとする。
【００５８】
図６に示す処理は、管理者からのバックアップ要求に応答して、ステップＳ１００から開始される。ステップＳ１０１では、バックアップドライバ２３０は、分散共有ファイルシステム３０２をスキャンする。バックアップ要求が到達した時点で、予備移行（pre-migrated）状態または本移行（migrated）状態に既に移行しているファイルがバックアップ対象となる。まず、対象のファイルを確定するために、ファイルシステムのスナップショットを取得する。そして、スナップショットのファイルをスキャンして、バックアップの対象のファイルを確定する。図７に示す例では、例えば、ファイル（file-a_v1）が対象となる。また、ファイル（file-a_v1）が移行されたテープメディア３１２も対象として抽出される。
【００５９】
ステップＳ１０２では、バックアップドライバ２３０は、分散共有ファイルシステム３０２のメタデータ（ｉｎｏｄｅイメージ）のバックアップを取得する。図７では、１つのファイルのメタデータ（inode-a_v1）のみが示されているが、バックアップ／リストア部２１２により、分散共有ファイルシステム３０２内の複数のファイルのメタデータをまとめて圧縮したイメージバックアップを行うことができる。
【００６０】
ステップＳ１０３では、バックアップドライバ２３０は、分散共有ファイルシステム３０２のメタデータと略同時点の共有ディスク３０４上にある各テープメディア３１２のインデックスのバックアップを取得する。図７では、１つのテープメディア３１２のインデックス（Index_v1）のみが示されているが、複数のテープメディアに渡って移行されている場合は、移行先となったすべてのテープメディア各１本につき、共有ディスク３０４にある最新のインデックス１つをバックアップする。
【００６１】
図６に示すフローでは、ステップＳ１０４で終了する。メタデータ（inode-a_v1）およびインデックス（Index_v1）がメディア３１０−１にバックアップされる。なお、バックアップ処理は、１日１回など必要に応じた頻度で行うようスケジュールされていてもよい。メタデータおよびインデックスのバックアップ後、階層化ストレージのファイルシステムの運用が再開される。
【００６２】
図８は、本発明の実施形態による階層化ストレージのファイルシステムのバックアップ処理後に引き続き運用を再開した状態を説明する図である。運用サイト３００では、その後ファイルが更新され（共有ディスク３０４上でfile-a_v2となる。）ると、その更新されたファイルが移行されて（テープメディア３１２上にfile-a_v2が書き込まれる。）、メタデータも更新される（inode-a_v2となる）。更新されたメタデータ（inode-a_v2）は、必要に応じて、その拡張属性のテープＩＤが更新される。
【００６３】
また、新しく書き込まれたファイル（file-a_v2）のテープ上の位置情報が、テープメディア３１２および共有ディスク３０４の両方で、新たなインデックス（Index_v2）に書き換えられる。テープメディア３１２に未使用部分がなくなった場合は、別のテープメディアにファイルデータが書き込まれ、メタデータ（inode-a_v2）には、その拡張属性に新しいテープＩＤが上書きされる。この状態で、再度バックアップ処理が実施されると、メタデータ（inode-a_v2）およびインデックス（Index_v2）がメディア３１０−２にバックアップされる。
【００６４】
図９は、本発明の実施形態による階層化ストレージのファイルシステムのリストア方法を示すフローチャートである。図１０は、本発明の実施形態による階層化ストレージのファイルシステムのリストア処理を説明する図である。
【００６５】
図１０には、運用サイト３００に加えて、復旧側のシステムが復旧サイト３２０として示されている。復旧サイト３２０は、運用サイト３００と同様の構成を有し、分散共有ファイルシステム３２２と、共有ディスク３２４と、テープライブラリ３２６とを含む。復旧サイト３２０でファイルシステムをリストアするため、運用サイト３００からは、（１）テープメディア３１２、（２）復旧したい時点のメタデータ（ｉｎｏｄｅイメージ）および（３）メタデータと略同時にバックアップしたインデックスの３つを復旧サイト３２０へ移動する。なお、図１０では、図８で示すように最新のバックアップが取得された後、さらに、ファイル（file-a）が更新されている。したがって、移動されるテープメディア３１２には、更新されたファイル（file-a_v3）およびインデックス（Index_v3）が含まれている。
【００６６】
図９に示す処理は、管理者からのリストア要求に応答して、ステップＳ２００から開始される。ステップＳ２０１では、バックアップドライバ２３０は、分散共有ファイルシステム３２２のメタデータ（ｉｎｏｄｅ情報）を、バックアップ先メディア３１０−２のバックアップからリストアする。図１０では、１つのファイルのメタデータ（inode-a_v2）のみが示されているが、バックアップ／リストア部２１２により、複数のファイルのメタデータがまとめてリストアされる。
【００６７】
ステップＳ２０２では、バックアップドライバ２３０は、リストアした各ファイルのメタデータにおいて、本移行（migrated）状態に変更する。これは、例えばバックアップ時点で事前移行（pre-migrated）状態であった場合でも、リストア直後は、上位の共有ディスク３２４が空であり、テープメディア３１２上にしかファイル本体データが存在しないため、この状態に整合させるためである。
【００６８】
ステップＳ２０３では、バックアップドライバ２３０は、メタデータと略同時点に取得されたバックアップ先メディア３１０−２内のバックアップから、共有ディスク３２４上の各テープメディア用の管理領域にインデックスをリストアする。図１０では、１つのテープメディア３１２のインデックス（Index_v2）のみが示されているが、複数のテープメディアがある場合は、すべてのテープ１本につき、バックアップされたインデックス１つを共有ディスク３２４上に複製する。ステップＳ２０４では、拡張ファイルシステム２２０を起動し、ステップＳ２０５で本処理を終了する。
【００６９】
復旧はここまでで完了し、必要なファイルを読み出すことが可能となる。
【００７０】
図１０に示す例では、最新のバックアップが取得された後、さらにファイル更新が行われているので、テープメディア３１２上のインデックスは、更新されている（Index_v3となっている。）とともに、更新されたファイル（file-a_v3）がテープメディア３１２のＤＰに追記されている。したがって、共有ディスク３２４上にリストアされたインデックス（Index_v2）と、テープメディア３１２のＩＰ上のインデックス（Index_v3）とは一致しない。
【００７１】
そこで、本実施形態による階層化ストレージ管理システム１００では、リストアした後の初回テープメディアのマウント時は、テープメディアのＩＰ上のインデックス・ファイル（Index_v3）を無視して、リストアされた共有ディスク３２４上のインデックス（Index_v2）を用いてマウントするよう構成されている。リストアされたインデックス（Index_v2）には、ファイル（file-a）のバックアップ時点のファイル本体データ（file-a_v2）のＤＰ上の位置情報が存在する。また、テープメディア３１２のＤＰには、最新のファイル（file-a_v3）が追記される形で書き込まれるので、バックアップ時点のファイル（file-a_v2）も存在する。したがって、リストアされたインデックス（Index_v2）を用いて、バックアップ時点のファイル（file-a_v2）にアクセスすることが可能となる。
【００７２】
図１１は、本発明の実施形態による階層化ストレージ管理システムで用いることができるテープメディアのフォーマットを模式的に示す図である。図１１に示すように、ＬＴＦＳフォーマットでは、ファイルデータ（ユーザデータ）は、テープメディアのＤＰ上に保存される。データが書き込まれたＤＰ内のブロック番号（位置情報）が、テープメディアのＩＰにあるインデックス・ファイルに書き込まれる。したがって、インデックス・ファイルを用いてファイルデータの書かれたブロックを特定し、ファイルを読み出すことが可能となる。
【００７３】
ファイル更新された場合は、ファイルの移行先であるテープメディア（未使用容量が無いなど従前とは異なるテープメディアの場合もある。）のＤＰにファイルが追記されるとともに、移行先のテープメディアのインデックスにおいては、そのファイルの古い位置情報が消去され、新しい位置情報が書き込まれて、ＩＰ上のインデックス・ファイルが最新のものに置き換えられる。新規ファイルが追加された場合は、移行先となるテープメディアのＤＰにファイルが追記されるとともに、そのインデックスにおいては、位置情報が書き込まれて、ＩＰのインデックス・ファイルが最新のものに置き換えられる。ファイルが削除された場合は、移行先であったテープメディアのインデックスにおいて、そのファイルの古い位置情報が消去され、ＩＰのインデックス・ファイルが最新のものに置き換えられる。ロールバック機能が有効とされる場合、インデックス・ファイルは、ＤＰにも保存されており、ＤＰの従前のインデックスは、消されずに残り、最新のインデックスがデータの最後に追記される。
【００７４】
なお、上述した実施形態では、共有ディスク上のテープメディアのインデックスをバックアップ先メディアに複製するものとして説明した。しかしながら、他の実施形態では、ロールバック機能が有効であれば、ファイル移行先のテープメディアのインデックスは、ＤＰにも各時点で追記される。そのため、テープメディアのインデックス本体に代えて、バックアップ時点のインデックスが書き込まれているＤＰ上のブロック番号やインデックスの世代番号のようなインデックスを特定する特定情報を、バックアップ先メディアに記憶してもよい。ただし、その場合、インデックスをリストアする際には、ＤＰ上のインデックスを読み出す必要がある。この観点からは、好ましくは、インデックスを複製する実施形態が好ましいといえる。
【００７５】
以下、図１２および図１３を参照しながら、リストア後のファイルアクセスについて説明する。図１２は、本発明の実施形態による階層化ストレージのファイルシステムにおけるリストア後のファイルアクセス方法を示すフローチャートである。図１３は、本発明の実施形態による階層化ストレージのファイルシステムにおけるファイルアクセス方法を説明する図である。
【００７６】
ここでは、ＬＴＦＳ  ＥＥを用いる場合を一例として説明する。この場合、テープメディア内に移行されるファイルデータは、クラスタＩＤ、ファイルシステムＩＤ、ｉｎｏｄｅ世代、ｉｎｏｄｅ番号を含む固有な識別子（ＵＩＤ）をファイル名として有し、分散共有ファイルシステム上のパスとリンクされる。ファイルが更新されるとＵＩＤが変更され、リンクが作り直される。また、ファイルデータが移行されたテープメディアを識別するテープＩＤが、ｉｎｏｄｅ内に属性情報として保存され、それらを使用してファイルを読み出すことができる。
【００７７】
分散共有ファイルシステム上のファイルは、図１３の上段に示すようにディレクトリ「/gpfs」下に認識される。これに対して、テープライブラリのファイルシステムでは、図１３の下段に示すようにディレクトリ「/ltfs」下にテープＩＤを有するサブディレクトリが作成され、個々のテープＩＤのサブディレクトリ下に、そのテープメディア上のファイルがディレクトリ階層で認識される。
【００７８】
図１２に示す処理は、ファイルに対するアクセス要求に応答して、ステップＳ３００から開始される。ここでは、仮にユーザが、分散共有ファイルシステムのファイル（例えば、「/gpfs/dir1/file-a」）にアクセスしたとする。ステップＳ３０１では、まず、アクセス要求を受け付けたノード１１２が、ファイルが共有ディスク上に存在するか否かを判断する。ステップＳ３０１で、共有ディスク上にあると判断された場合（ＹＥＳ）は、ステップＳ３０２で、ノード１１２は、共有ディスク上のファイルにアクセスし、ステップＳ３１１で本処理を終了する。
【００７９】
これに対して、ステップＳ３０１で、共有ディスク上に存在しないと判断された場合（ＮＯ）は、ステップＳ３０３で、ノード１１２は、そのファイルのｉｎｏｄｅ情報に基づき、該当ファイルが移行されているテープＩＤを特定する。ｉｎｏｄｅ情報のファイル拡張属性には、実際のデータが書き込まれているテープメディアのテープＩＤ（例えば「tapeA」）が書かれている。ステップＳ３０４では、テープＩＤで識別されるテープメディアがテープドライブにロードされ、マウントされる。
【００８０】
ステップＳ３０５では、ノード１１２は、マウントするテープメディアのＩＰ上のインデックスと、共有ディスク上の対応するインデックスとが一致するか否かを判定する。図１０に示す例では、第２世代のメタデータ（inode_v2）をバックアップした後にファイルが更新されているので、テープメディアのＩＰ上には第３世代のインデックス（Index_v3）がある。これに対して、共有ディスク上には第２世代のインデックス（Index_v2）があり、不一致となる。ステップＳ３０５で、不一致と判定された場合（ＮＯ）は、ステップＳ３０６へ処理が分岐される。
【００８１】
ステップＳ３０６では、ノード１１２は、当該マウントがリストア後初回のマウントであるかを判定する。例えば、所定のテープメディアについて初回マウント時に立てるフラグを用意し、そのフラグが立っているか否かを確認して、初回であるか否かを判定することができる。ステップＳ３０６で、初回であると判定された場合（ＹＥＳ）は、ステップＳ３０７へ処理が分岐される。
【００８２】
ステップＳ３０７では、ノード１１２は、テープメディアのＩＰ上のインデックスを無視し、共有ディスク上のインデックスを用いてマウントし、ステップＳ３０９へ処理を進める。図１０に示す例では、テープメディア上の第３世代のインデックス（Index_v3）が無視され、共有ディスク上の第２世代のインデックス（Index_v2）が使用される。
【００８３】
一方、ステップＳ３０６で、初回ではないと判定された場合（ＮＯ）は、ステップＳ３０８へ処理が分岐される。ステップＳ３０８では、ノード１１２は、テープメディア上のインデックスを、共有ディスクに複製してマウントし、ステップＳ３０９へ処理を進める。なお、ステップＳ３０５で、一致すると判定された場合（ＹＥＳ）は、ステップＳ３０９へ処理が直接進められる。
【００８４】
ステップＳ３０９では、ノード１１２は、共有ディスク上のインデックスに基づいて、特定されたテープメディア上のファイル（「/ltfs/tapeA/dir1/file-a」）にアクセスする。このファイルは、実際はシンボリックリンクになっており、ファイル本体データが存在しているフォルダ「tapeA/.LTFSEE_DATA」にあるファイルから読み出しが行われる。
【００８５】
図１０に示す例では、第２世代のメタデータ（inode_v2）をバックアップした後にファイルが更新されているので、テープメディア上のインデックス（Index_v3）には、バックアップ後に書かれたファイルデータ（file-a_v3）の情報が保存されている。しかしながら、このインデックスは、初回マウント時に無視され、共有ディスクにリストアされ、マウントに使用された第２世代のインデックス（Index_v2）が用いられる。第２世代のインデックス（Index_v2）には、ファイル（file-a_v2）の情報が保存されているので、バックアップ時点のファイル本体データ「file-a_v2」が読み出される。
【００８６】
ステップＳ３１０は、必要に応じて、アクセスにかかるファイル本体データをディスク上にリコールし、ファイルの状態を変更し、ステップＳ３１１で本処理を終了する。例えば読み出しアクセスであれば、ディスクとテープとの両方にある予備移行状態に変更される。例えば上書きアクセスであれば、ディスクのみにある未移行（resident）状態に変更される。なお、マウントされたテープメディアへの書き込み時、またはマウントされたテープメディアのアンマウント時には、テープメディアのＩＰ上のインデックスが、リストア後の最新のインデックスで上書きされるので、そのタイミングで、ディスクとテープの不一致は解消する。
【００８７】
以下、図１４、図１５および再度図１１を参照しながら、本発明の実施形態によるバックアップ方法およびリストア方法と他の想定される方法との比較を行う。
【００８８】
（書き込み禁止にする場合との比較）
図１４は、書き込み禁止にする他のバックアップ方法およびリストア方法を説明する図である。図４を参照して説明した、バックアップおよびリストアしたメタデータと、テープメディア上のファイルとの不整合を避けるため、バックアップを取得する毎に、既に書き込んだテープメディアを書き込み禁止にする手法が考えられる。
【００８９】
例えば、図１４のように、異なる３つのファイル「file-a」、「file-b」、「file-c」を順に作成することを考える。その作成のたびに、ファイルをテープメディアへ移行し、メタデータ「inode-a」、「inode-a/b」、「inode-a/b/c」のバックアップを取得し、それぞれのファイル「file-a」、「file-b」、「file-c」を保存したテープを書き込み禁止にする。これにより、３本の書き込み禁止のテープメディアができる。また、復旧する際は、最後のバックアップを保持するメディア５１０−３を使用し、メタデータ「inode-a/b/c」をリストアする。また、バックアップのたびに書き込み禁止にした、３本のテープメディアすべてを復旧サイト５２０に移動する。
【００９０】
できるだけ最新の情報を復元するには、適切な頻度で分散共有ファイルシステムのメタデータのバックアップを取得し、そのたびにテープメディアを書き込み禁止する必要がある。しかしながら、頻繁にバックアップを取得すると、まだ未使用部分のあるテープを書き込み禁止にすることになるため、使用できないテープの容量が多くなる。また、大規模なファイルシステムでは、テープライブラリ内に多数のテープドライブを導入し、複数のテープメディアに分散して複数のファイルを同時に書き込むことで、マイグレーションの高速化を図っている。特にこのような場合、テープメディアを書き込み禁止にするたびに、テープドライブの数だけ未使用部分を残したテープが作られるため、テープの使用効率が大きく低下する。
【００９１】
例として、テープドライブ１０台をもつテープライブラリを使ったシステムとして計算する。一度に書き込む速度をあげるため、すべてのテープドライブを使い、１０本のテープメディアに分散して同時に保存するとする。テープ容量がどれだけの割合で使用されるかは、ばらつきがあるが、平均して５０％が使われると仮定する。また、１日に１０本のテープメディアが容量の５０％使われ、毎日メタデータのバックアップを取得するものとする。ＬＴＯ６フォーマットを使うとすると、テープ容量は、圧縮時で６．２５ＴＢある。したがって、上述した書き込み禁止にする方法では、１０本の５０％しか使われないため、１日約３１ＴＢが未使用のままになる。毎日バックアップを取得した場合は、１週間で全体の５０％である約２１８ＴＢの容量の損失になる。
【００９２】
これに対し、本発明の実施形態によるバックアップ方法およびリストア方法では、同様の条件を仮定した場合、テープメディアを１週間追記し続けることにより、４０本使われ、そのうち３０本は、未使用部分のない容量を使い切った状態となる。１０本は、最終日に５０％のみ使われるが、１週間後のテープの未使用部分は、約３１ＴＢとなり、全体の１３％に抑えられる。仮に各テープの容量を毎日９０％使った場合でも、書き込み禁止にする手法では１０％の損失があるのに対し、本発明の実施形態による手法では、１％程度で済み、約１／１０に収まる。
【００９３】
（リクラメーションする場合との比較）
図１５は、書き込み禁止にしかつリクラメーションを行う他のバックアップ方法およびリストア方法を説明する図である。図１５に示すように、上述したテープの未使用部分は、メタデータのバックアップを取得する前に、一旦複数テープメディア５１２−１〜５１２−３に分散して保存されたファイル（file-a/b/c）を、１本のテープメディア５１４に書き直すリクラメーションを行うことにより、テープ容量の利用率を改善することができる。
【００９４】
しかしながら、リクラメーションのデータ移動では、テープへの読み書きが発生し、ファイル数が多い場合は、テープドライブ占有と、データトランザクションで、システムに負荷がかかる。また、ファイルが誤って消されたなどの理由で、以前のファイルデータを読み出したい場合、後述するファイル状態を過去にさかのぼって読み出すロールバック機能というものを利用できるが、ファイル削除前のメタデータのバックアップがあっても、リクラメーションを行ったことでテープＩＤがメタデータと実際のテープとの間で異なるため、読み出せなくなる。
【００９５】
上述した１０台のテープドライブを有するシステムで、容量の５０％が使用されたテープをリクラメーションする場合、最大５０％のデータを別のテープに移動することになる。１本のテープを書き込む時間は、ＬＴＯ６フォーマットの場合、最速で約４．４時間であるので、テープドライブを１０台使った場合でも、１０本のテープをリクレームするために２．２時間の間テープドライブが占有される。リクレーム処理中は、テープに移行されたファイルの読み出しがすぐにできないなどのパフォーマンスの低下が発生する。
【００９６】
これに対して、本発明の実施形態によるバックアップ方法およびリストア方法では、メタデータおよびインデックスのバックアップのみで足りる。ここで、バックアップ時間を見積もるために、まずバックアップするメタデータおよびインデックスのサイズを算出する。この見積もりにおいては、１本のテープメディアに格納するファイル数を約５００００個と仮定する。ファイルサイズの平均を約１００ＭＢとし、インデックスに使用する分も考慮して、ＬＴＯ６の圧縮時容量６．２５ＴＢから概算した値である。テープの本数は、上述した通り、１日１０本ずつ容量の５０％を、１週間とりつづけた場合、つまり約３５本分とする。
【００９７】
ファイル数５００００個のｉｎｏｄｅイメージバックアップのサイズは、１つのファイルのｉｎｏｄｅサイズが５１２Ｂ(バイト)であるので、下記式（数１）で計算され、約８９６ＭＢと見積もられる。実際には圧縮されるため、これよりも小さいサイズとなるが、上記値が最大値として計算される。
【００９８】
（数１）
イメージバックアップ・サイズ（Ｂ）＝５１２Ｂ×（ファイル数／テープ)×（テープ数）
【００９９】
ＬＴＦＳインデックスの中には、１つのファイルが１本のテープ内に分散して書かれて断片化したファイルデータの情報を保有するエクステント情報が存在する。エクステント情報には、ファイル内のオフセット、テープ上のデータのブロック番号、バイト数などが保存されている。テープメディア１本あたりのインデックスのサイズは、保存されているパラメーターである時間等の桁数の誤差があるが、おおよそ下記式（数２）で見積もることができる。
【０１００】
（数２）
テープ１本のインデックスサイズ（Ｂ）＝１３５０Ｂ
＋ファイル数×（１２１１Ｂ＋ファイルパスの長さ（Ｂ）＋エクステント数×１６５Ｂ）
＋ディレクトリ数×(ディレクトリパスの長さ（Ｂ）＋４００Ｂ）
【０１０１】
ここで、インデックスおよびエクステントのベースのサイズは、それぞれ１３５０Ｂおよび１６５Ｂである。ＬＴＦＳでは、ファイルパスの長さとディレクトリパスの長さは５１２Ｂ以下となっている。
【０１０２】
データブロックの書き方（分散度合い）でのエクステント数の違いや、ファイル名の長さの違いで、インデックスのサイズが変わるが、ここでは、上記と同じテープ容量、平均ファイルサイズ、テープ１本あたりのファイル数、テープ本数を仮定して、さらに、１ファイルあたりのエクステント数が１０個であり、ファイルパスの長さ平均値が２５６Ｂであり、ディレクトリパスの長さ平均値が１２６Ｂであると仮定する。すると、上記式（数２）により、テープ１本あたりのインデックスのサイズは、約１５６ＭＢと見積もられ、３５本で約５．４６ＧＢと見積もられる。
【０１０３】
バックアップ先メディアが、テープメディアであれば、書き込みおよび読み出し時間は、それぞれ１４秒程度で済む。仮にテープメディアを１０００本復旧する場合としても、６．５分で複製することが可能と見積もられる。つまり、本発明の実施形態によるリストア手法では、リクラメーションする手法と比較して、読み出し時間を節減できると言える。
【０１０４】
また、リクラメーションを使用すると、ファイルが別のテープへ移動し、インデックスの履歴が消去されて元のテープが空になるため、後述する古いインデックスを使用して消されたデータを復旧するロールバック機能は使用できない。本発明の実施形態によるバックアップ方法およびリストア方法では、過去にさかのぼって古いファイルシステムも復旧が可能である。
【０１０５】
（ロールバックする場合との比較）
図１１を参照して説明したように、ＬＴＦＳフォーマットで書かれたデータは、ＤＰに書き込まれたインデックスを利用して、過去のファイルデータを復元するロールバックが可能である。
【０１０６】
ロールバックするには、テープメディアをマウントして、ＤＰ上のロールバックする世代のインデックスを探索するために、最新のインデックスから逆順に読み出す必要がある。図１１に示す例では、ある時間Ｔより前の状態のファイルを読み出す場合は、まず第３世代のインデックス＃３を読み出し、インデックス＃３が時間Ｔ以降に書かれたものであれば、インデックス＃３の中に書いてあるＤＰ上のインデックス＃２のテープ上のブロック番号を読み出し、インデックス＃２の書かれている場所まで読み出し位置を移動する。インデックス＃２を読み出し、時間Ｔより前のものが見つかるまで比較を繰り返す。
【０１０７】
このように、ロールバック機能で、古いインデックスを指定してファイルを読み出すこともできるが、テープ１本あたり数十分から数時間かかり、ファイルやテープが増えると復旧に長時間かかる。本発明の実施形態によるリストア方法では、ロールバックする手法と比較しても、読み出し時間を節減できると言える。
【０１０８】
（その他の方法との比較）
上述したほか、定期的にメタデータ（ｉｎｏｄｅ情報）とファイルデータすべてのフルバックアップをとれば、昔の状態に戻すことは可能である。しかしながら、データ量が多い場合は、バックアップ用のテープの量や、バックアップ時に使うディスクキャッシュなどのリソースが多く必要となる。
【０１０９】
以上説明したように、本発明の実施形態によれば、復旧時間を短縮することができるとともに、バックアップ後もファイルシステムが運用可能であり、かつ、システムへの負荷が小さく、かつ、移行先の記憶媒体の使用効率を高めることができる、バックアップ方法、リストア方法、ストレージ・システムおよびプログラムを提供することができる。
【０１１０】
本発明の実施形態によるバックアップ方法では、運用サイトでファイルデータをテープメディアに保存し、メタデータとインデックスとをバックアップする。本発明の実施形態によるリストア方法では、復旧サイトで、メタデータをリストアするとともに、それと同時にバックアップしたインデックスをリストアし、このインデックスを使用してメタデータと同じ時点のテープ上のファイルデータを読み出す。これにより、時間整合性のあるファイルシステムを復旧することが可能となる。
【０１１１】
テープの未使用領域を、テープメディアへの更新を禁止する手法と比べ１／４以下に減らすことができ、テープの容量を効率的に使うことが可能になる。また、テープメディアをリクラメーションで書き換えるためにテープドライブを数時間占有するなどのシステム負荷も生じす、ファイルシステム復旧に必要なバックアップおよびリストアを、短時間で行うことが可能となる。
【０１１２】
本発明の上記機能は、アセンブラ、Ｃ、Ｃ＋＋、Ｃ＃、Ｊａｖａ（登録商標）などのレガシープログラミング言語またはオブジェクト指向プログラミング言語などで記述された装置実行可能なプログラムにより実現でき、装置可読な記録媒体に格納して頒布または伝送して頒布することができる。
【０１１３】
これまで本発明を、特定の実施形態をもって説明してきたが、本発明は、実施形態に限定されるものではなく、他の実施形態、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。
【符号の説明】
【０１１４】
１０…ＣＰＵ、１２…メモリ、１４…記憶装置、１６…ネットワークＩ／Ｆ、１８…入出力Ｉ／Ｆ、１００，２００…階層化ストレージ管理システム、１０２…ＳＡＮファブリック、１０４…ＬＡＮ、１１０…クラスタ、１１２…ノード、１２０…共有ディスクアレイ、１２２…共有ディスク、１３０…テープライブラリ、１３２…テープドライブ、１３４…テープメディア、１４０…管理端末、２１０…分散共有ファイルシステム、２１２…バックアップ／リストア部、２２０…拡張ファイルシステム、２２２…階層化ストレージ管理部、２２４…ライブラリ制御部、２２６…テープ用ファイルシステム、２３０…バックアップドライバ、２３２…メタデータバックアップ制御部、２３４…インデックスバックアップ制御部、２３６…メタデータリストア制御部、２３８…インデックスリストア制御部、３００…運用サイト、３０２，３２２…分散共有ファイルシステム、３０４，３２４…共有ディスク、３０６，３２６…テープライブラリ、３１０…メディア、３１２…テープメディア、３２０…運用サイト、５００…運用サイト、５０２，５２２…分散共有ファイルシステム、５０４，５２４…共有ディスク、５０６，５２６…テープライブラリ、５１０…メディア、５１２…テープメディア、５２０…復旧サイト
【図１】
0005975473.tif 000002
【図２】
0005975473.tif 000003
【図３】
0005975473.tif 000004
【図４】
0005975473.tif 000005
【図５】
0005975473.tif 000006
【図６】
0005975473.tif 000007
【図７】
0005975473.tif 000008
【図８】
0005975473.tif 000009
【図９】
0005975473.tif 000010
【図１０】
0005975473.tif 000011
【図１１】
0005975473.tif 000012
【図１２】
0005975473.tif 000013
【図１３】
0005975473.tif 000014
【図１４】
0005975473.tif 000015
【図１５】
0005975473.tif 000016