JP2007141231A - データをバックアップするための方法、システム、およびコンピュータ・プログラム - Google Patents

Abstract

【課題】 複数のゲスト計算機を別のホスト計算機が、支援するデータ処理システムに用いられるバックアップ・ソリューションを提示する。
【解決手段】 ホスト装置のうちの一つであるマスタ装置は、どのゲスト・システムが、そのデータをバックアップできるようになっているのか、またいつバックアップ処理を実施しなければならないのかを示すスケジューリング・ファイルを有している。毎日、ホスト装置は互いに、対応するゲスト装置が当日のスケジューリング・ファイルに含まれているか否かを検証する。含まれている場合、バックアップするそれぞれのデータのパスが、マスタ・ホスト装置の制御ファイルに追加される。手順の最後に、マスタ・ホスト装置は、（制御ファイルに表示されているように）別のゲスト装置の必要なデータをバックアップする。クリティカル・ゲスト装置はいずれも、自動的にシャットダウンして、対応するバックアップ・データの整合性を確保する。
【選択図】 図３

Description

本発明は、情報技術分野に関する。さらに具体的には、本発明は、データのバックアップに関する。

データのバックアップは、現代のデータ処理インフラストラクチャの管理において重要な役割を果たしている。一般に、データのバックアップ処理は、オリジナル・ソースの一つ以上の追加コピーを別の装置に作成することによって実施される。安全上の理由から、バックアップ用のコピーは、元データの場所と異なる場所に保存することが望ましい。このようにデータが保存されることによって、（メモリ破壊などの）インフラ障害、（火災などの）災害、偶発的な不正削除などの場合にデータの原本が破損したり、失われたりしたとしても、そのデータを復元（すなわち再生）することができる。

バックアップ処理は、大規模な組織では、日常業務として実施されている（クリティカル・データやサービスを扱っている場合は、特にそうである）。しかし、適切なバックアップ処理の設計は非常に複雑な作業である。実際、このために、多数の問題を慎重に検討する必要が生じている。例えば、バックアップ媒体を適切に選択すること、コピーしたデータの整合性を確保すること、効率的なバックアップ手順を定義すること、正しい再生の方針を確立すること、バックアップ・コピーの保全性と有効性を検証すること等々は極めて重要である。

バックアップすべきデータが複数のコンピュータに保存されている分散インフラストラクチャでは、さらに新たな問題が起こっている。特に、このような状況下では、分散インフラストラクチャは本来散在しているので、全てのバックアップ処理を制御することは極めて難しい。例えば、別のコンピュータ上のバックアップ処理のスケジューリングは、全く分からない。上記の問題は、コンピュータが、別種類のハードウェアおよび／またはソフトウェア・プラットフォームを実行している異種環境下では、さらに深刻である。

上述のシナリオにおいて、バックアップ処理を別のコンピュータの中央のサイト（ｃｅｎｔｒａｌ ｓｉｔｅ）から、完全に強制的に実施することは、通常は許容されない点に留意するべきである。実際のところ、最も現実的な状況下では、バックアップされるデータの定義は、常にローカル制御下に留めておかなければならないのである。

業界で知られたソリューションのもう一つの課題は、そのソリューションがかなり侵襲的（ｉｎｖａｓｉｖｅ）なものであるということである。バックアップ処理には、一般に、各コンピュータ上において、バックアップ処理を管理するのに必要なすべての操作の実行を担当する比較的複雑なエージェントを使用できることが必要である。しかし、常にこのエージェントをインフラストラクチャの全てのコンピュータにインストールできるわけではない。例えば、インストールは、安全上の懸念から許容されない場合もある。

いずれの場合でも、バックアップ処理中は、できるだけ人間の介入に依存しないことが望ましい。人間の行動は殆ど反復不能で誤りを犯しやすく、かつ個人の技量に強く依存している。しかし、このように、分散アーキテクチャを備えたインフラストラクチャの自動バックアップ処理の設計は、上記の問題により妨げられる。

本発明は、独立請求項に記載のソリューションを提案する。また、本発明の有利な実施態様が、従属請求項に記述される。

原則として、本発明は中央制御によるバックアップ処理を提案している。

本発明の態様では、データを処理する複数のエンティティ（例えば、物理的なおよび／または論理的な装置（ｐｈｙｓｉｃａｌ ａｎｄ／ｏｒ ｌｏｇｉｃａｌ ｍａｃｈｉｎｅｓ））を含むシステムにおいて、データをバックアップする方法が提供される。方法には、複数のエンティティのセット（それらの内の１つから全部まで）についての一連のステップが含まれる。まず、スケジューリング構造（例えば、ファイル）が、エンティティのうち選択されたエンティティに備えられる。スケジューリング構造には、対応するデータをバックアップ可能なエンティティの記述（ｉｎｄｉｃａｔｉｏｎ）が含まれる。次に、方法は、スケジューリング構造内の各エンティティが含まれていることを検証することによって継続する。含まれていることに応じて、各バックアップ可能なエンティティは、対応するデータの記述を、選択されたエンティティ上の制御構造（例えば別のファイル）に付加する。方法は、制御構造に記述されるデータを、選択されたエンティティの制御に基づいてバックアップしたあとで終了する。

スケジューリング・ファイルは、各バックアップ可能なエンティティに対するスケジューリング・ポリシーを定めるためにも用いられることが好ましい。また、スケジューリング・ファイルへ含まれていることの検証は、各エンティティの制御の下で定期的に実行されることが好ましい。さらに好ましくは、エンティティは相互にタイミングをずらして（ｏｕｔ−ｏｆ−ｐｈａｓｅ）ステップを実行する。

ソリューションをさらに改良する方法としては、クリティカル・エンティティのシャットダウン時間を設定するために、スケジューリング構造を用いることである。

具体的な実施形態では、本発明は、（対応するゲスト計算機に関する上述の操作の実行を制御する）ホスト計算機に実装されるゲスト計算機に適用される。

有利には、スケジューリング・ファイルと、制御ファイルと、バックアップされるデータとが、共用ディスクに保存されている。

さらなる拡張として、提案されているソリューションでは、同一の共用ディスク（制御ファイルに複写されている）の反復バックアップが防止される。

さらに本発明の他の態様では、この方法を実行するためのコンピュータ・プログラムが提案される。

さらに本発明の他の態様では、対応するシステムが提案される。

本発明は、さらなる特徴及びその利点とともに、非制限的な表現によって純粋に記述されている。本発明は、添付図面と併せて、以下の発明の実施形態の詳細な説明を読むことによって、最もよく理解されるであろう。

図１は、分散アーキテクチャを備えたデータ処理インフラストラクチャ１００を図示する。インフラストラクチャ１００は、複数の物理コンピュータ１０５（例えば、ＩＢＭ社の『ｚＳｅｒｉｅｓ（Ｒ）』または『ＡＳ／４００（Ｒ）』タイプ）を含む。各コンピュータ１０５は、データ処理エンティティである複数の論理システム１１０を実装する。このために、別のコンピュータとして独立して動作するコンピュータ１０５は、対応する論理パーティション（ＬＰＡＲ）に分割され、各パーティションは、コンピュータ１０５のハードウェア資源のサブセットで構成される。同様に、各ホスト・システム１１０は、複数のゲスト・システム１１５をサポートする。特に、ホスト・システム１１０は、対応する仮想計算機を備える。そして、各仮想計算機は、仮想計算機が独占的に制御する現実のコンピュータの様相（ａｐｐｅａｒａｎｃｅ）を与える抽象的環境（ａｂｓｔｒａｃｔ ｅｎｖｉｒｏｎｍｅｎｔ）から構成される。

コンピュータ１０５は、典型的には磁気ディスクから構成されるある配列のダイレクト・アクセス記憶装置（ＤＡＳＤ）１２０を共用している。共用ディスク１２０では、かなり大量のデータ（例えばＩＢＭ社の３３９０−３タイプのディスクでは、３ギガ・バイト、３３９０−３タイプでは１０ギガ・バイトなど）に高速アクセスできる。共用ディスク１２０は、論理システム１１０，１１５のローカル・データを保存するのに用いられる。ローカル・データは、別のファイル・システムに従って編成される（なお、各ファイル・システムは、対応する論理システム１１０，１１５のソフトウェア・プラットフォームに依存している）。さらに、共用ディスク１２０は、より大きな論理システム１１０，１１５が、読み出しおよび／または書き込みアクセスができるグローバル・データを保存することもある。このために、インフラストラクチャ１００は、共用ファイル・システム・サービスを実装する。共用サービスにより、各論理システム１１０、１１５はそのファイル・システム（あるいはその一部のシステム）を、他の論理システム１１０、１１５にエキスポートできるようになる。エキスポート先の論理システム１１０、１１５はエキスポートされたデータを組み込んで、そのファイル・システムに完全に一体化する。この結果は、別の論理システム１１０、１１５上で実行される対応クライアント／サーバ・モジュールの手段により達成される。また、これらのモジュールは、プラットフォーム独立型になるように設計された対応プロトコル（例えばＴＣＰ／ＩＰ）を介して通信する。好適な共用サービスの例としては、ネットワーク・ファイル・システム（ＮＦＳ）がある。

以下に詳述するように、共用ディスク１２０のデータは、典型的には磁気テープ・カートリッジ（あるいはストリーマ）から構成されるリムーバブル・メディア１２５にバックアップされる。テープ１２５は大変安価であり、大量の順次アクセスの記憶容量を有する（例えば、ＩＢＭ社の３５９０タイプのテープは、１０ギガ・バイトある）。バックアップ処理は、共用ディスク１２０からテープ１２５へ直接実行することもできる。他の方法として、バックアップするデータを、適切に処理して、ある配列のリポジトリ・ディスク１３０に一旦保存し、次にリポジトリ・ディスク１３０に保管した処理済みのデータを、テープ１２５にコピーするようにすることができる。

図２に移って、上述のインフラストラクチャ上で実行される主要なソフトウェア・コンポーネントが、まとめて２００として参照される。情報（プログラムおよびデータ）は、典型的には、共用ディスクに保存され、プログラムを実行する際に、少なくとも部分的には、各コンピュータのメモリ（すなわちＲＡＭ）に読み込まれる。プログラムは最初に、例えばテープから共用ディスクにインストールされる。

特に、各コンピュータ１０５上のパーティション層（ｐａｒｔｉｔｉｏｎｉｎｇ ｌａｙｅｒ）２０５は、コンピュータ１０５を複数の論理パーティションに分割することによって、対応するホスト・システムをシミュレートする。各論理パーティションは、コンピュータ１０５のハードウェア資源の専用サブセットを制御する。以下に詳述するように、ホスト・システムのうちの一つのシステム（以後マスター・システム１１０ｍと記述する）は、その他のすべてのホスト・システム（以後従属システム１１０ｓと記述する）のバックアップ処理を制御する。特に、マスター・システム１１０ｍは、他の従属システム１１０ｓのゲスト・システム１１５のバックアップ処理スケジュールを共用ファイル内に記述する。各従属システム１１０ｓは定期的に、そのデータを本共用ファイルの内容に従ってバックアップすべきか否か検証する。バックアップが必要な場合、従属システム１１０ｓは、他の共用ファイルにバックアップするデータを特定する。手順の最後に、マスター・システム１１０ｍは、別のゲスト・システム１１５の必要なデータをバックアップできる。

提案したソリューションによって、バックアップ処理の集中制御が可能になる。特に、別のゲスト・システム１１５上で、バックアップ処理のスケジューリングを、極めて効果的な方法で管理することができる。この成果は、別のゲスト・システム１１５によってサポートされるファイル・システムに無関係に達成される。換言すれば、考案されたバックアップ処理は、本質的にプラットフォームには依存しない。それに加えて、バックアップされるデータの制御は、完全にローカルのままである。

この技法には、別の従属システム１１０ｓに、非常に簡単なプログラムをインストールするだけでよい。一方、バックアップ処理のコア・モジュールは、マスター・システム１１０ｍだけに必要になる。この結果、従属システム１１０ｓに及ぼす影響はごくわずかである。その上、別のゲスト・システム１１５には、追加コンポーネントはまったく必要ない。これにより、提案されているソリューションは、厳しいセキュリティ要件を有する適用に好適なものとなる。

上述のバックアップ処理は、最初の設定をしたあとはいかなる人間の介入をも必要としないということが重視されている。その結果、提案したソリューションは、完全に自動化されている。これにより、結果の品質が改善されるとともに、誤りの要因も大幅に軽減されることになる。

ここで、汎用の従属システム１１０ｓについてさらに詳しく考察する。バーチャリゼーション層（ｖｉｒｔｕａｌｉｚａｔｉｏｎ ｌａｙｅｒ）２１０ｓは、多数の仮想計算機を用いて、対応ゲスト・システム１１５をシミュレートする。このような機能を備えた市販のバーチャリゼーション層２１０ｓの例としては、ＩＢＭ社の『ＶＭｗａｒｅ（Ｒ）』や、マイクロソフト社の『マイクロソフト・バーチャル・サーバ２００５（ＭＳＶＳ）（Ｒ）』などがある。

各ゲスト・システム１１５において、オペレーティング・システム２１５（例えば、ＩＢＭ社の『ｚ／ＯＳ（Ｒ）』や『Ｌｉｎｕｘ（Ｒ）』など）は、ソフトウェア・プラットフォームを定める。上記で指摘したように、オペレーティング・システム２１５は、あたかもバーチャリゼーション層２１０ｓによりシミュレートされる現実のコンピュータ（ｒｅａｌ ｃｏｍｐｕｔｅｒ）上にインストールされたように動作する。ソフトウェア・アプリケーション２２０は、オペレーティング・システム２１５上で実行される。各ソフトウェア・アプリケーション２２０は、対応する作業データ２２５（例えば、ファイル、データベースなど）を持っている。

従属システム１１０ｓ上で実行される全てのゲスト・システム１１５についての構成情報は、バーチャリゼーション層２１０ｓによって、対応ファイル２３０に保存される。構成ファイル２３０は、典型的には、各ゲスト・システム１１５に割り当てられた従属システム１１０ｓのハードウェア資源を記述する。特に、本構成情報には、ゲスト・システム１１５が、そのデータ（例えば、オペレーティング・システム２１５、ソフトウェア・アプリケーション２２０、及び作業データ２２５）を保存するのに用いる各共用ディスクの識別子（ＩＤ）（すなわち、その絶対パス）が含まれる。

従属システム１１０ｓで実行されるバックアップ・スクリプト２３５は、バックアップ処理のクライアントとして、マスター・システム１１０ｍと連動している。バックアップ・スクリプト２３５（例えば、ＲＥＸＸ言語で書かれている）は、小さなプログラムから構成され、一般的にはユーザとのいかなる対話をすることなく実行されることを意図した一連のコマンドで形成されている。このために、バックアップ・スクリプト２３５は、構成ファイル２３０に（読み出し専用モードで）アクセスする。

マスター・システム１１０ｍに移って、同様のバーチャリゼーション層２１０ｍが、多数の仮想計算機を同様にシミュレートする。バックアップ・マネージャ２４０（マスター・システム１１０ｍ内で実行される）は、全ての従属システム１１０ｓのバックアップ処理のサーバー側を実行する。典型的には、バックアップ・マネージャ２４０は、バックグラウンドで継続的に稼動するエージェントから成る。

バックアップ・マネージャ２４０は、スケジューリング・ファイル２４５（例えば、エディタを用いて作成される）を制御する。スケジューリング・ファイル２４５は、別の従属システム１１０ｓ上のどのゲスト・システム１１５（対応するＩＤにより特定される）が、そのデータをバックアップできるのか、またいつバックアップ処理を実行すべきなのかを表現している。このために、スケジューリング・ファイル２４５は、それぞれのバックアップ可能なゲスト・システム１１５のバックアップ処理回数を保存することが好ましい。これに加えて、スケジューリング・ファイル２４５は、ゲスト・システム１１５がオフの時にバックアップ処理を実行しなければならないクリティカル・ゲスト・システム１１５を識別できる。このことは、例えば、トランザクションが別のメモリ構造に影響を及ぼす場合などに、バックアップされたデータが、常に確実に整合するようにするために必要なことである。各クリティカル・システム１１５について、スケジューリング・ファイル２４５は、ゲスト・システム１１５をシャットダウンしなければならない時間（時分）を記憶している。例えば、「Ｈ１」と命名した従属システム１１０ｓ上の、「Ｇ１」と命名した重要ゲスト・システム１１５を毎日バックアップしなければならず、他方、「Ｈ２」と命名した別の従属システム１１０ｓが、さほど重要性のないゲスト・システム１１５、すなわち、「Ｇ２ａ」と命名したゲスト・システム１１５（これは週に一度バックアップしなければない）と、「Ｇ２ｂ」と命名したゲスト・システム１１５（これは月に一度バックアップしなければならない）をホストするという状況について、検討してみることとする。ゲスト・システム「Ｇ１」はクリティカルであり、そのシャットダウン時間は、「２２時００分」である。この場合、年全体のスケジューリング・ファイル２４５は次の表で定められる。

各従属システム１１０ｓのバックアップ・スクリプト２３５がスケジューリング・ファイル２４５を読み込む。それぞれが従属システム１１０ｓのホストとなっているゲスト・システム１１５が、現在の日付のスケジューリング・ファイル２４５にバックアップ回数に基づき表現された場合、バックアップ・スクリプト２３５は、ゲスト・システム１１５がデータ保存用に使用する共用ディスクのＩＤを構成ファイル２３０から抽出する。本情報は、マスター・システム１１０ｍにも保存されている制御ファイル２５０に付加される。このようにすることによって、この手順の終わりには、制御ファイル２５０は、バックアップされるインフラストラクチャ内のすべての共用ディスクのリストを含むこととなる。

制御ファイル２５０は、バックアップ処理を相応に制御するバックアップ・マネージャ２４０によってアクセスされる。このために、バックアップ・マネージャ２４０は、マスター・システム１１０ｍ（例えば４〜８のような）のホストになっている専用仮想計算機２５５のプール（ｐｏｏｌ）を活用する。各仮想計算機２５５は、ネイティブ・モードでロボット２６０を作動する。ロボット２６０は、人間のいかなる介入もなく自動的に動作する、必要なデータをテープ１２５にコピーするプログラムから成っている。バックアップ・マネージャ２４０は、制御ファイル２５０に表現されている特定の大容量共用ディスクをバックアップするために、選択されたロボット２６０を直接呼び出すことができる。その代わりに、バックアップ・マネージャ２４０は、小容量共用ディスクをコピーしなければならないときは、マスター・システム１１０ｍのホストとなっているさらに専用的な仮想計算機２６５（例えば８〜１５のような）のプールを活用する。各仮想計算機２６５は、ネイティブ・モードで圧縮ユーティリティ２７０を実行し、圧縮ユーティリティ２７０は、多数の共用ディスクを圧縮するとともに、リポジトリ・ディスクに保存される単一イメージ・ファイル２７５（例えば、ＣＭＳファイル）に結合する。圧縮ユーティリティ２７０は、イメージ・ファイル２７５を（それをテープ１２５にコピーする）、選択されたロボット２６０順に渡す。最後に、バックアップ・マネージャ２４０は、バックアップ処理の結果を対応するバックアップ・ログ２８０に保存する。

次に、図３および図４に関して、上述のシステムにおいて実行できるバックアップ処理を管理するための典型的な方法の論理フローを方法３００として記述する。

方法は、マスター・システムのスイム・レーンにおけるスタートの黒色の円３０３から始まる。ブロック３０６に続き、バックアップ処理を管理している、インフラストラクチャ全体のアドミニストレータは、新しいスケジューリング・ファイルを規定する。この作業は、例えば、来年以降の各年の年末に実行される。

次に、汎用の従属システムのスイム・レーンに移って、検証手順が定期的に（例えば毎日）実行されるが、本検証手順は、別の従属システムでは時間をずらしてで呼び出される（例えば、第１の従属システムでは１２時００分、第２のそれでは１２時１５分、第３のそれでは１２時３０分等々といったように）ことが好ましい。このように選択すると、必要な共用リソース（すなわち、スケジューリング・ファイルおよび制御ファイル）における競合が回避できる。

さらに詳細には、対応するタイムアウトが終了する（ブロック３０９）と、常にバックアップ・スクリプトがブロック３１２で起動し、これがトリガになってマスター・システムからスケジューリング・ファイルが読み込まれ、続いて従属システムのホストになっている各ゲスト・システムのループが実行される。ループは、ブロック３１５で始まり、ここでバックアップ・スクリプトは、カレント（現行）・ゲスト・システム（最初のシステムからスタートする）が、スケジューリング・ファイルに含まれているか否かを検証する。もし含まれていれば、さらなるテストがブロック３１８で行われ、現在の日付（ｃｕｒｒｅｎｔ ｄａｙ）が、ゲスト・システムのスケジューリング・ファイルに特定されているバックアップ回数に対応しているか否かが決定される。

バックアップ回数に対応している場合、ゲスト・システムはそのデータを今日バックアップすることができることを意味し、方法はブロック３２１へ下る。この段階で、バックアップ・スクリプトは、ゲスト・システムが使用している共用ディスクのＩＤを（構成ファイルから）抽出する。さて、ブロック３２４では、現在の日付用の制御ファイルがマスター・システム上に既に存在しているか否か（例えば、後に現在の日付が続くキーワードによって識別される）を決定するためにテストが行われる。ファイルが存在していない場合、ブロック３２７で新しい制御ファイルが作成され、動作のフローはそれから、ブロック３３０へ続く。逆に存在する場合には、同ブロックにはブロック３３０から直接到達する。いずれの場合にも、（バックアップされるゲスト・システムのデータが保存されている）共用ディスクのＩＤが、ブロック３３０で制御ファイルに付加される。

次いでブロック３３３において、シャットダウン時間が、（クリティカル）ゲスト・システムの制御ファイルに特定されている場合、方法はブロック３３６へ下る。ここで、ゲスト・システムのシャットダウン時間が、従属システム（例えば、構成ファイル内の対応するレコード）に保存される。

動作のフローは、ブロック３３９で再び合流する。このブロックにはブロック３３６から、あるいは（シャットダウン時間がゲスト・システムのスケジューリング・ファイルに特定されていない場合には）ブロック３３３から、あるいは（現在の日付がゲスト・システムのスケジューリング・ファイルに特定されていない場合には）ブロック３１８から、あるいは（ゲスト・システムがスケジューリング・ファイルに含まれていない場合には）ブロック３１５から到達する。さらに処理すべきゲスト・システムがある場合は、方法はブロック３１５に戻り、次のゲスト・システム上で同じ操作を繰り返す。逆に、さらに処理すべきシステムがない場合には、ループは定期的検証手順を終えて、終了する。

このようにして、すべての従属システムについて検証手順が終了すると、制御ファイルは、（、別の従属システム上のバックアップ可能なゲスト・システム用に）今日にバックアップされる共用ディスクの一覧表を含むことになる。

動作のフローは、従属システムのスイム・レーン内で続く。従属システムでホストとなっている各クリティカル・ゲスト・システムについては、対応するシャットダウン時間になると（ブロック３４２）、クリティカル・ゲスト・システムは、ブロック３４５でオフになる。

同時に、ブロック３４８での対応するタイムアウトの終了がトリガとなって、マスター・システム上のバックアップ・マネージャが、ブロック３５１に入る。この段階で、バックアップ・マネージャは、（上述の命名規則に従って特定される）今日の制御ファイルを探す。制御ファイルがある（図４の判断ブロック３５４）場合、方法は、制御ファイルのあらゆる複製された共用ディスクが削除されているブロック３５７へ続く。これにより、同じ共用ディスクのコピーの繰り返しが防止される。このようにして、バックアップ処理は、必要な操作（そしてその時間）を軽減するように最適化される。

さて、ループはバックアップされる残りの共用ディスクごとに（１つ目からスタートして）、実行される。ループは、動作フローがカレントの共用ディスクの容量に応じて分岐するブロック３６０で始まる。共用ディスクが大容量である（すなわち、実質的にテープと同等の容量を有する）場合には、ブロック３６３が実行され、他方共用ディスクがより小容量である場合には、ブロック３６６〜３６７が実行される。いずれの場合にも、方法は、ブロック３７５で合流する。

特にブロック３６３（本発明の実施形態の例としては、１０ギガ・バイトの容量を有しているような大容量の共用ディスク）について考えると、バックアップ・マネージャは、利用可能なロボットのうちの１つを（例えば、負荷平準化アルゴリズムに従って）選択する。選択されたロボットは、ダイレクト・トゥ・ディスク・レコーディング（Ｄｉｒｅｃｔ ｔｏ Ｄｉｓｋ Ｒｅｃｏｒｄｉｎｇ）（ＤＤＲ）として知られる技術により、共用ディスクをテープに（１つの共用ディスクを１つのテープに）コピーするよう命令される。

ブロック３６６（問題の例では、３ギガ・バイトの容量を有するような小容量の共用ディスク）に関しては、バックアップ・マネージャは、（常に負荷平準化アルゴリズムに従って）利用可能な圧縮ユーティリティのうち１つを選択する。選択された圧縮ユーティリティは、次いでＤＤＲ２ＣＭＳＸとして知られている別の技術を用いて、共用ディスクを圧縮するとともに、リポジトリ・ディスク上のカレント・イメージ・ファイルに付加するよう命令される。ブロック３６９でイメージ・ファイルが完了しているか否かを検証するために、テストが実施される。各テープは１０ギガ・バイトの容量を有し、各小容量の共用ディスクは３ギガ・バイトの容量を有している、本発明の実施形態の例では、３つの小容量の共用ディスクがイメージ・ファイルに圧縮された後に、テストが実施される。テストの結果が好ましいものである場合、ブロック３７２のバックアップ・マネージャは同様に、利用可能なロボットのうちの１つを選択して、例えば、ＶＭコマンドＶＭＦＰＬＣ２を使って、そのロボットにイメージ・ファイルをテープに（３つの共用ディスクを１つのテープに）コピーするよう命令する。次に方法は、ブロック３７５へ続く。同ブロックには、イメージ・ファイルが完了していない場合には直接、ブロック３６９からも到達する。

さてブロック３７５について考えると、さらなる共用ディスクがバックアップされるべく（制御ファイル内に）残存しているか否かを検証するために、テストが行われる。残存している場合、方法は、ブロック３６０まで戻り、次の共用ディスクについての手順を繰り返す。逆に残存していない場合、ループはブロック３７８へ下って終了する。

この段階では、（別の圧縮ユーティリティの制御下で）まだ完了していないいかなるイメージ・ファイルも同様に、対応するテープにコピーされる。ブロック３８１へ進んで、バックアップ処理の結果が、対応するログに保存される。同時に、アドミニストレータは、バックアップ処理の完了を電子メール（結果が添付されている）で通知されることが好ましい。方法は、白色・黒色の停止用の円３８４で終了する。

当業者は、ローカルで特定の要求を満足させるために、上述したソリューションに、多くの修正や改変を適用することができることは勿論である。特に、本発明は、その最適な実施形態に関して、ある程度詳細に記述されているけれども、他の実施形態の場合と同じように、形式および細部において、様々な省略や、置き換え、変更などが可能であることを理解すべきである。さらに、発明のあらゆる公開済みの実施形態に関連して記述されている特定の要素および／または方法は、一般的な設計選択要件として、他のいかなる実施形態にも盛り込むことができるよう、明確に意図されている。

例えば、インフラストラクチャが、異なるアーキテクチャを持っているか、あるいは、同等のユニットを含む場合、同様の考慮が適用される。さらに、各コンピュータは、別の構造を持ち得るし、同様の要素（例えば、実行中に共用ディスクへのアクセスを減らすために、プログラムやその一部を一時的に保存するキャッシュ・メモリなど）を持ってもよい。いずれの場合にあっても、コンピュータを何らかのコード実行エンティティ（例えば、ＰＤＡや、携帯電話等々）と置き換えることは可能である。代わりに、ここで提案したソリューションを、インフラストラクチャにおいて利用可能なホスト・システム、ゲスト・システムのサブセットのみに適用してもよい。本発明の概念は、バックアップされる他のいかなるデータ（例えば、プログラム・コードとか、マルチメディアの作品等のデータなど）にも適用される。発明の他の実施形態においては、スケジューリング・ファイルは、ゲスト・システム（ではあるが、それぞれの従属システムによって制御ファィルに常に付加される対応するアクセス・パスを有している）ごとにバックアップされるデータの記述も含んでいてよい。

提案されたスケジューリング・ファイルと制御ファイルは、単に例示のためのものであり、他の同等の構造に（例えば、単にバックアップの日付を列挙することによって）置き換えることができることは容易に明白になるべきであろう。

（特定の事柄の必要条件とされる）スケジューリング・ファイルにおいては、より複雑なポリシーの明確化を妨げるものはない。いずれの場合でも、バックアップされるゲスト・システムを（バックアップ処理が実行されるたびに）特定することのみは可能な発明の基本的な実施は、本発明の範囲内で行われる。

先の説明では、スケジューリング・ファイルに各ゲスト・システムが取り込まれているか否かの検証が（対応する従属計算機によって）毎日行われるバックアップ処理について述べたけれども、これは制限的にしようと意図したものではない。実際、同様の考慮が、同じ操作が他の周期で行われる場合や、もっと複雑な時間パターンで行われる場合にも適用される。いずれの場合にも、ゲスト・システムがマスター・システムによって記録される行為は含まれていない。

同様の考慮は、（別の従属システムによって実施される連続的な検証手順の各組合わせ間の）時間シフトが、別の長さである場合にも適用される。代わりに、同様の結果が、（各従属システムが、その検証手順の完了を次のシステムに通知する）通知技術によって達成される場合もある。しかし、すべての従属システムが、検証手順を同時に実行する基本的な実施体制を妨げるものは何もない。

発明の趣旨から離れることなく、クリティカル・ゲスト・システムのシャットダウン時間を、他の方法で定めることもできる。例えば、発明の他の実施形態では、シャットダウン時間はスケジューリング・ファイルでは定められない。この場合、毎日実施されるバックアップ処理の開始時（例えば２２時００分）直前に各従属システムがマスター・システム上のスケジューリング・ファイルを読み込み、そこに含まれる対応ゲスト・システムをすべて無条件でオフにする。さらに、提案された事項の実施に際し、オフ中のゲスト・システムの再起動はそれらの所有者に委ねられている。代わりに、自動的な手順を実行することも可能で、バックアップ・マネージャが、バックアップ処理の完了を従属システムに通知する自動手順を実行して、従属システムがそのクリティカル・ゲスト・システムを自動的に再起動できるようにすることも可能である。いずれの場合にも、ゲスト・システムのシャットダウンに関する特徴は、厳密に必要だというわけではなく、ある実施形態（例えば、データの整合性が重要でない場合など）では省略してもよい。

本発明の実施形態におけるソリューションは、仮想計算機に基づく環境に合わせて特に記述されたものではあるが、これは制限的に解釈されるべきものではない。実際、同一の概念は、（汎用ホスト計算機が、多数のゲスト計算機の処理を実行する）同等の構造を持つシステムにも適用される。いずれの場合にも、提案されたソリューションを他のデータ処理エンティティ（例えば、各々が要求された操作の実施を直接制御する物理的計算機など）に適用することができるだろう。

考案されたソリューションは、共用ディスク（あるいは他の記憶媒体）に基づく上述のインフラストラクチャで実行されることが望ましい。しかし、同一のソリューションは、ネットワーク・インフラストラクチャにおいても適用できるだろう。

さらに、（制御ファイルに複写されている）同一の共用ディスクの反復バックアップを防止するという成果は、本発明と同等の技術で（例えば、バックアップ処理中に、それらをスキップすることによって）、達成することもできる。いずれの場合にも、この特徴を持たない単純化された実施形態は、発明の範囲内である。

同様の考慮は、（発明の各実施形態を実行するのに用いられる）プログラムが別の方法で構成されている場合や、モジュールや機能が追加されている場合でも、適用される。同様に、メモリの構成は、他のタイプであってもよいし、あるいは同等のエンティティ（必ずしも物理的な記憶媒体である必要はない）で置き換えてもよい。さらに、提案されたソリューション自体は、（順番は異なっていても、同様な又は付加的なステップを有する）同等の方法で実施できる。いずれの場合にも、プログラムは、例えば、外部ソフトウェア又は常駐ソフトウェア又は、ファームウェア又は、（オブジェクト・コードあるいは、ソース・コードの）マイクロ・コード等の、データ処理システムによるか、あるいはデータ処理システムと関連して用いるのに適した形態ならいかなる形態でもとることができる。さらに、プログラムは、コンピュータ使用可能ないかなる媒体にも提供できる。媒体は、プログラムを、搭載し、保存し、通信し、伝播し、あるいは転送するのに適した要素であれば何でもよい。そのような媒体の例としては、（プログラムをあらかじめ搭載しておくことができる）固定ディスク、リムーバブル・ディスク、テープ、カード、ワイヤ、ファイバ、無線接続、ネットワーク、放送波、などがあり、媒体には、電子タイプや、磁気タイプや、光タイプや、電磁気タイプや、赤外線タイプや、半導体タイプなどがある。

いずれの場合にも、本発明によるソリューションは、（例えば、半導体材料のチップに集積化された）ハードウェア構造、またはソフトウェアとハードウェアの組み合わせによって、実行することができる。

本発明の実施形態によるソリューションを実行できるデータ処理インフラを図示したものである。 本発明の実施形態によるソリューションを実行するのに用いることのできる主要なソフトウェア・コンポーネントを示す。 本発明の実施形態によるソリューションの実行に関する動作フローを説明する図表を示す。 本発明の実施形態によるソリューションの実行に関する動作フローを説明する図表を示す。

符号の説明

２０５ パーティション層
２１０ バーチャリゼーション層
２１５ オペレーティング・システム
２２０ アプリケーション
２２５ 作業データ
２３０ 構成ファイル
２３５ バックアップ・スクリプト
２４０ バックアップ・マネージャ
２４５ スケジューリング・ファイル
２５０、３５１ 制御ファイル
２６０ ロボット
２７０ 圧縮ユーティリティ
２８０ バックアップ・ログ

Claims (10)

1. 複数のデータ処理エンティティを含むシステム内のデータを、前記複数のエンティティのセットを対象にバックアップするための方法であって、
   対応するデータをバックアップ可能な前記エンティティの記述を含むスケジューリング構造を、前記エンティティのうちから選択されたエンティティ上に供給するステップと、
   前記スケジューリング構造に各エンティティが含まれていることを検証するステップと、
   前記含まれていることに応じて、各バックアップ可能なエンティティが、前記対応するデータの記述を前記選択されたエンティティ上の制御構造に追加するステップと、
   前記制御構造に記述されたデータを、前記選択されたエンティティの制御に基づいてバックアップするステップと、
   を含む方法。
2. 前記スケジューリング構造が、各バックアップ可能なエンティティのスケジューリング・ポリシーの記述をさらに含み、前記取り込みを検証するステップは、現在の日付と、前記対応するスケジューリング・ポリシーとの整合性を検証するステップを含む、請求項１に記載の方法。
3. 前記含まれていることを検証するステップが、各エンティティの制御に基づいて定期的に実行される、請求項１または２に記載の方法。
4. 前記エンティティが、相互にタイミングをずらして前記検証するステップを実行する、請求項３に記載の方法。
5. シャットダウン時間の記述が、前記バックアップ可能なエンティティのうち少なくともクリティカル・エンティティの前記スケジューリング構造に存在し、
   前記含まれていることに応じて、各バックアップ可能なエンティティが、前記スケジューリング構造の前記対応するシャットダウン時間の存在を検証するステップと、
   前記シャットダウン時間の存在に応じて、クリティカルでバックアップ可能な各エンティティが、前記対応するシャットダウン時間の到達したことを条件に、シャットダウンするステップと、
   をさらに含む、請求項１乃至４のいずれかに記載の方法。
6. 前記システムは、複数のホスト計算機を含み、各機械が複数のゲスト計算機のホストとして動作し、前記エンティティは、前記ゲスト計算機から構成され、前記検証するステップと前記付加するステップが、前記対応するゲスト計算機の各ホスト計算機の制御に基づいて実行される、請求項１乃至５のいずれかに記載の方法。
7. 前記エンティティが、複数の記憶媒体と、前記スケジューリング構造と、前記制御構造と、前記共用記憶媒体に保存されている前記データを共用する、請求項１乃至６のいずれかに記載の方法。
8. 前記制御構造が、各バックアップ可能なエンティティの前記データが保存されている前記記憶媒体の記述を含み、各記憶媒体の前記反復バックアップが前記制御構造で反復されるのを防止するステップをさらに含む、請求項７に記載の方法。
9. 複数のデータ処理エンティティを含むシステム内のデータを、前記複数のエンティティのセットを対象にバックアップするためのコンピュータ・プログラムであって、
   対応するデータをバックアップ可能な前記エンティティの記述を含むスケジューリング構造を、前記エンティティのうちから選択されたエンティティ上に供給するステップと、
   前記スケジューリング構造に各エンティティが含まれていることを検証するステップと、
   前記含まれていることに応じて、各バックアップ可能なエンティティが、前記対応するデータの記述を前記選択されたエンティティ上の制御構造に追加するステップと、
   前記制御構造に記述されたデータを、前記選択されたエンティティの制御に基づいてバックアップするステップと、
   をデータ処理システムに実行させる、プログラム。
10. 複数のデータ処理エンティティを含むシステム内のデータを、前記複数のエンティティのセットを対象にバックアップするためのシステムであって、
    対応するデータをバックアップ可能な前記エンティティの記述を含むスケジューリング構造を、前記エンティティのうちから選択されたエンティティ上に供給する手段と、
    前記スケジューリング構造に各エンティティが含まれていることを検証する手段と、
    前記含まれていることに応じて、各バックアップ可能なエンティティが、前記対応するデータの記述を前記選択されたエンティティ上の制御構造に追加する手段と、
    前記制御構造に記述されたデータを、前記選択されたエンティティの制御に基づいてバックアップする手段と、
    を含むシステム。

Images