JP4917102B2 - ローカル・ストレージおよびリモート・ストレージの混合環境におけるデータ・セット・バージョンのカウントのための方法、プログラム、およびシステム - Google Patents

Description

本発明は、ローカル・ストレージおよびリモート・ストレージの混合環境におけるデータ・セット・バージョンのカウントの分野に関する。

従来のシステムでは、データ・セットがローカル・コンピューティング・デバイスに常駐する場合、データ・セットのバックアップ・コピーをリモート・バックアップ・システムで維持することが有用な可能性がある（たとえば、ローカル・コンピューティング・デバイスでデータが損失した場合のデータ・リカバリのため）。

バックアップおよびストレージ管理の製品は、データをどのように管理するかを指示するためのポリシー構成のセットを提供する。ポリシー構成は、規則として説明することができる。これらのポリシー構成の１つが、ローカル・コンピューティング・デバイスのローカル・ストレージに存在するデータ・セットに関して（それに関する他のポリシー構成が存在する、コンピュータ上で削除されたデータ・セットとは対照的に）、バックアップ・データ・セットのいくつのコピーをリモート・バックアップ・システムで維持するべきかを指示する。たとえばユーザは、ローカル・ストレージ内の所与の既存のデータ・セットに関して、データ・セットの３つのバージョンをリモート・バックアップ・システムのリモート・ストレージ内に維持すべきであると、指定することができる。リモート・バックアップ・システムは、第４のデータ・セットが受け取られた場合、リモート・バックアップ・システムがデータ・セットの第１のバージョンを廃棄するように（事実上、データ・セットの第２、第３、および第４のバージョンを維持しながら）、リモート・ストレージを管理する。

従来のシステムでは、バックアップ・データ・セットは、リモート・バックアップ・システムのコンテキスト外で生成することができる。これらを「ローカル・バックアップ操作」と呼ぶことができる。たとえば、ソフトウェアまたはハードウェアのデータのスナップショットは、データのスナップショットを、それを実行するローカル・コンピューティング・デバイスまたはハードウェア・システム（たとえば、インターナショナル・ビジネス・マシンズ・コーポレーションから入手可能なＩＢＭ（Ｒ） Ｅｎｔｅｒｐｒｉｓｅ Ｓｔｏｒａｇｅ Ｓｅｒｖｅｒ（Ｒ）（ＥＳＳ）システム）上で生成することが可能な第三者のスナップショット・ソフトウェア・パッケージなどの、必ずしもリモート・バックアップ・システムに組み込まれていない製品によって生成することができる。

スナップショット操作の詳細は、１９９５年４月２５日発行の「Data Record Copy System for a Disk Drive Array Data Storage Subsystem」という名称の米国特許第５４１０６６７号に開示されている。これらの技法を使用したデータ・セット・バージョンのカウントは、リモート・バックアップ・システムでのデータ・セット・バージョンのカウントとは異なる。

第１に、従来のリモート・バックアップ・システムでは、リモート・ストレージはローカル・コンピューティング・デバイスに対して不透明である。すなわち、ローカル・コンピューティング・デバイスは、少なくともローカル・コンピューティング・デバイス側のユーザが管理を希望する数のバージョンを格納するのに十分なリモート・ストレージがあるものと想定する。また、この種のリモート・バックアップ・システムでは、ストレージを使い切った状況は例外である。実際、リモート・バックアップ・システムは、ユーザがある時間間隔について要求する以上のバージョンを維持することができる。たとえば、ユーザが３つのバージョンのデータ・セットを維持するように指定し、第４のバージョンのデータ・セットがリモート・バックアップ・システムに送られた場合、リモート・バックアップ・システムは４つのバージョンすべてを、データ・セットの不要なバージョンを削除する期限切れ処理を条件として維持することができる。期限切れ処理は、第４、第５、第６などのデータ・バージョンの追加に時間依存性を持たないため、非同期として説明することができる。さらに、データ・セットのバックアップが期限切れ処理よりも頻繁である場合、さらに多くのバージョンのバックアップ・データ・セットが、リモート・バックアップ・システムから期限切れにするようにキューに入れられている可能性もある。

ローカル・バックアップ・データ・セットは、テラバイトのデータを表す場合がある。ユーザが１００ギガバイト（ＧＢ）サイズのデータ・セットを有し、３つのバージョンのデータ・セットを管理するポリシー構成を有する場合、ユーザは技術的に、少なくとも４つの使用可能な１００ＧＢストレージ・コンテナを有する必要がある。ストレージ・コンテナは、データ・セット・バージョンを格納するためにリモート・バックアップ・システムによって使用されるリモート・ストレージの論理部分（すなわち、物理ディスク・スペースのセット）として説明することができる。３つのストレージ・コンテナが３つのバージョンのローカル・バックアップ・データ・セットで満たされた後、第４のストレージ・コンテナを使用して第４のバージョンが収容され、その後、第１のバージョン用のストレージ・コンテナを解放することができる。

この問題に対する代替の手法は、ローカル・コンピューティング・デバイスに関して、第４のデータ・セットをバックアップする前に３つのバックアップ・データ・セットのうちの１つを削除することである。これによりユーザは、３つのバージョンのバックアップ・データ・セットを収容するために４つのストレージ・コンテナを有する必要が軽減される。この代替手法の欠点は、第４のバックアップ操作（数時間かかる可能性がある）を実行中に、ユーザが復元操作を実行できるのは２つのバージョンのバックアップ・データ・セットのみであり、この操作はポリシー構成に準拠していないことである。また、第４のデータ・セットのバックアップが失敗した場合、ユーザには２つのバージョンのバックアップ・データ・セットが残されることになる。この種のリモート・バックアップ・システムでは、ストレージを使い切った状況は通常である。

いくつかの直接アクセス・ストレージ・デバイス（ＤＡＳＤ）サブシステムは、「高速複製機能」とも呼ばれる「即時仮想コピー（instant virtual copy）」操作を実行することができる。即時仮想コピー操作は、関係テーブルまたはポインタなどのメタデータを修正することによって、ソース・データ・オブジェクトをオリジナルおよびコピーの両方として取り扱うように動作する。ストレージ・コントローラ（ストレージへのアクセスを提供する）で受信されたコピー操作要求に応答して、いかなるデータの物理コピーも作成することなく、コピーの作成が報告される。「仮想」コピーのみが作成され、追加の物理コピーがないことは、コピー操作要求の発信元にはまったく知らされない。

その後、ストレージ・コントローラがオリジナルまたはコピーへの更新を受信した場合、この更新は別に格納され、更新されたデータ・オブジェクトのみと相互参照される。この時点で、オリジナルおよびコピーのデータ・オブジェクトが分岐（diverge）を始める。所期の利点は、即時仮想コピーがほぼ瞬時に開始されるという点であり、通常の物理コピー操作よりもかなり速く完了する。これにより、ストレージ・コントローラは他のタスクを実行するために解放される。ストレージ・コントローラは、背景処理中に、または他の時点で、オリジナルデータ・オブジェクトの実際の物理コピーの作成を進行させることさえも可能である。

こうした即時仮想コピー操作の１つが、ＦｌａｓｈＣｏｐｙ（Ｒ）として知られている。即時仮想コピー操作の詳細は、２００３年８月２６日発行の「Method, System, and Program for Maintaining Electronic Data as of a Point-in-Time」という名称の米国特許第６６１１９０１号に記載されている。

バックアップ・バージョンのカウントの従来技法に伴う第２の問題は、バージョンのバックアップが完了し、リモート・バックアップ・システムにコミットされたものと想定されることである。大規模なローカル・データ・セットのバックアップ（たとえば、ＦｌａｓｈＣｏｐｙ（Ｒ）のバックアップ操作）の場合、後続のバックアップ操作が実行される時点で、ローカル・ストレージが使用中の可能性がある。たとえばユーザが、現在３つのローカル・コンテナと２つのバージョンのローカルＦｌａｓｈＣｏｐｙ（Ｒ）データを有し、４時間かかるローカルＦｌａｓｈＣｏｐｙ（Ｒ）バックアップ操作を開始する場合がある。この時点で、ローカル・ストレージ・コンテナのうちの２つが有効なデータ・セット・バージョンに使用され、第３のストレージ・コンテナは現在の処理に割り振られる。２時間後のある時点で（「時間ｔ１」）、ユーザは別のバックアップ操作を開始する。この時点で、ユーザは２つのローカル・ストレージ・コンテナのうちの１つを再使用して、このバックアップ操作に専念させなければならない。これにより、有効なバックアップ・データを備えたローカル・ストレージ・コンテナが１つと、バックアップ操作に専念するローカル・ストレージ・コンテナが２つになる。どちらのバックアップ操作も失敗した場合、ユーザには１つのバックアップ・データ・セットが残されることになる。ユーザがこの時点でデータを復元しようとする場合、復元元となる有効なデータ・セットは１つだけであり、３つのバージョンのデータを維持するためのポリシーが設定された時点でユーザが意図した内容とは異なる。

第３の問題は、エンド・ユーザが、リモート・バックアップ・システムが管理するバージョンの数と正確に一致するように、ローカル・ストレージを明示的にセットアップしなければならないことである。たとえば、ユーザが、リモート・バックアップ・システム上で３つのバージョンｖ（１）を管理するようにポリシーをセットアップする場合、ユーザは、この３つのバージョンｖ（１）を格納するのに十分なローカル・ストレージｓ（１）が存在することを確認しなければならない。ユーザが追加のローカル・ストレージｓ（１）を有する場合、この追加のローカル・ストレージを使用して前述の例における問題を軽減することが可能であるが、ユーザが所望の数のバージョンを格納するのに十分なローカル・ストレージのみを有する場合（ｓ（１）＝ｖ（１））、すべてのローカル・ストレージが使用された後にバックアップを行う際には、別の規則セットが適用されることになる。

第４の問題は、同じローカル・ストレージ・プール上で、異なるバックアップ技術が使用される可能性があることである。たとえば、即時仮想コピーおよび増分仮想コピーが、同じローカル・ストレージ・プール上で使用される場合がある。増分仮想コピー操作についての詳細は、２００３年６月１８日出願の「Method, System, and Program for Incremental Virtual Copy」という名称の米国特許出願第１０／４６５１１８号に記載されている。増分仮想コピー操作は、即時仮想コピー操作に対する機能強化である。増分仮想コピー操作を使用する場合、ソース・ボリュームからターゲット・ボリュームへの最終のコピー操作（たとえば即時仮想コピー操作）以降に、ソースおよびターゲットのボリューム上で更新されたデータのブロックのみがコピーされる。

たとえばユーザが、ローカル・ストレージ・コンテナの３つのセット、ｓｃ（１）を有し、完全な即時仮想コピー・バックアップを１２：００に、増分仮想コピー・バックアップを２時間ごとに、実行することを希望すると想定する。したがって、１２：００に、ストレージ・コンテナｓｃ（１）１が完全バックアップに使用される。２：００には、ストレージ・コンテナｓｃ（１）２が増分仮想コピーに使用される。４：００には、ストレージ・コンテナｓｃ（１）２が増分仮想コピーに再使用される（単一セットの増分仮想コピー関係のみが存在する可能性のある状況の場合）。ストレージ・コンテナｓｃ（１）３は、１２：００に別の完全な即時仮想コピーが実行されるまで使用されない。増分仮想コピー関係が、完全な即時仮想コピー操作と混合されるという事実により、この混合モード環境においてバージョン・カウントがどのように使用されるかをユーザに説明することが、さらに困難になる。したがって、従来技法のバックアップ・バージョンのカウントは、いかなる時点でもユーザが復元を希望するバージョンの数と相関する。リモート・バックアップ・システム外部で管理されるデータ・セットのバージョンを格納するローカル・ストレージを導入する場合、所望の数のバックアップ・バージョンが任意の所与の時点で復元可能であることを保証するために、ローカル・ストレージ内でどれだけのストレージ・スペースを割り振る必要があるかについてユーザに指示することは困難になる。
米国特許第５４１０６６７号 米国特許第６６１１９０１号 米国特許出願第１０／４６５１１８号

したがって当分野では、ローカル・ストレージおよびリモート・ストレージの混合環境におけるデータ・バージョンのカウントを改良することが求められている。

データ・セットのローカル・バージョンを格納するための方法、コンピュータ・プログラム、およびシステムが提供される。データ・セットのいくつのローカル・バージョンが、使用可能なローカル・ストレージの量が与えられたローカル・ストレージに格納されるべきかを示す、第１の数が受け取られる。ローカル・ストレージが格納可能なデータ・セットのローカル・バージョンの合計数を示す第２の数が、第１の数を超えるかどうかが判別される。第２の数が第１の数を超える旨の判別に応答して、データ・セットの第１の数のローカル・バージョンを格納することが可能なローカル・ストレージの量が使用される。

次に、本発明の諸実施形態について、添付の図面を参照しながら単なる例として説明する。

以下の説明では、本明細書の一部を形成し、本発明のいくつかの諸実施形態を示す、添付の図面が参照される。本発明の範囲を逸脱することなく、他の諸実施形態が使用可能であること、ならびに構造および操作の変更が実行可能であることが理解されよう。

図１は、本発明のある実施形態に従ったコンピューティング環境を示す。ローカル・コンピューティング・デバイス１００は、ローカル・ストレージ１１０内でデータのローカル・バージョンを管理するローカル・バックアップ・マネージャ１０２を含む。ローカル・コンピューティング・デバイス１００は、ローカル・ストレージ１１０に結合される。ローカル・ストレージ１１０は、直接アクセス・ストレージ・デバイス（ＤＡＳＤ）などの１つまたは複数の物理ストレージ・デバイスを備える。ローカル・ストレージ１１０は、１つまたは複数のローカル・ストレージ・コンテナ１１２に区分することができる。

ストレージ・コントローラ１２０もローカル・ストレージ１１０に結合することができる。ストレージ・コントローラ１２０は制御ユニットまたはストレージ・ディレクタと呼ばれることもあり、他のコンピューティング・デバイス（図示せず）からローカル・ストレージ１１０へのアクセスを管理する。

ローカル・コンピューティング・デバイス１００は、リモート・バックアップ・システム１３０にも結合される。リモート・バックアップ・システム１３０は、リモート・ストレージ１４０内のデータのバックアップ・バージョンを管理するリモート・バックアップ・マネージャ１３２を含む。リモート・バックアップ・システム１３０は、リモート・ストレージ１４０に結合される。リモート・ストレージ１４０は、直接アクセス・ストレージ・デバイス（ＤＡＳＤ）などの１つまたは複数の物理ストレージ・デバイスを備える。リモート・ストレージ１４０は、１つまたは複数のリモート・ストレージ・コンテナ１４２に区分することができる。

ある実施形態では、（リモート・ストレージ１４２などのリモート・ストレージの代わりに、またはこれに加えて）取り外し可能ストレージを使用して、ローカル・ストレージ１１０のすべてまたはサブセットのバックアップ・コピーを維持することができる。取り外し可能ストレージは、ローカル・コンピューティング・デバイス１００に常駐可能である。

図２および図３は、ある実施形態に従った、ローカル・ストレージ１１０内でローカル・バージョンを管理するための論理を示す。ポリシー構成は、規則（たとえば３つのバージョンのローカル・バックアップ・データ・セットを格納する）として説明することができる。ユーザは、データ・セットを管理するためのポリシー構成を提供する。ある実施形態は、使用可能なローカル・ストレージの量が与えられたローカル・ストレージ１１０内にデータ・セットのいくつのローカル・バージョンを格納すべきであるかを定義する、新しいポリシー構成を提供する。ある代替実施形態では、使用可能なローカル・ストレージの量が与えられたローカル・ストレージ１１０内にデータ・セットのいくつのバージョンを格納すべきであるかを定義するために、既存のポリシー構成をオーバーロード（overload）すなわち多重定義する。ユーザは、ポリシー構成が必要とするよりも多くのローカル・ストレージ１１０を有することが可能である（たとえばユーザは、５つのバージョンのローカル・バックアップ・データに十分なローカル・ストレージがある場合、３つのバージョンに十分なローカル・ストレージがあるものと示す）。

図２のブロック２００で、ローカル・バックアップ・マネージャ１０２が、ある量の使用可能なローカル・ストレージ１１０が与えられたローカル・ストレージに、データ・セットのいくつのローカル・バージョンを格納すべきであるかを示す、第１の数を受け取ることで、制御が開始される。ブロック２０２では、ローカル・ストレージ１１０が格納可能なデータ・セットのローカル・バージョンの合計数を示す第２の数が、第１の数を超えるかまたはこれに等しいかどうかが判別される。すなわち、この第２の数は、ローカル・ストレージが格納できるローカル・バージョンの実際の数を表す。第２の数が第１の数を超える（たとえば第２の数は、ローカル・ストレージが５つのローカル・バージョンを格納できることを示し、第１の数は、３つのローカル・バージョンを格納すべきであることを示す）場合、処理はブロック２０４へ進み、そうでない場合、処理はブロック２１４へ進む。ブロック２０４で、ローカル・バックアップ・マネージャ１０２は、データ・セットの第１の数のローカル・バージョンが格納可能な量のローカル・ストレージ１１０を使用する。

ある実施形態では、いかなる追加の使用可能なローカル・ストレージ１１０も使用されない（たとえば、ローカル・バージョンの数が３であり、使用可能なローカル・ストレージ１１０の量が５つのローカル・バージョンを格納できる場合、追加のローカル・ストレージは使用されない）。

ある実施形態では、使用されるストレージの量は第３の数のローカル・ストレージ・コンテナであり、第１の数および第３の数は等価である（たとえば、第１の数が３つのローカル・バージョンを示す場合、第３の数は３つのローカル・ストレージ・コンテナを示す）。処理は、ブロック２０４からブロック２０６（図３）へと続行される。

ブロック２０６で、ローカル・バックアップ・マネージャ１０２は、データ・セットのバージョンの格納要求を受け取る。ブロック２０８で、ローカル・バックアップ・マネージャ１０２は、ローカル・ストレージ１１０内の、要求されたデータ・セットのバージョンを格納するために予約されたすべてのローカル・ストレージ・コンテナ（すなわち、第３の数のローカル・ストレージ・コンテナ）が使用されているかどうかを判別する。使用されている場合、処理はブロック２１０へと進み、そうでない場合、処理はブロック２１２へと進む。ブロック２１０で、ローカル・バックアップ・マネージャ１０２は、第１の数のローカル・バージョンを超えるローカル・バージョンがローカル・バックアップ操作でバックアップされる場合、バックアップ・ポリシーを使用して、ローカル・ストレージ１１０内の第３の数のローカル・ストレージ・コンテナをどのように再使用すべきかを決定する（たとえば、３つのローカル・バージョンを維持するべきであれば、バックアップ・ポリシーを使用して、コンテナのうちの１つを再使用することによって第４のローカル・バージョンをどのように格納するかを決定する）。ブロック２１２で、ローカル・バックアップ・マネージャ１０２は、使用可能なローカル・ストレージ・コンテナ内に、データ・セットのバージョンを格納する。

パックアップ・ポリシーは、使用されるローカル・バックアップ技術に基づいて、ローカル・ストレージ・コンテナをどのように再使用するかを定義する追加の構成を含むものとして説明することができる。たとえば、ローカル・バックアップ・マネージャ１０２は、（１）要求されたバックアップが即時仮想コピー操作である場合、他のローカル・ストレージ・コンテナのうちの１つに他の即時仮想コピー操作がない限り、最も古いフル・コピーを表すローカル・ストレージ・コンテナを再使用すること、および（２）要求されたバックアップが増分仮想コピー操作である場合、増分関係で確立されたバックアップ・コピーを表すローカル・ストレージ・コンテナ内のボリューム上に、依然として事実上、背景コピー処理または増分リフレッシュがない限り、そのローカル・ストレージ・コンテナを再使用すること、などのポリシーを、実施することができる。

ブロック２１４で、第１の数が第２の数を超える（たとえば第１の数が６つのローカル・バージョンを格納すべきであることを示し、第２の数が、ローカル・ストレージが４つのローカル・バージョンを格納できることを示す）旨の判別に応答して、第２の数を超えるいずれのデータ・セットのローカル・バージョンについてもバックアップ操作は失敗する（たとえば、ローカル・バージョンの数が５であり、使用可能なローカル・ストレージ・コンテナの数が４である場合、第５のローカル・バージョンを作成するバックアップ操作は失敗する）。ある実施形態では、バックアップ操作に使用可能な十分なストレージがないことを示すためのメッセージが発行される。

このようにして、諸実施形態ではローカル・ストレージに関するデータ・バージョンをカウントするための技法を提供し、リモート・ストレージに関するバージョンのカウントは、同じかまたは異なる場合がある。

ＩＢＭは、米国および／または他の諸国におけるインターナショナル・ビジネス・マシンズ・コーポレーションの登録商標または一般的な法定マークである。

追加の実施形態の詳細
説明された操作は、ソフトウェア、ファームウェア、ハードウェア、またはそれらの任意の組み合わせを生成するために、標準的なプログラミングおよび／またはエンジニアリング技法を使用する、方法、装置、または製品として実施可能である。本明細書で使用される「製品」という用語は、媒体内に実装されるコードまたは論理を言い表し、こうした媒体は、ハードウェア論理（たとえば集積回路チップ、プログラム可能ゲート・アレイ（ＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）など）、あるいは、磁気ストレージ媒体（たとえばハード・ディスク・ドライブ、フレキシブル・ディスク、テープなど）、光ストレージ（ＣＤ−ＲＯＭ、光ディスクなど）、揮発性および不揮発性のメモリ・デバイス（たとえばＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウェア、プログラム可能論理など）などのコンピュータ読み取り可能媒体を含むことができる。コンピュータ読み取り可能媒体内のコードは、プロセッサによってアクセスおよび実行される。内部でコードまたは論理が符号化された媒体は、空間、あるいは光ファイバ、銅線などの伝送媒体を介して伝播される、伝送信号も含むことができる。内部でコードまたは論理が符号化された伝送信号は、無線信号、衛星伝送、電波、赤外線信号、Ｂｌｕｅｔｏｏｔｈ（登録商標）などを、さらに含むことができる。内部でコードまたは論理が符号化された伝送信号は、送信局によって受信されること、および受信局によって受信されることが可能であり、伝送信号内で符号化されたコードまたは論理は、受信および送信の局またはデバイスにあるハードウェアまたはコンピュータ読み取り可能媒体内で復号および格納することができる。加えて、「製品」は、内部でコードが具体化、処理、および実行される、ハードウェアおよびソフトウェアのコンポーネントの組み合わせを含むこともできる。もちろん当業者であれば、本発明の範囲を逸脱することなくこの構成に対して多くの修正が実行可能であること、および、製品が当分野で知られた任意の情報担持媒体を含むことが可能であることを、理解されよう。

論理という用語は、たとえば、ソフトウェアまたはハードウェア、ならびに／または、ソフトウェアおよびハードウェアの組み合わせを含むことができる。

図２および図３の論理は、特定の順序で発生する特定の操作を記述する。代替の実施形態では、一定の論理操作の、異なる順序での実行、修正、または除去が可能である。さらに、前述の論理に操作を追加することも可能であり、依然として説明された諸実施形態に準拠する。さらに、本明細書で説明された操作が順次実行されること、または一定の操作が並行して処理されること、あるいは単一の処理によって実行されるものとして説明された操作が分散処理によって実行されることも可能である。

図２および図３に示された論理は、ソフトウェア、ハードウェア、プログラム可能およびプログラム不可のゲート・アレイ論理で、あるいは、ハードウェア、ソフトウェア、またはゲート・アレイ論理の何らかの組み合わせで、実施可能である。

図４は、ある実施形態に従って使用可能なコンピュータ・システムのアーキテクチャ３００を示す図である。ローカル・コンピューティング・デバイス１００、ストレージ・コントローラ１２０、および／またはリモート・バックアップ・システム１３０は、アーキテクチャ３００を実装することができる。コンピュータ・アーキテクチャ３００は、プロセッサ３０２（たとえばマイクロプロセッサ）、メモリ３０４（たとえば揮発性メモリ・デバイス）、およびストレージ３１０（たとえば、磁気ディスク・ドライブ、光ディスク・ドライブ、テープ・ドライブなどの、不揮発性ストレージ領域）を実装することができる。オペレーティング・システム３０５は、メモリ３０４内で実行可能である。ストレージ３１０は、内蔵ストレージ・デバイスまたは取り付け型またはネットワーク・アクセス可能なストレージを備えることができる。ストレージ３１０内のコンピュータ・プログラム３０６はメモリ３０４内にロードすること、および当分野で知られた様式でプロセッサ３０２によって実行することが可能である。さらにアーキテクチャは、ネットワークとの通信を実行可能にするネットワーク・カード３０８を含む。入力デバイス３１２は、ユーザ入力をプロセッサ３０２に提供するために使用され、キーボード、マウス、ペンスタイラス、マイクロフォン、タッチ検知ディスプレイ・スクリーン、または当分野で知られた任意の他の活動化または入力機構を含むことができる。出力デバイス３１４は、プロセッサ３０２、またはディスプレイ・モニタ、プリンタ、ストレージなどの他のコンポーネントからの情報をレンダリングすることができる。コンピュータ・システムのコンピュータ・アーキテクチャ３００は、図示されたよりも少ないコンポーネント、本明細書に図示されていない追加のコンポーネント、または図示されたコンポーネントと追加のコンポーネントとの何らかの組み合わせを含むことができる。

コンピュータ・アーキテクチャ３００は、メインフレーム、サーバ、パーソナル・コンピュータ、ワークステーション、ラップトップ、ハンドヘルド・コンピュータ、電話デバイス、ネットワーク機器、仮想化デバイス、ストレージ・コントローラなどの、当分野で知られた任意のコンピューティング・デバイスを備えることができる。当分野で知られた任意のプロセッサ３０２およびオペレーティング・システム３０５を使用することができる。

本発明の諸実施形態の前述の説明は、例示および説明の目的で提示されたものである。本発明の諸実施形態を網羅するか、または開示された精密な形に制限することを意図するものではない。前述の教示に照らせば、多くの修正形態および変形形態が可能である。本発明の諸実施形態の範囲は、この詳細な説明によってではなく、むしろ本明細書に添付の特許請求の範囲によって制限されることが意図される。前述の指定、例、およびデータは、本発明の諸実施形態の構成の製造および使用に関する、完全な説明を提供する。本発明の多くの実施形態は本発明の諸実施形態の範囲から逸脱することなく実行可能であるため、本発明の諸実施形態は、添付の特許請求の範囲または任意の今後出願される特許請求の範囲内にあるものとする。

ある実施形態が実施可能なコンピューティング・デバイスを示す詳細図である。 ある実施形態に従った、ローカル・ストレージ内でローカル・バージョンを管理するための論理を示す図である。 ある実施形態に従った、ローカル・ストレージ内でローカル・バージョンを管理するための論理を示す図である。 ある実施形態に従って使用可能なコンピュータ・システムのアーキテクチャを示す図である。

Claims (7)

1. データ・セットのバージョンを格納するための方法であって、
   （ａ）前記データ・セットのいくつのローカル・バージョンが、使用可能なローカル・ストレージの量が与えられたローカル・ストレージに格納されるべきかを示す、第１の数を受け取るステップを含み、
   前記ローカル・ストレージが１つまたは複数のローカル・ストレージ・コンテナに区分され、
   （ｂ）前記ローカル・ストレージが格納可能な前記データ・セットのローカル・バージョンの合計数を示す第２の数が、前記第１の数を超えるかどうかを判別するステップと、
   （ｃ）前記第２の数が前記第１の数を超える旨の判別に応答して、前記データ・セットの前記第１の数のローカル・バージョンを格納することが可能なローカル・ストレージの前記量を使用するステップと、
   （ｄ）ローカル・バックアップ操作を用いて前記データ・セットのバージョンを前記ローカル・ストレージに格納するための要求を受け取るステップとを含み、
   前記ローカル・バックアップ操作が即時仮想コピー操作または増分仮想コピー操作のいずれかであり、
   （ｅ）前記要求に応答して、前記第１の数より多くのローカル・バージョンがローカル・バックアップ操作でバックアップされる場合、前記ローカル・バックアップ操作に基づき前記ストレージ・コンテナをどのように再使用するかを決定するためにバックアップ・ポリシーを使用するステップをさらに含む、方法。
2. 前記データ・セットの各ローカル・バージョンが、前記ローカル・ストレージ内の前記１つまたは複数のローカル・ストレージ・コンテナに格納される、請求項１に記載の方法。
3. 使用される前記ストレージの量がローカル・ストレージ・コンテナの第３の数であり、前記第１の数および第３の数が等価であり、
   前記第１の数より多くのローカル・バージョンがローカル・バックアップ操作でバックアップされる場合、前記第３の数のストレージ・コンテナをどのように再使用するかを決定するために前記バックアップ・ポリシーを使用するステップをさらに含む、請求項１に記載の方法。
4. 前記ローカル・バックアップ操作が前記即時仮想コピー操作であり、前記バックアップ・ポリシーは、他のローカル・ストレージ・コンテナのうちの１つに他の即時仮想コピー操作がない限り、最も古いフル・コピーを表すローカル・ストレージ・コンテナが再使用されることを示す、請求項３に記載の方法。
5. 前記第１の数が前記第２の数を超える旨の判別に応答して、前記第２の数を超えるいずれのデータ・セットのローカル・バージョンについてもバックアップ操作を失敗させるステップをさらに含む、請求項１に記載の方法。
6. コンピュータ上で実行された場合、請求項１から５のいずれか一項に記載のステップを実行するための、コンピュータ読み取り可能プログラム・コードを備える、コンピュータ・プログラム。
7. データ・セットのローカル・バージョンを格納するためのシステムであって、
   ローカル・ストレージと、
   請求項１から５のいずれか一項に記載のステップを実施するための操作を実行することが可能な論理と、
   を備える、システム。

Images