JP5984151B2 - データの復旧方法、プログラムおよびデータ処理システム - Google Patents

Description

本発明は、複数のデータをデータ処理システムに復旧する方法、その方法をコンピュータに実行させるためのプログラムおよびデータ処理システムに関する。

データを作成し、提供する運用サイトでは、作成したデータを運用サイトに保存するほか、記録媒体にバックアップを取ることにより、万一の災害に備えている。記録媒体としては、例えば、低コストの磁気テープ媒体（テープ・メディア）が使用される。

テープ・メディアは、データのバックアップを取った後、運用サイトから遠く離れた災害時復旧用のサイト（復旧サイト）へ運搬され、そこに保管される。復旧サイトには、運用サイトと同様の機器から構成されるデータ処理システムが予め構築される。したがって、運用サイトで災害が発生しても、遠隔地にある復旧サイトで、保管しているテープ・メディアから運用サイトと同じ状態までデータを復旧（リストア）し、バックアップを取った時点に遡って業務を再開することができる。

従来のデータのリストアは、テープ・メディアに保存されたファイルをすべて読み出し、復旧サイトのHDDやSSD等に書き込むことにより行われていた。このため、ファイル数が多い場合やデータ・サイズが大きい場合、復旧に相当の時間がかかってしまい、業務を早期に再開することができなかった。

運用サイトでは、複数のコンピュータを連結し、１台のコンピュータが障害等により停止しても全体が停止することなく、処理を継続して行うことができ、その間に障害等が発生したコンピュータの修理や交換を行うことができるクラスタ・システムが採用されている。このクラスタ・システムでは、個々のコンピュータはノードと呼ばれ、各ノードが管理する記憶装置（ディスク）へのデータの分散保存やバックアップは、GPFS(General Parallel File System)等のソフトウェア・コンポーネントを使用して行われている。

GPFSを利用したデータのバックアップおよびリストアは、図１に示すような方法で実施される（例えば、特許文献１、２参照）。図１に示すように、運用サイトは、GPFSであるファイルシステム１０と、高速で読み書きが行われる記憶装置であるディスク１１と、低速で読み書きが行われるテープ・プール１２とを備えるシステム構成とされる。復旧サイトは、運用サイトと同じ、ファイルシステム１３と、ディスク１４と、テープ・プール１５とを備えるシステム構成として構築される。

通常の業務において、運用サイトでデータを保存する際、ファイルシステム１０がディスク１１のほか、テープ・プール１２内のテープ・メディア１６にそのコピーをファイルとして保存する。バックアップ時には、ファイルの属性情報（メタ情報）を有するinode情報のみを保存する。このときのファイルがディスク１１とテープ・メディア１６の両方にある状態は、pre-migrated状態と呼ばれる。

復旧サイトでは、ファイルシステム１３にinode情報をリストアしてファイルのメタ情報を復旧し、ファイルの状態を、テープ・メディアにのみファイルがある状態（migrated状態）に変更して復旧を完了する。このデータの復旧方法では、テープ・メディア１６からファイルをすべて読み出し、復旧サイトのディスク１４に書き込む必要がなくなるため、リストアに時間を要することなく、早期に業務を再開することができる。

しかしながら、業務を再開した後は、すべてのファイルがテープ・メディア１６にしかないので、各ファイルへ最初にアクセスする際は、テープ・メディア１６から読み出す必要があり、ユーザは大きなストレスを感じることなる。テープ・メディア１６からデータを読み出すのに、ディスク１４と比較して時間がかかるからである。

そこで、図２に示すように、復旧後にすぐに使用すると考えられるファイルを、予め設定された規則に基づき選択するファイル・リストを作成しておき、そのファイル・リストに含まれるファイルを予めディスク１４に読み出しておく仕組みが提供されている。この仕組みは、preferred recallと呼ばれる。復旧後にすぐに使用するファイルは、テープ・メディア１６からではなく、高速に読み出すことが可能なディスク１４から読み出すことができるので、ユーザのストレスを軽減することができる。

ところで、大容量、高速の読み書きを目的とした磁気テープ記憶装置の規格としてLTO(登録商標)という規格がある。現在、最新のLTO（登録商標）は、LTO-6で、容量が２．５TB、転送レートが１６０MB/sとなり、各社共通のファイルシステム(LTFS)をサポートし、USBメモリやSDカードのように、複数のOS環境でその共通のファイルシステムを扱えるようになっている。LTFSは、図３に示すように、テープ１７上の領域をインデックス・パーティション１８と、データ・パーティション１９の２つに分け、ファイルのメタ情報（ファイルの属性、パス、物理位置、サイズ、アクセス制御リスト、拡張属性等）をインデックスとして持つことにより、テープ１７上のデータをOSにファイルとして認識させている（例えば、特許文献３参照）。

LTFSは、インデックス・パーティション１８上のインデックス・ファイルに書かれたメタ情報を、テープ１７が磁気テープ・ドライブ装置１５によりロードされるときに読み出し、ノードが備えるCPUがメモリ上に展開した上で、OSからのファイルシステム情報の要求に応答する。図４には、インデックス・パーティション１８上のインデックス・ファイルの例を示す。インデックス・ファイルは、図４に示すように、ファイルを階層構造（ディレクトリ）で管理し、そのディレクトリに属するファイルはxml(Extensible Markup Language)形式で記述される。ここでは、ファイルのファイル名、サイズ等がテキスト形式で記述されている。

LTFSは、個々のテープ・メディア１６に保存されたファイルを管理するファイルシステムであるが、GPFSのような複数のノード間でファイルシステムを共有する環境で使用できるように拡張されたLTFS EE(Enterprise Edition)が提供されている。このLTFS EEは、図５に示す共有ディスク２０にテープ・メディア１６に保存されたファイルのメタ情報を格納することにより、ノード１とノード２との間でこのメタ情報を共有することを可能にする。LTFS EEは、共有ディスク２０にノード１およびノード２が有するユーザ・ファイルと同じディレクトリ構成をもった、データは持たないdentriesファイル２１を作成し、そのdentriesファイル２１にファイル属性を付加してメタ情報を管理する。

特開２００５−１８７５７号公報 特開２００５−１８７５８号公報 特開２０１４−１２３２５４号公報

GPFSは、ストリーミング・データ等のサイズが大きいファイルを多数管理することを目的として作成され、メタ情報のような小さいサイズのファイルを多数扱うように構成されてはいない。

ここで、図６に、共有ディスク２０上にdentriesファイルをインデックス・ファイルから生成するのにかかる時間と、バックアップしたメタ情報をdcacheファイルとして共有ディスク２０上に書き込む時間とを比較した図を示す。図６を参照すると、dcacheファイルを書き込む時間の方が、時間はかかるが、いずれもファイル数に比例してその時間が増加している。この図６では、２万ファイルについてdentriesファイルを生成するには、約９分かかり、これが１０億ファイルであれば、３００日以上かかることが分かる。したがって、小さいサイズのファイルとはいえ、その数が多ければ膨大な処理時間がかかる。

preferred recallでリストア時に読み出すファイルは、全テープ・メディア１６に保存されている一部のファイルである。共有ディスク２０上に展開が必要なメタ情報は、当該一部のファイルのメタ情報のみである。全テープ・メディア１６のインデックス・ファイルから全ファイルについてdentriesファイルを生成等するには、上記のような膨大な時間が必要となるが、当該一部のファイルについてdentriesファイルを生成等するだけであれば、大幅に処理時間を短縮することができる。

そこで、preferred recallで復旧時に読み出すファイルを特定のテープ・メディア１６にまとめる方法を使用することができる。必要なテープ・メディア１６のみをロードし、そのテープ・メディア１６からインデックス・ファイルを読み出せばよいからである。

しかしながら、LTFS EEでは、pre-migrated状態にするための操作（premigration）を行うファイルが書き込まれる先は、テープ・メディア１６毎ではなく、ある個数のテープ・メディア１６から構成されるプール単位で指定するため、その全てのファイルがプール内の特定のテープ・メディア１６に書き込まれることは稀であり、プール内のテープ・メディア１６に分散して書き込まれることになる。テープ内のほとんど全てのテープ・メディア１６に分散して書き込まれた場合、復旧時には、preferred recall対象のファイルを読み出すために、そのプール内のほとんど全てのテープ・メディア１６をロードするとともに、そのテープ・メディア１６に保存されたpreferred recall対象以外のファイルを含む全てのファイルのメタ情報を共有ディスク２０上に展開した上で、preferred recallを実行することになる。これでは、メタ情報を共有ディスク２０に展開する処理だけで膨大な時間がかかってしまうといった問題があった。

したがって、短時間でデータを復旧して、早期に業務を再開することを可能にする方法等の提供が望まれている。

本発明は、上記課題に鑑み、複数のデータをデータ処理システムに復旧する方法であって、データ処理システムが、複数のデータの各々に関連付けられた記録媒体を識別するための媒体識別情報を含む複数のデータを複数のファイルとして管理するための管理情報を、データ処理システムが備える記憶装置に記憶して管理情報を復旧するステップと、複数のファイルと複数のファイルに関する情報（メタ情報）とが記憶された複数の記録媒体の接続を受け付けるステップと、１以上の媒体識別情報を含む複数のファイルのうちの１以上のファイルに関する情報を、記憶装置に記憶するステップと、複数の記録媒体に記憶されている複数のファイルに関する情報に代えて、記憶装置に記憶された１以上のファイルに関する情報を使用してファイルを読み出す設定に切り替えるステップと、１以上のファイルに関する情報に基づき、ファイルを読み出す１以上の記録媒体を特定し、特定した該１以上の記録媒体から１以上のファイルを記憶装置へ読み出すステップと、１以上のファイルに関する情報を記憶装置から削除するステップとを含む、データの復旧方法が提供される。

本発明によれば、短時間でデータを復旧して、早期に業務を再開することができる。

データのバックアップおよびリストアの１つの方法を説明する図。 データのバックアップおよびリストアの別の方法を説明する図。 テープ・メディアのパーティショニングの利用例を示した図。 図３に示すテープ・メディアのインデックス・パーティションに書き込まれるインデックス・ファイルの例を示した図。 複数のノード間でファイルシステムを共有する例を示した図。 ファイル数と、インデックス・ファイルからdentriesファイル生成するのにかかる時間およびバックアップしたdcacheファイルを共有ディスクに書き込む時間との関係を示した図。 複数のデータをバックアップまたはリストアするデータ処理システムの構成例を示した図。 図７に示すデータ処理システムに実装されるプログラムを構成するコンポーネントの例を示した図。 データ処理システムが行うバックアップの流れを説明する図。 図９に示す処理の流れを示したフローチャート。 データ処理システムが行うデータをリストアする処理の流れを説明する図。 図１１に示す処理の流れを示したフローチャート。 テープ・メディア上のファイルへのアクセスを説明する図。

以下、本発明を図面に示した具体的な実施の形態に沿って説明するが、本発明は、後述する実施の形態に限定されるものではない。図７は、複数のデータをバックアップまたはリストアするデータ処理システムの構成例を示した図である。データ処理システム３０は、コンテンツ配信や映像配信等の業務を行う運用サイトと、その運用サイトから遠く離れた遠隔地にあるその業務を復旧するための復旧サイトとに同じ構成で構築される。運用サイトのデータ処理システムは、複数のデータを保持し、複数の記録媒体へ複数のデータを書き込んでバックアップを取るために、復旧サイトのデータ処理システムは、バックアップを取った複数のデータをリストアするために使用される。

データ処理システム３０は、複数のノード３１と、複数のテープ・メディア３２をロードすることができる複数のドライブ装置３３とを含んで構成される。複数のノード３１は、例えばＮ個のサーバ装置等のコンピュータとされ、互いに接続され、それぞれが各ドライブ装置３３と接続されている。このデータ処理システム３０は、各ノードが分散して並列に処理を実行するクラスタ・システムとされている。図７では、クラスタ・システムを例示したが、これに限られるものではなく、１つのサーバ装置と１つのドライブ装置とから構成されるシステムであってもよい。

各ノード３１は、処理装置としてのCPU３４と、RAM等のメモリ３５と、HDD等の記憶装置３６と、入出力インタフェース(I/F)３７を含む。CPU３４は、データをファイルとして所定の処理を実行する。所定の処理には、ファイルの読み出し、ファイルの書き込み、ファイルの加工等が含まれる。ファイルの読み出し、書き込みには、データのバックアップ、データのリストアが含まれる。メモリ３５は、CPU３４が処理を行うために読み出したファイルを記憶するための記憶領域を提供する。したがって、CPU３４は、ファイルを一度メモリ３５に読み出し、その読み出したファイルに対して処理を実行する。

記憶装置３６は、CPU３４が所定の処理を実行するためのプログラムを記憶し、バックアップするデータまたはリストアしたデータをファイルとして記憶することができる。記憶装置３６は、各ノードがアクセス可能な記憶装置３６の一部の記憶領域を共有ディスクとして構成することができる。複数のノード３１が備える共有ディスクをネットワークで接続したものは、ネットワーク共有ディスク(NSD)と呼ばれる。なお、記憶装置３６は、HDDに限られるものではなく、SSD等を使用することもできる。

記憶装置３６が記憶することができるファイルは、文書ファイル、画像ファイル、映像ファイル等、いかなるファイルであってもよい。ファイルには、ファイルに関する情報として、属性情報（メタ情報）が含まれる。また、記憶装置３６は、上記プログラムやファイルのほか、各種の設定値、OS、ドライバ等も記憶することができる。OSは、UNIX（登録商標）、LINUX（登録商標）、Windows（登録商標）、MacOS（登録商標）等を用いることができ、入出力装置、メモリ３５、記憶装置３６の管理や、ネットワークを介した通信の制御等を行う。ドライバは、ノード３１内の装置やノード３１に接続された機器の制御、操作を行う。

入出力I/F３７は、ノード３１をドライブ装置３３と接続し、ドライブ装置３３との間でファイルのやりとりを行う。各ノード３１は、そのほか、装置を起動するためのブート・プログラム等を記憶するROM、外部記憶メディアを接続するための外部記憶I/F、ネットワークに接続するための通信I/F、ユーザからの入力を受け付けるユーザI/F、処理状況やエラー等を表示するための表示装置等を備えることができる。

記録媒体は、USBメモリ、SDカード、CD-ROM等を用いることもできるが、テープ・メディア３２を使用することができる。以下、記録媒体をテープ・メディア３２として説明する。テープ・メディア３２は、例えば、リールに多重に巻かれたテープをカートリッジ内に収納したものとされ、ドライブ装置３３は、そのカートリッジを挿入する挿入口を備え、その挿入口へカートリッジを挿入することにより、テープ・メディア３２をセットすることができる。また、ドライブ装置３３は、CPU３４からの命令に基づき、ドライブ装置３３内にセットしたテープ・メディア３２に対してファイルの読み書きを行う。なお、複数のテープ・メディア３２の管理、操作、各ドライブ装置３３へのテープ・メディア３２の挿入等は、テープ・ライブラリ３９により行われる。このため、複数のドライブ装置３３は、テープ・ライブラリ３９に組み込まれている。

ドライブ装置３３は、例えば、上記の入出力I/F３７と接続し、ノード３１のOSからテープ・メディア３２へのファイルの書き込みや読み出しを指示する命令を受け付ける入出力I/Fと、書き込むべきファイルや読み出したファイルを蓄積するメモリと、実際にテープ・メディア３２へのファイルの書き込みや読み出しを行うヘッドと、リールを一定の回転数で回転させる駆動部と、ドライブ装置３３全体の制御を行うコントローラとを含んで構成することができる。

図８は、データ処理システム３０に実装されるプログラムを構成するコンポーネントの例を示した図である。データ処理システム３０は、複数のノード３１により共有される複数のディスクから構成されるNSD等の共有ディスク３８と、複数のテープ・メディア３２とドライブ装置とを含んで構成されるテープ・ライブラリ３９と、共有ディスク３８およびテープ・ライブラリ３９内の複数のファイルを管理するための、複数のノード３１により使用される複数のコンポーネントからなる管理システム４０とを含んで構成することができる。

コンポーネントとしては、複数のノード３１で共有するファイル、例えば共有ディスク３８に記憶されるファイル等を管理するGPFS等の分散共有ファイルシステム４１と、個々のテープ・メディア３２に記憶されるファイルを管理するLTFS等のテープ用ファイルシステム４２とを用いることができる。これらは、ファイルとともにファイルのメタ情報を管理する。分散共有ファイルシステム４１は、共有するファイルへのアクセス、テープ用ファイルシステム４２は、個々のテープ・メディア３２に記憶されるファイルへのアクセスを提供する。

また、コンポーネントとしては、上記のテープ用ファイルシステム４２と、階層ディスク記憶管理部４３と、管理部４４とを含み、テープ・メディア３２上のファイルを、複数のノード３１で共有することを可能にする機能が拡張されたテープ用ファイルシステム（拡張ファイルシステム）４５を用いることができる。階層ディスク記憶管理部４３は、共有ディスク３８を上位層とし、テープ・ライブラリ３９を下位層とした階層ディスク構造を構築し、上位層から下位層へファイルを移行する。管理部４４は、テープ・ライブラリ３９のどのテープ・メディア３２へファイルを保存するかを判断し、ファイルの振り分けを行う。また、管理部４４は、テープ・メディア３２からファイルを読み出し、読み出したファイルの共有ディスク３８への書き込みも行う。さらに、コンポーネントとしては、バックアップを取るためのバックアップ・ドライバ４６を用いることができる。

テープ・ライブラリ３９は、複数のテープ・メディア３２を、アーカイブ用のテープ・プールと、バックアップ用のテープ・プールとに分けて使用する。アーカイブ用のテープ・プールは、主に２つの目的で使用される。１つは、共有ディスク３８に保存された重要なファイルをコピーし、そのコピーを冗長的にテープ・メディア３２に格納する目的である。もう１つは、migrationポリシーに基づき、長時間使用されていないファイルをテープ・メディア３２に書き込み、共有ディスク３８上から削除するアーカイブ目的である。migrationポリシーは、例えば、ファイルが３０日未使用である場合にテープに移行するといったファイルの移行に関して設定された規則である。

バックアップ用のテープ・プールは、遠隔地にある復旧サイトで業務を復旧するためのバックアップ目的で使用される。このバックアップ用テープ・プールのテープ・メディア３２へのファイルの書き込みも、migrationポリシーに基づき行うことができる。

データ処理システム３０が扱うファイルには、文書ファイル、画像ファイル、映像ファイル等のユーザ・ファイルに加え、ファイル名、パス、ファイルの物理位置、ファイルのサイズ、アクセス制御リスト、拡張属性等のメタ情報が含まれる。このため、データ処理システム３０では、ユーザ・ファイルに加え、メタ情報も各ノード３１間で共有される。メタ情報に含まれるパスは、ディレクトリの最上層（ルート・ディレクトリ）から目的のファイルまでの道筋を記述したものである。アクセス制御リストは、そのファイルへのアクセスを許可するか否かを記述した制御情報である。拡張属性は、ユーザによって追加して記述することができる情報である。

このデータ処理システム３０を使用した通常の業務では、ユーザが定義したmigrationポリシーに基づき、高速ストレージとしての共有ディスク３８に書き込まれたファイルを、低速ストレージとしてのアーカイブ用およびバックアップ用のテープ・プールのテープ・メディア３２に書き込む。ファイルを書き込んだとき、共有ディスク３８からそのファイルは削除されないので、同じファイルが３箇所に存在する状態、すなわち共有ディスク３８にも、テープ・メディア３２にも存在するpre-migrated状態になる。

アーカイブ用のテープ・プールを有する環境では、共有ディスク３８の空き領域を確保し、共有ディスク３８を有効に利用するために、その共有ディスク３８からアーカイブ用のテープ・プールにコピーしたファイルは削除することができる。このため、アーカイブ用のテープ・プールにのみファイルが存在するmigrated状態もサポートすることが可能となっている。

共有ディスク３８は、ファイルを構成するデータの実体に加えて、ファイルを管理するための管理情報として、ファイルのメタ情報を有するinode情報も格納している。分散共有ファイルシステム４１は、inode情報を管理し、このinode情報から管理するファイルのディレクトリ情報やメタ情報をファイルシステム情報として取得し、OSからのファイルシステム情報の要求に応答して、OSにファイルを認識させる。ファイルシステム情報は、パスや物理位置等を含むため、OSの制御の下、ノード３１がそのファイルへアクセスし、そのファイルを読み出すことができる。

分散共有ファイルシステム４１は、inodeバックアップ・コンポーネントを備え、このinodeバックアップ・コンポーネントにより上記のinode情報のバックアップを取ることができる。

テープ用ファイルシステム４２は、ファイルに関する情報としてのメタ情報をインデックスとしたインデックス・ファイルを使用してテープ・メディア３２上のファイルを管理する。また、テープ用ファイルシステム４２は、個々のノード３１に接続されているドライブ装置３３をマウントする。共有ディスク３８からテープ・メディア３２にファイルをコピーする場合は、そのコピーを実行するノード３１上で、分散共有ファイルシステム４１からテープ用ファイルシステム４２にそのファイルがコピーされる。これと同時に、テープ用ファイルシステム４２のメタ情報が分散共有ファイルシステム４１に書き込まれる。分散共有ファイルシステム４１に書き込まれたメタ情報は、他のノードからも参照可能であるため、そのテープ用ファイルシステム４２が複数のノード３１で共有されているように見える。

拡張ファイルシステム４５は、テープ用ファイルシステム４２が管理するインデックス・ファイルのメタ情報を、テープ・メディア３２がロードされる際に該テープ・メディア３２から読み出し、メモリ上に展開してOSからのファイルシステム情報の要求に応答する。そして、テープ・メディア３２上のファイルを、ファイルシステム情報によりOSに認識させる。これにより、ノード３１は、OSの制御の下で、読み出しを要求されたファイルを、特別なプログラムを使用することなく、テープ・メディア３２から読み出すことができる。

inode情報には、拡張属性が含まれ、その拡張属性には、ファイルの実体が保存されているテープ・メディア３２を識別するための媒体識別情報、すなわちテープ識別情報としてのテープIDが含まれている。拡張ファイルシステム４５は、ファイルのinodeに書かれているテープIDの情報を基に、どのテープ・メディア３２からファイルを読み出せばよいかを判断する。これにより、特定したテープ・メディア３２をマウントして、そのテープ・メディア３２からファイルを読み出すことができる。

バックアップ・ドライバ４６は、バックアップ要求を受け付けて、その要求を受け付けた時点の分散共有ファイルシステム４１のスナップショットを取り、そのスナップショットが示すファイルシステムをスキャンする。ここで、スキャンとは、ファイルシステム内の全てのファイルの属性を走査することを意味する。このスキャン時に、ユーザが定義した選択ポリシーに合致するファイルを検出し、ファイル・リストにそのファイルのパス名を追記する。選択ポリシーは、バックアップ要求を受け付けたときに指定することができるため、バックアップ後４８時間以内に書き込まれたファイルについてpreferred recallを実行する等、復旧時に読み出すデータを、柔軟性をもって指定することができる。

選択ポリシーは、業務再開後にすぐに使用することが予想されるファイルを選択するといったファイル選択に関して設定された規則とすることができる。上記のほか、例えば、１週間以内に保存したファイルを選択する、特定の種類のファイルを選択するという規則とすることができる。ユーザが行う業務に応じて選択ポリシーを設定することができる。また、バックアップ・ドライバ４６は、選択したファイルのリストを生成し、そのリストに基づき、後述するpreferred recall用インデックス・ファイルを生成する。

図９を参照して、データ処理システム３０が行うバックアップについて説明する。バックアップは、運用サイトに構築されたデータ処理システム３０により予め設定されたスケジュールに従って、またはユーザからの指示により実施される。データ処理システム３０は、バックアップ・ドライバ４６を使用して、最初に、バックアップ対象のファイルを管理するファイルシステムのスキャンを行う。ファイルシステムをスキャンするのは、ファイルシステムが管理する全てのファイルを検出することができるからである。ファイルシステムは、図８に示すコンポーネントでいう分散共有ファイルシステム４１である。

データ処理システム３０は、バックアップを行う対象のファイルを決定する。バックアップを行う対象のファイルは、バックアップ要求を受け付けた時点でmigrated状態またはpre-migrated状態に既に移行しているファイルとすることができる。

データ処理システム３０は、上記のスキャンと同時に、選択ポリシーに基づき、復旧サイトに構築された運用サイトと同じ構成のデータ処理システムで最初に読み出してpre-migrated状態にするファイル、すなわち復旧サイトですぐに使用するファイルを選択し、その選択したファイルのリスト（preferred recallリスト）を作成する。

なお、preferred recallリストを作成する際、ファイルが保存されているテープ・メディア３２を識別するためのテープIDでソート（並べ替え）しておくことが望ましい。リストアする際の読み出し時のパフォーマンスを向上させることができるからである。また、テープ・メディア３２上でファイルが保存されている位置を示すブロック情報（ブロック番号）でソートしておくことがさらに望ましい。ブロック番号の順に読み出しを行うことにより、ファイルの頭出しに要する時間を最小限にすることができるからである。preferred recallリストは、１つのリストとし、テープID毎にグループ化してもよいし、テープID毎にリストをもつようにしてもよい。これらのソートも、バックアップ・ドライバ４６により行うことができる。

次に、符号（１）に示すように、ファイルシステムが備えるinodeバックアップ・コンポーネントにより、全inode情報のバックアップを取る。バックアップ先は、テープ・メディア３２であってもよいし、USBメモリ等の別の記録媒体であってもよい。テープ・メディア３２を用いる場合、１つのテープ・メディア３２のみを使用してもよいし、２以上のテープ・メディア３２を使用してもよい。また、バックアップ先は、記録媒体に限らず、ネットワークを介して復旧サイトへ直接送信し、復旧サイトの共有ディスク４７にバックアップしてもよい。

inode情報のバックアップを取った後、符号（２）に示すように、上記で作成したpreferred recallリストに列挙されているファイルに関するインデックス情報を、共有ディスク３８にあるインデックス・ファイルから抽出する。

抽出したインデックス情報を使用して、preferred recall用インデックス・ファイルを作成する。preferred recall用インデックス・ファイルは、例えば、共有ディスク３８にあるインデックス・ファイルの、preferred recallリストにないファイルの記述を削除することにより作成することができる。

preferred recall用インデックス・ファイルは、preferred recall対象のファイルのパス名を含み、そのインデックス・ファイル名にテープIDを含めておくことができる。これにより、どのテープ・メディア用のインデックス情報かを区別することができる。このpreferred recall用インデックス・ファイルも、inode情報と同様に記録媒体にバックアップし、またはネットワークを介して復旧サイトへ直接送信し、復旧サイトの共有ディスク４７にバックアップすることができる。

ここでは、バックアップ側のデータ処理システムを、データ処理システム３０としているので、共有ディスク３８、共有ディスク４７と区別して示している。

preferred recall用インデックス・ファイルを作成した後、符号（３）に示すように、バックアップを取った全ファイルを格納した全てのテープ・メディア３２、inode情報であるinodeのバックアップ・ファイル、preferred recall用インデックス・ファイルを復旧サイトへ移動する。復旧サイトでは、これらを使用してリストアを行い、ファイルの復旧を行う。記録媒体にバックアップを取った場合は、inode情報、preferred recall用インデックス・ファイルを格納した記録媒体を、復旧サイトへ持っていき、復旧サイトの共有ディスク４７にリストアを行う。

このバックアップ処理の流れを、図１０を参照して詳細に説明する。ユーザからの指示により発行されたバックアップ要求またはスケジュールに従って発行されたバックアップ要求を受け付けることにより、ステップ１０００からバックアップを開始する。データ処理システム３０は、通常の業務において、各ノード３１からファイルの読み書きを行い、ファイルを更新する。このため、ファイルシステムの内容は、常時変化する。そこで、バックアップ対象のファイルを確定するために、最初に、ファイルシステムのスナップショットを取る。

ステップ１００５では、スナップショットを取ったファイルシステムのスキャンを行い、バックアップ対象のファイルを確定する。ファイルシステムのスキャンでは、上記で取ったスナップショット内のファイルの属性を比較し、上記のいずれかの状態にあるファイルをバックアップ対象とする。

ステップ１０１０では、ステップ１００５のスキャンと同時に、選択ポリシーに基づき、業務再開後に復旧サイトでテープ・メディア３２から読み出してpre-migrated状態にするファイルを決定し、その決定したファイルを並べて記述したpreferred recallリストを作成する。

ステップ１０１５では、preferred recallリストを作成する際、ファイルが保存されているテープ・メディア３２のテープID毎にファイルをソートする。すなわち、テープID毎にファイルをまとめ、グループ化する。また、テープ・メディア３２毎にファイルが保存されている位置を示すブロック番号でもソートを行う。すなわち、ブロック番号に従ってファイルを並べ替える。このように、テープID毎にファイルをまとめ、ブロック番号順に並べ替えておくことで、ファイルを読み出す際の読み出し速度を改善し、パフォーマンスを向上させることができる。

ステップ１０２０では、ファイルシステムが備えるinodeバックアップ・コンポーネントを使用して、inode情報のバックアップを取る。バックアップは、記録媒体にinode情報のバックアップ・ファイルを格納することにより行うこともできるし、そのファイルを、ネットワークを介して復旧サイトへ直接送信し、復旧サイトの共有ディスク４７に保存することにより行うこともできる。なお、記録媒体にバックアップを取った場合は、その記録媒体を復旧サイトへ持ち運び、復旧サイトの共有ディスク４７へリストアすることができる。

データの実体は、通常の業務において作成したバックアップ用のテープ・プールにあるテープ・メディア３２群を、復旧サイトへ持ち運び、そのまま使用する。

ステップ１０２５では、共有ディスク３８においてノード間で共有されているインデックス・ファイルから、preferred recallリストに含まれるファイルの情報を抽出し、ステップ１０３０では、抽出したファイルの情報からpreferred recall用インデックス・ファイルを作成する。preferred recall用インデックス・ファイルは、バックアップ対象のファイルが格納された全てのテープ・メディア３２につき作成される。

ノード間で共有されているインデックス・ファイルは、xml形式のファイルとされ、ファイルの情報が記述されており、その記述には、上記のリストに含まれないファイルの情報も含まれる。このステップ１０３０では、ノード間で共有されているインデックス・ファイルから、対象のファイルの情報のみを抜き出して作成することもできるし、対象ではないファイルの情報を削除して作成することもできる。メモリ上に展開されているメタ情報、すなわちdentry情報がある場合は、このdentry情報を基づき、新規にpreferred recall対象のファイルについてのインデックス・ファイルを作成してもよい。

また、ステップ１０３０では、作成するインデックス・ファイルのファイル名にテープIDを含める。これにより、復旧サイトでインデックス・ファイルを、対応するファイルを保存したテープ・メディア３２と関連付けることが容易になる。ここでは、ファイル名により、インデックス・ファイルとテープ・メディア３２とを関連付けているが、これに限定されるものではなく、他の方法により関連付けてもよい。

上記のインデックス・ファイルとテープ・メディア３２との関連付けが終了したところで、ステップ１０３５へ進み、バックアップを終了する。復旧する場合は、復旧サイトへ、ステップ１０２０でバックアップを取ったinode情報と、ステップ１０２５で作成したpreferred recall用のインデックス・ファイルと、バックアップ用のテープ・プールにある全てのテープ・メディア３２とを持っていく。

次に、復旧サイトで行われるリストアについて、図１１を参照して説明する。復旧サイトには、バックアップを取った業務の運用サイトと同じ複数のノードから構成されるクラスタ・システムとしてのデータ処理システム３０が構築される。したがって、復旧サイトのデータ処理システム３０も、複数のノードから読み書き可能な共有ディスク３８と、テープ・ライブラリ３９と、管理システム４０とを備える。テープ・ライブラリ３９は、アーカイブ用のテープ・プールのみを少なくとも備え、必要に応じて、バックアップ用のテープ・プールを備えることができる。テープ・ライブラリ３９に、運用サイトからのバックアップ用のテープ・プールにあった全てのテープ・メディア３２をセットする。

復旧サイトでは、最初に、符号（１）に示すように、運用サイトで取得したinode情報のバックアップ・ファイルを共有ディスク３８に保存し、inode情報のリストアを行う。次に、符号（２）に示すように、テープ・メディア３２をドライブ装置３３に入れ、ロードする。また、作成したpreferred recall用インデックス・ファイルを使用して、preferred recall対象のファイルのメタ情報をメモリ上に展開する。この時点で、preferred recallリストにあるファイルのうち、テープ・メディア３２上にあるファイルは、テープ・ボリューム上のファイルとして認識される。これに対して、preferred recallリストにないファイルは、ファイルシステムに認識されていない。これらのファイルは、メモリ上にメタ情報が展開されていないからである。

テープ・ライブラリ３９にセットされたテープ・メディア３２に格納されているファイルは、preferred recallリストにおいてテープIDによりグループ化され、ブロック番号の順に並べられている。テープIDは、preferred recall用インデックス・ファイルのファイル名に含まれているため、そのファイル名から取得することができる。

次に、符号（３）に示すように、取得したテープIDに基づき、テープ・メディア３２を特定し、preferred recall用インデックス・ファイルに基づき、特定したテープ・メディア３２の先頭から順にファイルを調べ、該当するファイルを読み出す。このファイルの読み出しにより、テープがロードされる。その該当するmigrated状態のファイルは、拡張ファイルシステム４５の管理部４４によりテープから読み出されると、該管理部４４により共有ディスク３８に書き込まれ、pre-migrated状態になる。この処理は、preferred recall用インデックス・ファイルにある１つのテープIDにつき、ファイルの読み出しが終了したところで、次のテープIDにつき、ファイルの読み出しを行う。これを、最後のテープIDにつき完了するまで繰り返す。なお、複数のドライブ装置３３が使用可能な場合は、テープID毎に並列に読み出しを行うことができ、これにより、処理を高速化することができる。

最後に、符号（４）に示すように、preferred recall用インデックス・ファイルは、preferred recall対象のファイルが全て共有ディスク３８上に読み出されたところで、不要になるため削除する。また、メモリ上に展開したメタ情報も削除する。

実際には、テープ用ファイルシステム４２をマウントし、preferred recall対象のファイルのメタ情報をメモリ上に展開し、そのファイルを共有ディスク３８に読み出した後、テープ用ファイルシステム４２を一旦アンマウントし、再びテープ用ファイルシステム４２をマウントする。このアンマウントおよび再度のマウントにより上書きされてpreferred recall用インデックス・ファイルも、メモリ上に展開したメタ情報も削除されるため、それらを削除するための特別な操作は不要である。

このリストア処理の流れを、図１２を参照して詳細に説明する。復旧サイトでは、上述したように、運用サイトと同等のデータ処理システム３０を予め構築しておく。そして、ノード間で共有する共有ディスク３８上にファイルシステム（分散共有ファイルシステム）を作成しておく。また、テープ用ファイルシステム４２をノードのローカルに作成しておく。復旧サイトは、共有ディスク３８、アーカイブ用テープ・プールは必須であるが、バックアップ用テープ・プールは任意で設けることができる。

ステップ１２００からこの処理を開始し、ステップ１２０５では、運用サイトでバックアップ・コンポーネントを使用してバックアップしたinode情報を含むバックアップ・ファイルを共有ディスク３８に保存し、ファイルシステムに組み込まれたリストア・コンポーネントによりinode情報のリストアを行う。inode情報をリストアすることで、ファイルシステム上のファイルは、migrated状態として復旧される。すなわち、ファイルがテープ・メディア３２のみにある状態として復旧される。

復旧サイトのテープ・ライブラリ３９に業務サイトのバックアップ用テープ・プールにあったテープ・メディア３２をセットする。これにより、データ処理システム３０は、テープ・メディア３２の接続を受け付ける。この時点では業務を再開しない。この時点では、まだpreferred recall対象のファイルが共有ディスク３８に読み出されていないからである。ちなみに、この時点で業務を再開し、ファイルシステム上のファイルにアクセスすると、inode情報に書かれているテープIDのテープ・メディア３２からファイルを読み出すことになる。

preferred recall用インデックス・ファイルを共有ディスク３８上にコピーする。１つのノードのみからpreferred recallを行う場合は、共有ディスク３８にコピーする必要はないが、ワークロードを分散するために複数のノードで並列に処理を行う場合は、共有ディスク３８にコピーする必要がある。ステップ１２１０では、preferred recall用インデックス・ファイルのファイル名からテープIDを取得する。

ステップ１２１５では、取得したテープIDをもつテープ・メディア３２が保存するファイルを管理するテープ用ファイルシステム４２をマウントする。このとき、オプションを指定する。通常、テープ用ファイルシステム４２は、そのテープ・メディア３２をロードすると、共有ディスク３８上にコピーしたインデックス・ファイルと、テープ・メディア３２上のインデックス・ファイルとを読み込み、メモリ上にdentryファイルを構築する。このとき、両者が一致しない場合、テープ・メディア３２上のインデックス・ファイルを優先して使用し、マウントを行ってしまう。すると、テープ・メディア３２上のインデックス・ファイルを使用して、そのテープ・メディア３２上の全てのファイルのdentryファイルを生成することになる。

そこで、オプションで、コピーしたインデックス・ファイルを使用してマウントを行うように指定し、テープ・メディア３２上のインデックス・ファイルを使用してマウントを行う設定からコピーしたインデックス・ファイルを使用してマウントを行う設定に切り替える。これにより、テープ・メディア３２上のインデックス・ファイルを無視し、これに代えて、共有ディスク３８上にコピーしたインデックス・ファイルでメモリ上にdentryファイルを構築するようになる。このため、preferred recall対象のファイルのうち、そのテープIDをもつテープ・メディア３２に格納されたファイルについてのdentryファイルのみをメモリ上に構築する。

テープ用ファイルシステム４２は、共有ディスク３８上にdcacheファイルを構築せずにマウントするオプションを用意している。通常の業務においては、ファイルを読み出す際等にノード間でdcacheファイルを共有する必要があるが、preferred recallでは、ノード間でdcacheファイルを共有する必要がないので、このオプションを指定して、テープ用ファイルシステム４２をマウントする。これにより、必要なdentryファイルの生成のみを行い、dcacheファイルは構築しないようにすることができる。

ステップ１２２０では、管理システム４０が備える拡張ファイルシステム４５を起動し、preferred recall対象のファイルのうち、そのテープIDをもつテープ・メディア３２に保存されたファイルのメタ情報、すなわちdentry情報をメモリ上に展開し、そのファイルをそのテープ・メディア３２から読み出すことにより、共有ディスク３８に書き込まれる。これにより、そのファイルをrecallし、pre-migrated状態にする。このとき、拡張ファイルシステム４５がメタ情報の拡張属性として持っている、テープ・メディア３２上でファイルが存在している位置情報を考慮し、読み出す順番を決定することで、高速に読み出すことができる。

ファイルは、preferred recall用インデックス・ファイルにおいて、グループ化されたテープID毎にソートされている。ステップ１２２５では、拡張ファイルシステム４５は、全てのテープIDにつき、preferred recallが完了したかを判断する。まだ完了していない場合は、ステップ１２１０へ戻り、次のテープIDをもつテープ・メディア３２についてpreferred recallを実行する。複数のノード３１からpreferred recallを行う場合、テープIDのグループの区切りで分割し、各ノード３１で各テープIDにつき並列して実行することができる。このように並列して実行することにより、より短時間に復旧することができ、早期に業務を再開することが可能になる。

ここで、migrated状態にあるファイルへのアクセスについて、図１３を参照して説明する。ファイルシステム上のファイルは、ファイルシステムとしてGPFSを使用する場合、「/gpfs」というディレクトリの下位層にファイルが示される。テープ用ファイルシステム４２としてLTFSを使用する場合、テープ・ライブラリ３９を作成したディレクトリ「/ltfs」をマウント・ポイントとしてマウントし、テープIDをもつディレクトリの下に、そのテープ上のファイルが示される。

migrated状態にあるファイルは、上位層のGPFSにinodeのみがあり、ファイルの実体は、テープ上に存在している状態である。このファイルにアクセスすると、inodeの属性に書かれているテープ上のファイルの実体のみが読み出され、GPFSのファイルシステム上にコピーされてpre-migrated状態になる。

例えば、ユーザがGPFSのファイル「/gpfs/dir1/file3」にアクセスするものとする。すると、データ処理システム３０は、preferred recall用インデックス・ファイルにおいてファイル名からテープIDを取得する。テープIDが「tapeA」である場合、「tapeA」をもつテープ・メディア３２の「/ltfs/tapeA/dir1/file3」にアクセスする。図１３に示す例では、このファイルが、別名であるシンボリック・リンクになっているため、そのファイルの実体が存在するtapeAのフォルダ「.LTFSEE_DATA」にあるファイルから読み出しが行われる。

再び図１２を参照して、ステップ１２２５で完了したと判断した場合、ステップ１２３０へ進み、拡張ファイルシステム４５を停止し、テープ用ファイルシステム４２をアンマウントする。このアンマウントにより、インデックス・ファイルからメモリ上に展開したメタ情報が消滅する。

テープ用ファイルシステム４２を、dcacheファイルを構築せずにマウントするオプションを指定せずにマウントし、拡張ファイルシステム４５を起動し、ステップ１２３５でリストアを終了する。すなわち、テープ・メディア３２上のインデックス・ファイルを使用してマウントを行う設定に切り替える。テープ用ファイルシステム４２をマウントした後、preferred recallされていないファイルにアクセスされたとき、そのファイルが格納されているテープ・メディア３２上のインデックス・ファイルから、そのファイルのメタ情報をメモリ上に展開する。共有ディスク３８上には、dcacheファイルが構築されるので、そのファイルへのアクセスが可能になる。アクセスが可能になった時点で、通常の業務を再開することができる。

このリストア後は、preferred recall対象のファイルも、非対象のファイルも読み出すことができる。preferred recall対象のファイルは、すでに共有ディスク３８上にあり、pre-migrated状態になっているので、共有ディスク３８からファイルを読み出すことができる。

非対象のファイルは、テープ・メディア３２から一旦共有ディスク３８に読み出し、共有ディスク３８に書き込まれた上で、共有ディスク３８から読み出される。inode情報の拡張属性には、そのファイルが保存されているテープ・メディア３２のテープIDが書かれている。拡張ファイルシステム４５は、このテープIDをもつテープ・メディア３２から読み出しを行うが、この時点ではまだメタ情報がメモリ上に展開されていない。このため、そのテープ・メディア３２をマウントし、そのテープ・メディア３２のインデックス・パーティションからメタ情報を読み出し、それをメモリ上に展開し、それと同時に、共有ディスク３８上にインデックス・ファイルを構築する。

テープ・メディア３２は、ノード３１からファイルへのアクセスが発生した場合にロードされ、テープ用ファイルシステム４２は、そのテープのインデックス情報を読み出し、マウントされる。このため、バックアップの時点では、インデックス全体を予めバックアップとして取っておく必要はない。

アクセスされたファイルは、テープ・メディア３２から読み出され、共有ディスク３８上に保存される。そして、ファイルの状態が、pre-migrated状態に変更される。ここで、ファイルへの書き込みが行われると、ファイルの状態はresidentに遷移する。resident状態とは、ドライブ装置３３上のファイルが削除されて、共有ディスク３８上にのみファイルの実体が存在している状態である。

なお、バックアップでは、preferred recall対象のファイルのインデックスを保存しているが、これに限られるものではなく、dentry情報を保存してもよい。実際にシミュレーションを実施し、検証を行ってみると、インデックス・ファイルからリストアしたほうが早く復旧することができることが分かった。したがって、preferred recall用インデックス・ファイルを保存するほうが望ましい。

以上に説明してきたように、本発明のデータの復旧方法、その方法をデータ処理システムに実行させるためのプログラムおよびデータ処理システムを提供することにより、復旧後にすぐに使用すると予想されるファイル以外のファイルのメタ情報をメモリ上に展開する必要がないため、その分の時間を短縮することができる。また、dcacheファイルを共有ディスク上に作成する必要もないため、その分の時間も短縮することができる。したがって、復旧サイトにおいて業務を再開するまでにかかる時間を短縮することができる。

具体例で説明すると、共有ディスク３８上にdcacheファイルを構築する時間は、メタ情報をメモリ上に展開する時間に比べて１０倍以上の時間がかかることが知られている。例えば、１００万のファイルが保存されているテープ・メディア３２をマウントする場合、共有ディスク３８上にdcacheファイルを構築するには数時間かかるのに対し、メタ情報をメモリ上に展開する時間は１０分程度で済む。本発明では、この共有ディスク３８上にdcacheファイルを構築する必要がないので、この時間分短縮することができる。

本発明では、メタ情報をメモリ上に展開するが、全ファイルのメタ情報ではなく、preferred recall対象のファイルのメタ情報のみである。preferred recall対象のファイルは、例えば、全体の０．１％のファイルといったように全ファイルに比較して大幅に少ない数のファイルである。したがって、１００万ファイルでは１０分程度かかるが、１００万ファイルの０．１％では１０００ファイルであり、そのメモリ上への展開には１秒以下の時間しかかからない。

上記の例では、全ファイルの０．１％をpreferred recall対象としたが、仮に全ファイルをpreferred recall対象とした場合であっても、メタ情報のメモリ上への展開は必要であるが、その展開より１０倍以上の時間がかかる共有ディスク３８上へのdcacheファイルの構築が不要であるため、業務再開までにかかる時間を大幅に短縮することができる。

これまで、本発明のデータの復旧方法、プログラムおよびデータ処理システムについて、図面を参照して詳細に説明してきたが、他の実施形態や、追加、変更、削除など、当業者が想到することができる範囲内で変更することができ、いずれの態様においても本発明の作用・効果を奏する限り、本発明の範囲に含まれるものである。

１０、１３…ファイルシステム、１１、１４…ディスク、１２、１５…テープ・プール、１６…テープ・メディア、１７…テープ、１８…インデックス・パーティション、１９…データ・パーティション、２０…共有ディスク、２１…dentriesファイル、３０…データ処理システム、３１…ノード、３２…テープ・メディア、３３…ドライブ装置、３４…CPU、３５…メモリ、３６…記憶装置、３７…入出力I/F、３８…共有ディスク、３９…テープ・ライブラリ、４０…管理システム、４１…分散共有ファイルシステム、４２…テープ用ファイルシステム、４３…階層ディスク記憶管理部、４４…管理部、４５…拡張ファイルシステム、４６…バックアップ・ドライバ、４７…共有ディスク

Claims (21)

1. 複数のデータをデータ処理システムに復旧する方法であって、
   前記データ処理システムが、
   前記複数のデータの各々に関連付けられた記録媒体を識別するための媒体識別情報を含む該複数のデータを複数のファイルとして管理するための管理情報を、前記データ処理システムが備える記憶装置に記憶して該管理情報を復旧するステップと、
   前記複数のファイルと該複数のファイルに関する情報とが記憶された複数の前記記録媒体の接続を受け付けるステップと、
   １以上の前記媒体識別情報を含む前記複数のファイルのうちの１以上のファイルに関する情報を、前記記憶装置に記憶するステップと、
   前記複数の記録媒体に記憶されている前記複数のファイルに関する情報に代えて、前記記憶装置に記憶された前記１以上のファイルに関する情報を使用してファイルを読み出す設定に切り替えるステップと、
   前記１以上のファイルに関する情報に基づき、ファイルを読み出す１以上の記録媒体を特定し、特定した該１以上の記録媒体から１以上のファイルを前記記憶装置へ読み出すステップと、
   前記１以上のファイルに関する情報を前記記憶装置から削除するステップとを含む、データの復旧方法。
2. 前記複数の記録媒体に記憶されている前記複数のファイルに関する情報を使用してファイルを読み出す設定へ切り替えるステップをさらに含む、請求項１に記載のデータの復旧方法。
3. 前記記録媒体は、ファイルに関する情報を記憶するための第１のパーティションと、ファイルを記憶するための第２のパーティションとを有する磁気テープ媒体である、請求項１に記載のデータの復旧方法。
4. 前記１以上のファイルに関する情報は、前記１以上のファイルの属性情報を含み、該１以上のファイルの属性情報が複数である場合、前記媒体識別情報毎に、前記磁気テープ媒体に記憶されるファイルの位置を示すブロック情報に従って並べられている、請求項３に記載のデータの復旧方法。
5. 前記読み出すステップでは、前記データ処理システムが処理を実行するために使用する記憶領域に前記１以上のファイルの属性情報を読み出し、該記憶領域に読み出した該属性情報を使用して前記特定した１以上の記録媒体から前記１以上のファイルを読み出す、請求項４に記載のデータの復旧方法。
6. 前記削除するステップでは、前記記憶領域に読み出した前記１以上のファイルの属性情報を削除する、請求項５に記載のデータの復旧方法。
7. 前記複数のファイルを保持し、該複数のファイルを前記複数の記録媒体へ書き込む処理を実行する第２データ処理システムが、
   予め設定された選択ポリシーに基づき、前記複数のファイルから１以上のファイルを抽出し、該１以上のファイルのリストを生成するステップと、
   前記リストに基づき、前記複数の記録媒体に前記複数のファイルとともに記憶された該複数のファイルに関する情報または前記第２データ処理システムが処理を実行するために使用する記憶領域に読み出した前記複数のファイルの属性情報を使用して、前記複数の記録媒体の少なくとも１つを識別するための媒体識別情報を含む前記１以上のファイルに関する情報を生成するステップとをさらに含む、請求項１に記載のデータの復旧方法。
8. 前記記録媒体は、ファイルに関する情報を記憶するための第１のパーティションと、ファイルを記憶するための第２のパーティションとを有する磁気テープ媒体であり、
   前記１以上のファイルが複数である場合、前記リストを生成するステップでは、複数の該ファイルを、前記媒体識別情報毎に、前記磁気テープ媒体に記憶されるファイルの位置を示すブロック情報に従って並べることにより該リストを生成する、請求項７に記載のデータの復旧方法。
9. 前記１以上のファイルに関する情報は、前記複数の記録媒体の少なくとも１つもしくは該複数の記録媒体とは別の記録媒体またはネットワークを介して前記データ処理システムへ送られる、請求項７に記載のデータの復旧方法。
10. バックアップ要求を受け付けるステップと、
    前記バックアップ要求を受け付けた時点の前記第２データ処理システムが保持する前記複数のファイルを管理するファイルシステムのスナップショットを取るステップと、
    得られた前記スナップショットに基づき、バックアップ対象の複数のファイルを決定するステップと、
    決定した前記バックアップ対象の複数のファイルを管理するための管理情報をバックアップするステップとをさらに含む、請求項７に記載のデータの復旧方法。
11. 複数のデータを復旧する処理をデータ処理システムに実行させるためのプログラムであって、
    前記複数のデータの各々に関連付けられた記録媒体を識別するための媒体識別情報を含む該複数のデータを複数のファイルとして管理するための管理情報を、前記データ処理システムが備える記憶装置に記憶して該管理情報を復旧するステップと、
    前記複数のファイルと該複数のファイルに関する情報とが記憶された複数の前記記録媒体の接続を受け付けるステップと、
    １以上の前記媒体識別情報を含む前記複数のファイルのうちの１以上のファイルに関する情報を、前記記憶装置に記憶するステップと、
    前記複数の記録媒体に記憶されている前記複数のファイルに関する情報に代えて、前記記憶装置に記憶された前記１以上のファイルに関する情報を使用してファイルを読み出す設定に切り替えるステップと、
    前記１以上のファイルに関する情報に基づき、ファイルを読み出す１以上の記録媒体を特定し、特定した該１以上の記録媒体から１以上のファイルを前記記憶装置へ読み出すステップと、
    前記１以上のファイルに関する情報を前記記憶装置から削除するステップとを実行させる、プログラム。
12. 前記複数の記録媒体に記憶されている前記複数のファイルに関する情報を使用してファイルを読み出す設定へ切り替えるステップをさらに実行させる、請求項１１に記載のプログラム。
13. 前記記録媒体は、ファイルに関する情報を記憶するための第１のパーティションと、ファイルを記憶するための第２のパーティションとを有する磁気テープ媒体である、請求項１１に記載のプログラム。
14. 前記１以上のファイルに関する情報は、前記１以上のファイルの属性情報を含み、該１以上のファイルの属性情報が複数である場合、前記媒体識別情報毎に、前記磁気テープ媒体に記憶されるファイルの位置を示すブロック情報に従って並べられている、請求項１３に記載のプログラム。
15. 前記読み出すステップでは、前記データ処理システムが処理を実行するために使用する記憶領域に前記１以上のファイルの属性情報を読み出し、該記憶領域に読み出した該属性情報を使用して前記特定した１以上の記録媒体から前記１以上のファイルを読み出す処理を実行させる、請求項１４に記載のプログラム。
16. 前記削除するステップでは、前記記憶領域に読み出した前記１以上のファイルの属性情報を削除する処理を実行させる、請求項１５に記載のプログラム。
17. 複数のデータを保持し、複数の記録媒体へ該複数のデータを複数のファイルとして書き込むデータ処理システムに実行させるためのプログラムであって、
    予め設定された選択ポリシーに基づき、前記複数のファイルから１以上のファイルを抽出し、該１以上のファイルのリストを生成するステップと、
    前記リストに基づき、前記複数の記録媒体に前記複数のファイルとともに記憶された該複数のファイルに関する情報または前記データ処理システムが処理を実行するために使用する記憶領域に読み出した前記複数のファイルの属性情報を使用して、前記複数の記録媒体の少なくとも１つを識別するための媒体識別情報を含む前記１以上のファイルに関する情報を生成するステップとを実行させる、プログラム。
18. 前記記録媒体は、ファイルに関する情報を記憶するための第１のパーティションと、ファイルを記憶するための第２のパーティションとを有する磁気テープ媒体であり、
    前記１以上のファイルが複数である場合、前記リストを生成するステップでは、複数の該ファイルを、前記媒体識別情報毎に、前記磁気テープ媒体に記憶されるファイルの位置を示すブロック情報に従って並べることにより該リストを生成する処理を実行させる、請求項１７に記載のプログラム。
19. バックアップ要求を受け付けるステップと、
    前記バックアップ要求を受け付けた時点の前記データ処理システムが保持する前記複数のファイルを管理するファイルシステムのスナップショットを取るステップと、
    得られた前記スナップショットに基づき、バックアップ対象の複数のファイルを決定するステップと、
    決定した前記バックアップ対象の複数のファイルを管理するための管理情報をバックアップするステップとをさらに実行させる、請求項１７に記載のプログラム。
20. 複数のデータを復旧する処理を行うデータ処理システムであって、
    前記複数のデータを複数のファイルとして処理を実行する１以上の処理装置と、
    前記１以上の処理装置の各々が前記複数のファイルに対して処理を実行するための１以上の記憶領域を提供する１以上のメモリと、
    請求項１１〜１６のいずれか１項に記載の前記１以上の処理装置により実行されるプログラムを記憶し、作成された前記１以上のファイルに関する情報および前記１以上のファイルを記憶することが可能な記憶装置と、
    前記１以上の処理装置からの命令に基づき、前記複数のファイルが記憶された複数の記録媒体の少なくとも１つに対してファイルの読み書きを行うドライブ装置とを含む、データ処理システム。
21. 複数のデータを保持し、前記複数の記録媒体へ該複数のデータを書き込むデータ処理システムであって、
    前記複数のデータを複数のファイルとして処理を実行する１以上の処理装置と、
    前記１以上の処理装置の各々が前記複数のファイルに対して処理を実行するための１以上の記憶領域を提供する１以上のメモリと、
    請求項１７〜１９のいずれか１項に記載の前記１以上の処理装置により実行されるプログラムと、前記複数のファイルとを記憶する記憶装置と、
    前記１以上の処理装置からの命令に基づき、前記複数の記録媒体の少なくとも１つに対してファイルの読み書きを行うドライブ装置とを含む、データ処理システム。