JP2023542287A - データ・ストレージ・ボリューム回復管理 - Google Patents

データ・ストレージ・ボリューム回復管理 Download PDF

Info

Publication number
JP2023542287A
JP2023542287A JP2023515642A JP2023515642A JP2023542287A JP 2023542287 A JP2023542287 A JP 2023542287A JP 2023515642 A JP2023515642 A JP 2023515642A JP 2023515642 A JP2023515642 A JP 2023515642A JP 2023542287 A JP2023542287 A JP 2023542287A
Authority
JP
Japan
Prior art keywords
volume
data
virtual
restoration
storage
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2023515642A
Other languages
English (en)
Inventor
グドール、ラウリー
ドーソン、エリカ
エム シュヴィングラー、ジョセフ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Publication of JP2023542287A publication Critical patent/JP2023542287A/ja
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1448—Management of the data involved in backup or backup restore
    • G06F11/1451—Management of the data involved in backup or backup restore by selection of backup contents
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0617—Improving the reliability of storage systems in relation to availability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0614—Improving the reliability of storage systems
    • G06F3/0619—Improving the reliability of storage systems in relation to data integrity, e.g. data losses, bit errors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/0671—In-line storage system
    • G06F3/0683—Plurality of storage devices
    • G06F3/0686—Libraries, e.g. tape libraries, jukebox
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/815—Virtual

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Quality & Reliability (AREA)
  • Library & Information Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

データ・ストレージ・システム内のデータのボリュームを復元するためのコンピュータ・プログラム製品、システム、および方法が提供される。ストレージに格納されたデータのボリュームの仮想復元が、ターゲット・ボリュームを使用して実行される。一実施形態では、仮想復元は、ターゲット・ボリュームを、回復ボリュームの仮想復元として回復ボリュームにマッピングするように、ターゲット・ボリュームに関連付けられたメタデータを構成することを含む。回復ボリュームに格納されたデータに対するホストによる要求に応答して、ターゲット・ボリュームを使用して回復ボリュームのデータの物理的復元が実行される。一実施形態では、物理的復元は、仮想復元によってターゲット・ボリュームがマッピングされた回復ボリュームから、ターゲット・ボリュームにデータを転送することを含む。加えて、転送されたデータは、回復ボリューム・データの代わりにターゲット・ボリューム・データとして再ラベル付けされる。

Description

本発明は、データ・ストレージ・システム内のボリュームの回復を管理するためのコンピュータ・プログラム製品、システム、および方法に関する。
データの長期格納のために、さまざまなストレージ・デバイスが利用されている。例えば、データは磁気テープに格納され得る。そのようなテープの集合は、多くの場合、テープ・ライブラリと呼ばれ、データは、テープ・ドライブを使用してテープに書き込まれ、テープから読み取られる。磁気テープは、例えば、カートリッジで運ばれ、必要とされるときに、ロボットによってテープ・ドライブにマウントされ得る。テープ・ドライブにマウントされるときに、カートリッジのテープが、テープ・ドライブの読み取り／書き込みヘッドを通り過ぎて運ばれ、データがカートリッジのテープに書き込まれること、およびテープから読み取られることを可能にする。
メインフレーム・ホストおよびストレージ・コントローラは、テープ・プロトコルを使用して長期ストレージ・デバイスと通信する。仮想テープでは、仮想テープ・サーバ（ＶＴＳ：Virtual Tape Server）がテープ・デバイスをエミュレートする。インターナショナル・ビジネス・マシンズ・コーポレーションのＴＳ７７００は、テープ・ドライブを含むテープ・ライブラリをエミュレートする１つのそのようなＶＴＳである。メインフレーム・ホストは、ＴＳ７７００をテープ・ライブラリであるものとする。したがって、ＴＳ７７００などの仮想テープ・サーバは、テープ・ライブラリであるかのように、メインフレーム・ホストに対し現れて、メインフレーム・ホストと通信する。しかし、仮想テープ・サーバは、物理テープ・カートリッジを扱う代わりに、仮想テープ・ボリュームと考えられ得る論理ボリュームを操作する。テープ・カートリッジと同じ方法で、各論理ボリュームに、ＶＯＬＳＥＲ（volume serial number：ボリューム・シリアル番号）、およびそのボリューム・シリアル番号の特定のバージョンを識別するバージョン番号が割り当てられる。
テープ・ストレージ・デバイスのテープ・ライブラリは、通常、データを格納する準備ができた一連の空のテープ・カートリッジを含む。メインフレーム・ホストは、ＶＯＬＳＥＲによってこれらのテープ・ボリュームを分類し、どのテープ・ボリュームが使用可能であるか、どのテープ・ボリュームがデータを含んでいるか、およびデータの内容が何であるかを記録する。その結果、特定のデータ・セットが必要とされる場合、メインフレームは、特定のデータ・セットをストレージから取り出すために、ＶＯＬＳＥＲによって識別されたどのテープ・ボリュームをテープ・ライブラリからマウントするべきかを知る。あるテープ・ボリュームに格納されたデータが必要とされなくなった後に、そのテープ・ボリュームおよびそれに関連するＶＯＬＳＥＲを再利用するために、そのテープ・ボリュームは「スクラッチ」カテゴリに入れられ得る。
既知のテープ・ストレージ・デバイスでは、ストレージ・マネージャは、やはりＶＯＬＳＥＲによってこれらのテープ・ボリュームを分類して管理する。メインフレーム・ホストとは異なり、テープ・ストレージ・デバイスのストレージ・マネージャ論理は、ＶＯＬＳＥＲによって識別されたテープ・ボリュームの内容を知らないが、そのＶＯＬＳＥＲを有する特定のテープ・ボリュームがテープ・ライブラリ内のどこに格納されているか、およびそのＶＯＬＳＥＲを有するテープ・ボリュームをどのように管理するべきか（例えば、テープ・ボリュームが削除された後にテープ・ボリュームを保持する期間、維持するコピーの数、それらのコピーを行う場所など）を記録する。
単一のテープ・カートリッジ（ＶＯＬＳＥＲ）は、大量のデータを格納できるため、ホストは、通常、テープに書き込む前に、大量のデータを一緒にまとめる。ＶＯＬＳＥＲは、複数のデータ・セット（場合によっては、数千個のデータ・セット）を含むことができる。ＴＳ７７００などの仮想テープ・サーバは、メインフレーム・ホストがアクティブなデータを回収し、ＶＯＬＳＥＲに削除済みとしてマーク付けした後も、ホスト・ユーザによって指定された期間の間、そのＶＯＬＳＥＲを保持してもよい。この慣行は、ホスト内で誰かが、時期尚早にＶＯＬＳＥＲに削除のマークを付けるような、偶発的な活動または悪意のある活動の場合に備えて使用される。ＴＳ７７００では、この慣行はカテゴリ保持と呼ばれる。ユーザは、データを含む任意のボリュームに対して、数時間から数年までの保持期間を設定できる。しかし、ＶＯＬＳＥＲに含まれているデータは、最終的に削除される。
物理テープ・ボリュームであるか、仮想テープ・サーバの論理ボリュームであるかにかかわらず、ボリュームを復元または回復する必要性が生じることがある。例えば、ボリュームの古いバージョンが削除されたが、後で、ボリュームの特定のバージョンがまだ必要とされるということが発見されることがある。このため、データの古いバージョンを保持することが望ましいことがある。回収プロセスに起因して、論理ボリューム上のデータのすべてが有効でなくなったか、またはいずれかのアクティブなデータが別の論理ボリュームに移動された場合、論理ボリュームのバージョンの変更が発生する。これらのボリュームは、スクラッチされ、新しいデータの書き込みに再利用するために再び取り出される。論理ボリュームのバージョンは、データが追加された場合にも変化することがある。この場合、同じＶＯＬＳＥＲが使用され続けるが、バージョン・レベルが変化する。これらの事例のいずれかにおいて、論理ボリュームのより古いバージョンを復元または回復する必要がある場合に備えて、データのより古いバージョンが、ユーザの必要性に基づいて、ある時間の間、保持され得る。
既知の回復プロセス（復元プロセスとも呼ばれる）の１つは、論理ボリュームのより古いバージョンを、削除されたボリュームと同じＶＯＬＳＥＲ識別情報（ＩＤ：identification）を有するボリュームに復元する。しかし、そのＶＯＬＳＥＲのボリュームが最新の有効なデータを含んでおり、保持ポリシーによって「ホールド」プロパティも割り当てられている場合、ボリュームを同じＶＯＬＳＥＲに復元することは、必須のホールド期間の間、変更せずにボリュームをホールドすることを要求するホールド・プロパティに違反する。同様に、復元されるボリュームのＶＯＬＳＥＲがＬＷＯＲＭ（Logical Write Once, Read Many：ロジカル・ライト・ワンス・リード・メニー）として分類されている場合、このより古いバージョンを同じＶＯＬＳＥＲに復元することを許可することは、これらの厳密な保護ルールに違反する。
別の既知の手法は、ボリュームのより古いバージョンを、異なるスクラッチＶＯＬＳＥＲに復元する。しかし、これらの既知の復元方法は、ボリュームが「復元された」と見なされる前に、ボリュームがスクラッチ・ボリュームに物理的にコピーまたは移動されることを必要とする。そのような物理的コピーまたはデータ移動は、通常、ボリュームがストレージから読み取られ、読み取られたデータが変更され、その後、ストレージ・デバイスに再び書き込まれることを必要とする。例えば、復元されているボリュームから読み取られたデータは、通常、復元先のＶＯＬＳＥＲに一致するようにメタデータを更新することによって、再ラベル付けされる。したがって、ＶＯＬＳＥＲを参照するファイルを表すか、またはファイル内に含まれる任意のメタデータが、古いＶＯＬＳＥＲの代わりに新しいＶＯＬＳＥＲを指定するように更新される。しかし、復元されているボリュームのデータの変更は、データの変更または置き換えを禁止する、ボリュームに対する法的制限に違反することがある。また、ＷＲＯＭ（ライト・ワンス・リード・メニー：Write Once, Read Many）などの、読み取り専用としてマーク付けされたボリュームのデータは、読み取り専用制限に違反せずに変更されることも置き換えられることも不可能である。
ストレージ内のデータのボリュームを復元するためのコンピュータ・プログラム製品、システム、および方法が提供される。ストレージに格納されたデータの第１のボリュームの仮想復元が、第２のボリュームを使用して実行される。一実施形態では、第２のボリュームに関連付けられたメタデータは、第２のボリュームを、第１のボリュームの仮想復元として第１のボリュームにマッピングするように構成される。別の態様では、第１のボリュームに格納されたデータに対するホストによる要求に応答して、第２のボリュームを使用して第１のボリュームのデータの物理的復元が実行される。一実施形態では、物理的復元は、仮想復元によって第２のボリュームがマッピングされた第１のボリュームから、第２のボリュームにデータを転送することを含む。加えて、転送されたデータは、第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けされる。
上記の実施形態では、第１のボリュームのデータにアクセスすることは、データに対するアクセスがホストによって要求されるまで延期される。その結果、仮想復元における迅速な低コストの復元が容易にされる。さらに、第１のボリュームの仮想復元および物理的復元の間に、第１のボリュームの復元に関連する第１のボリューム上のデータの変更が回避され得る。したがって、第１のボリュームのデータの変更に関するどのような制限にもかかわらず、復元が実現され得る。
別の実施形態では、データを第１のボリュームから第２のボリュームに転送することは、第２のボリュームをストレージ・ドライブにマウントするためのホストによる要求を受信することと、この要求に応答して、第２のボリュームをストレージ・ドライブにマウントすることと、第１のボリュームをストレージ・ドライブにマウントすることと、第２のボリュームのメタデータによって第２のボリュームにマッピングされた第１のボリュームのデータをコピーすることとを含む。
上記の実施形態では、第１のボリュームのデータにアクセスするために第１のボリュームをマウントすることは、第２のボリュームのマウントがホストによって要求されるまで延期される。その結果、仮想復元は、第１のボリュームが要求された物理的復元のためにマウントされるまで、第１のボリュームの迅速な低コストの復元を容易にする。さらに、物理的復元の間に、データが第１のボリューム上ではなく第２のボリューム上で再ラベル付けされるため、第１のボリュームの仮想復元および物理的復元の間に、第１のボリュームの復元に関連する第１のボリューム上のデータの変更が回避され得る。したがって、第１のボリュームのデータの変更に関するどのような制限にもかかわらず、復元が実現され得る。
さらなる実施形態では、転送されたデータを第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることは、第１のボリュームからコピーされたデータを第１のボリュームの代わりに第２のボリュームのデータであるとして識別するために、データが第２のボリュームに格納されるときに、第１のボリュームから読み取られたヘッダー・データを変更することを含み、第１のボリュームから読み取られたヘッダー・データを変更することが、このデータに対するアクセスがホストによって要求されるまで延期されるようにする。
上記の実施形態では、データを再ラベル付けすることは、第２のボリュームのマウントがホストによって要求されるまで延期される。その結果、仮想復元は、データが、要求された物理的復元のために再ラベル付けされるまで、第１のボリュームの迅速な低コストの復元を容易にする。加えて、第１のボリュームの仮想復元および物理的復元の間に、第１のボリュームの復元に関連する第１のボリューム上のヘッダー・データの変更が回避され得る。代わりに、物理的復元の間に、第２のボリュームに転送されたユーザ・データを再ラベル付けするように、第２のボリューム上のヘッダー・データが変更され、第１のボリューム上のヘッダー・データは変更されない。
さらなる実施形態では、第１のボリュームは、第１のボリューム・シリアル番号を有し、第２のボリュームは、第１のボリューム・シリアル番号と異なる第２のシリアル番号を有する。ユーザ・データが第１のボリュームから読み取られ、読み取られたデータが第２のボリュームにコピーされた際に、第１のボリュームの物理的復元の間に第２のボリュームに格納するためにヘッダー・データを変更することは、ヘッダー・データ内の第１のボリュームの第１のシリアル番号を、ヘッダー・データとして、第２のボリュームの第２のボリューム・シリアル番号に置き換えることを含む。
上記の実施形態では、第２のボリュームのシリアル番号でデータを再ラベル付けすることは、第１のボリュームのデータを要求するために第２のボリュームのマウントがホストによって要求されるまで延期される。その結果、仮想復元は、データが、要求された物理的復元のために異なるシリアル番号で再ラベル付けされるまで、第１のボリュームの迅速な低コストの復元を容易にする。加えて、第１のボリュームの仮想復元および物理的復元の間に、第１のボリュームの復元に関連する第１のボリューム上のヘッダー・データ内のシリアル番号の変更が回避され得る。代わりに、物理的復元の間に、第２のボリュームに転送されたユーザ・データを再ラベ付けするように、第２のボリューム上のシリアル番号ヘッダー・データが変更され、第１のボリューム上のシリアル番号ヘッダー・データは変更されない。
別の実施形態では、第１のボリュームの仮想復元および物理的復元の両方の間に、第１のボリュームの復元による第１のボリュームの変更を防ぐために、第１のボリュームをマウントする前に、第１のボリュームが読み取り専用ボリュームとして分類される。
上記の実施形態では、第２のボリュームのデータに対するどのような変更もなく、仮想復元および物理的復元の両方が実行され得るため、第２のボリュームに対する法的制限またはポリシー制限の順守を保証するために、第２のボリュームが読み取り専用として分類されてよい。したがって、第１のボリュームのデータの変更に関するどのような制限にもかかわらず、復元が実現され得る。
さらに別の実施形態では、第１のボリュームの仮想復元の開始前に、第１のボリュームが保持カテゴリに分類され、保持カテゴリでは、削除を指定された後のある期間の間、ボリュームが保持される。第１のボリュームの仮想復元は、第１のボリュームをホールド・カテゴリに再分類することをさらに含み、ホールド・カテゴリでは、ボリュームの変更が防がれる。第１のボリュームの物理的復元中の、第１のボリュームから第２のボリュームへのデータの転送の完了に応答して、第１のボリュームがホールド・カテゴリから保持カテゴリへ再分類される。
上記の実施形態では、第１のボリュームの復元による第１のボリュームの変更は、第１のボリュームの仮想復元および物理的復元の両方の間では回避され得る。したがって、第１のボリュームの変更が防がれることを保証するために、第１のボリュームがホールド・カテゴリに再分類され得る。したがって、第１のボリュームのデータの変更に関するどのような制限にもかかわらず、復元が実現され得る。
さらに別の実施形態では、少なくとも１つのポリシーが第２のボリュームに割り当てられ、このポリシーは、ボリュームを維持する期間およびボリュームのバージョンの許可された数のうちの少なくとも１つに関するパラメータを定義する。この実施形態では、仮想復元が容易にされ得る。
別の実施形態では、第３のボリュームがストレージにインポートされ、このインポートは、ストレージのボリューム・シリアル付番規則（volume serial numbering convention）に従うボリューム・シリアル番号を有する第４のボリュームを使用して第３のボリュームの仮想復元を実行することを含む。第３のボリュームの仮想復元は、第４のボリュームを第３のボリュームの仮想復元として第３のボリュームにマッピングするように、第４のボリュームに関連付けられたメタデータを構成することを含む。
上記の実施形態では、インポート中に第３のボリュームのデータにアクセスすることは、データに対するアクセスがホストによって要求されるまで延期される。その結果、迅速な低コストのインポートが容易にされる。さらに、第３のボリュームのインポートに関連して、第３のボリューム上のデータの変更が回避され得る。したがって、第３のボリュームのデータの変更に関するどのような制限にもかかわらず、インポートが実現され得る。
さらに別の実施形態では、第２のボリュームが削除され、第３のボリュームを使用して第１のボリュームの第２の仮想復元が実行される。第２の仮想復元は、第３のボリュームを、第１のボリュームの第２の仮想復元として第１のボリュームにマッピングするように、第３のボリュームに関連付けられたメタデータを構成することを含む。
上記の実施形態では、第１のボリュームは、第１のボリュームの第１および第２の仮想復元にわたって変更不可能なままである。その結果、第１のボリュームは、各復元において変更不可能なまま、必要に応じて再帰的に何度も繰り返して復元されてよい。
別の実施形態では、第１のボリュームは、一次ストレージを含んでいるストレージ・サーバに結合された二次ストレージに格納される。第１のボリュームは、第１のボリュームの仮想復元全体を通じて、二次ストレージにおいてアンマウントされたままである。
上記の実施形態では、第１のボリュームのデータにアクセスするために第１のボリュームをマウントすることが、第２のボリュームのマウントがホストによって要求されるまで延期されるため、仮想復元中に、第１のボリュームが二次ストレージにおいてアクセスされないままであり、仮想復元に関連して二次ストレージ内の第１のボリュームからデータを転送する費用を回避する。
本説明に従って、データ・ストレージ・ボリューム回復管理（data storage volume recovery management）を採用するストレージ環境の実施形態を示す図である。 本説明に従って、データ・ストレージ・ボリューム回復管理を採用する、例えばストレージ・コントローラなどの、ホストの実施形態を示す図である。 保持ポリシーを定義するポリシー・プールの実施形態を示す図である。 オブジェクトのバージョンに関する実際のデータを含んでいるバージョン・オブジェクトの実施形態を示す図である。 バージョン・オブジェクトに関するメタデータを含んでいるバージョン・メタデータの実施形態を示す図である。 本説明に従って、データ・ストレージ・ボリューム回復管理を採用する仮想復元または回復プロセスの動作の実施形態を示す図である。 本説明に従って、データ・ストレージ・ボリューム回復管理を採用する物理的復元または回復プロセスの動作の実施形態を示す図である。 図５Ａの仮想回復プロセスの動作のさらに詳細な実施形態を示す図である。 図５Ｂの物理的回復プロセスの動作のさらに詳細な実施形態を示す図である。 図６Ａ～６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図６Ａ～６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図６Ａ～６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図６Ａ～６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図６Ａ～６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図６Ａ～６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図６Ａ～図６Ｂの仮想回復プロセスおよび物理的回復プロセスのさまざまな段階のうちの１つでのＶＴＳのテープ・ライブラリのカタログ・エントリの実施形態を示す図である。 図５Ａおよび図６の仮想回復プロセスのための、回復ボリュームへのターゲット・スクラッチ・ボリューム（target scratch volume）のマッピングを示すＶＴＳのカタログ・エントリの実施形態の図である。 図５Ａおよび図６の仮想回復プロセスのための、回復ボリュームへのターゲット・スクラッチ・ボリュームのマッピングを示すホストのカタログ・エントリの実施形態の図である。 回復ボリュームから読み取られたデータの実施形態を示す図である。 ターゲット・プライベート・ボリューム（target private volume）に格納されたデータの実施形態を示す図である。 図のコンポーネントが実装され得るコンピューティング環境を示す図である。
本説明に従うデータ・ストレージ・ボリューム回復管理は、コンピュータ技術に対する大幅な改善を実現する。本説明に従うデータ・ストレージ回復管理の一態様では、データ・ストレージ・ボリュームの回復は、ターゲット・スクラッチ・ボリュームを回復ボリュームにマッピングするように、ボリュームに関連付けられたメタデータを構成する仮想回復または復元を含む。このようにして、データを回復ボリュームからターゲット・スクラッチ・ボリュームにコピーすることも、他の転送を実行することもなく、仮想回復が完了され得る。メタデータを構成することは、一部の例では、１秒の数分の１で達成され得るが、数ギガバイトのデータをコピーすることは、多くの場合、約１時間以上の時間がかかる可能性がある。その結果、仮想回復は、さまざまな既知の回復方法と比較して、大幅に少ない計算リソースまたは人的資源を使用して、著しく速く完了され得る。さらに、仮想回復は、どのような方法でも回復ボリューム自体を変更せずに、したがって、回復ボリュームを全くマウントせずに完了され得る。その結果、回復ボリュームは、変更不可能なままとすることができ、回復ボリュームが変更されないままであるというさまざまな保持ポリシーまたは法的必要条件を満たす。さらに、データが回復以外の目的に実際に必要とされない限り、仮想回復は、多くの場合、データをコピーすることまたは移動することに関連する著しいコストを回避することを可能にする。
本明細書では、回復ボリュームのデータへのアクセスが、直ちに、または長期間にわたってさえ、必要とされないことが多いということが理解される。その結果、本明細書において説明されているように、仮想回復は、ボリューム回復に関連する即時の必要性、または長期間にわたる必要性さえ満たすことができることが多く、回復ボリュームのデータへの実際のアクセスに対する必要性は、生じないか、またはまだ生じていない。しかし、ボリュームの仮想回復が完了された後のある時点において、回復ボリュームのデータへのアクセスに対する必要性が明らかになるはずであるそれらの事例では、本説明に従うデータ回復管理は、第２の回復プロセス、すなわち、物理的復元または回復プロセスも提供し、このプロセスは、仮想回復プロセスをすでに完了している回復ボリュームのデータへの準備ができているアクセスを提供する。
一実施形態では、物理的回復プロセスは、回復ボリュームからターゲット・ボリュームにデータをコピーすることを含み、ターゲット・ボリュームは、この段階ではスクラッチ・ボリュームの代わりにプライベート・ボリュームと呼ばれることがある。したがって、実質的に「要求に応じた」データ転送を提供し、仮想回復プロセス中のデータ転送を未然に防ぐために、回復ボリュームからターゲット・プライベート・ボリュームにデータをコピーするための回復ボリュームのすべてのマウントは、データに対する必要性が実際に生じるまで延期される。前述したように、仮想回復のためのデータ転送を取り除くことは、仮想回復プロセスの迅速な完了を容易にする。したがって、時間のかかる、リソースを消費するデータ転送は、データに対する必要性が実際に生じて、物理的回復が実施されるまで延期される。
本説明に従う物理的回復プロセスの別の態様では、物理的回復プロセスに関連して回復ボリュームからターゲット・プライベート・ボリュームにデータがコピーされるときに、コピーされたデータが、コピーされたデータが読み取られた回復ボリュームのＶＯＬＳＥＲの代わりにターゲット・プライベート・ボリュームのＶＯＬＳＥＲに現在属していることを示すために、ターゲット・プライベート・ボリュームにおいて、コピーされたデータが再ラベル付けされる。したがって、データのこの再ラベル付けも、仮想回復プロセスの後まで延期され、データにアクセスする必要性が生じた、物理的回復が実施されるときまで延期される。このようにして、コピーされたデータの再ラベル付けは、物理的回復プロセスの実質的に「要求に応じた」データの再ラベル付けであり、仮想回復プロセス中のデータの再ラベル付けに対するすべての必要性を未然に防ぐ。ここでも、物理的回復は、どのような方法でも回復ボリュームを変更せずに完了され得る。その結果、回復ボリュームは、変更不可能なままとすることができ、回復ボリュームが変更されないままであるというさまざまな保持ポリシーまたは法的必要条件を満たす。
本説明に従うデータ・ストレージ回復管理の別の態様では、異なるか、または競合するボリューム・シリアル付番方式または規則を有することがある別のソースから素早く効率的にボリュームをインポートするために、仮想回復プロセスが使用されてよい。一実施形態では、インポートされるボリュームは、例えば、ターゲット・データ・ストレージ・システムの既存のボリューム・シリアル番号規則に従う新しいＶＯＬＳＥＲにマッピングまたは再マッピングされてよい。したがって、インポートされるボリュームは、例えばホストまたはＶＴＳの既存のアクティブなＶＯＬＳＥＲに一致しないか、または他の方法で既存のＶＯＬＳＥＲと競合する、ターゲット・データ・ストレージ・システムの新しいＶＯＬＳＥＲにマッピングまたは再マッピングされてよい。加えて、インポートされるボリュームは、既存のボリューム・シリアル番号範囲規則（volume serial number range conventions）に従い、それによって、既存のボリューム・シリアル番号範囲規則を維持する、ＶＯＬＳＥＲにマッピングまたは再マッピングされてよい。
例えばターゲットＶＴＳにインポートされるボリュームが、特定のアプリケーションに応じて、数百個、数千個、数百万個以上に達することがあるということが理解される。実施形態例の仮想回復プロセスは、仮想回復プロセスを使用してインポートされているどのボリュームもマウントせず、別途ボリュームにアクセスすることもなく、多数のボリュームが迅速にターゲットＶＴＳにインポートされることを可能にする。その結果、各インポートされたボリュームは変更不可能なままとすることができ、かつその後の物理的回復の任意の未来のマウント要求の一部としてオンデマンドで再ラベル付けされるのみであることが分かっているので、インポートされているボリュームは、そのボリュームの内容の有効性を維持するように堅牢にされ得る。例えば、法的な理由のため、インポート時のデータの状態が、ワークロード取得の一貫性のある位置を維持するために、変更不可能なままであることを必要とすることがある。実施形態例の仮想回復プロセスは、ボリューム・シリアル番号（ＶＯＬＳＥＲ）の競合がなく、各インスタンスにアクセスする必要がなく、ソース・インスタンスを変更する必要がない、ボリュームのインポートを可能にする。インポートされたボリュームのデータにアクセスする必要性が生じた場合、前述したように、インポートされたボリュームの要求に応じた物理的回復が実行されてよい。
図１Ａは、第１のネットワーク１０２を経由して、ボリュームの回収またはオブジェクトへの追加の形態でオブジェクトまたはボリュームのデータをストレージ・サーバ１０４に提供する、１つまたは複数のホスト・システムもしくはストレージ・コントローラまたはその両方１００を含んでいるデータ・ストレージ環境の実施形態を示している。「オブジェクト」は、この用語が本明細書において使用されるとき、ボリューム、データ・セット、データベース、論理ドライブ、ファイル・システム、およびデータの任意の他のグループ化を含んでよい。ストレージ・サーバ１０４は、第２のネットワーク１０８を経由したクラウド・ストレージ１０６（ストレージ・サーバ１０４に対してオンサイトまたはオフサイトにあってよい）、物理テープ・カートリッジに格納するためのテープ・ライブラリ１１０、およびストレージ・サーバ１０４の一次ストレージのうちの１つまたは複数にバックアップするために、バックアップ・ボリュームまたはテープ・ボリュームなどのオブジェクトを生成してよい。さらに、バージョン・バックアップ・オブジェクト（version backup objects）が、永続的または一時的に一次ストレージ１１２に格納されることに加えて、クラウドまたはテープ・ストレージに転送されてよい。ストレージ・サーバ１０４は、ＶＯＬＳＥＲなどの一意のシリアル番号を有し、標準的なテープ・マークおよびデータ・ブロックを含む、さまざまなバージョンのバックアップ・オブジェクトのバージョン・オブジェクト３００を生成してよい。
ストレージ・サーバ１０４は、プロセッサ１１４と、プロセッサ１１４によって実行されるプログラムを含んでいるメモリ１１６とを含み、これらのプログラムは、テープ形式などの形式でオブジェクトのバージョン・オブジェクト３００を作成し、テープ・ライブラリ１１０、クラウド・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納する。メモリ１１６は、ストレージ・サーバ１０４の動作を管理するためのオペレーティング・システム１１８と、テープ・ボリュームなどのオブジェクト・バージョン３００を作成して管理し、テープ・ライブラリ１１０、リモート・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納するための、バージョン・マネージャ１２０とを含む。回復マネージャ１２３は、下記にさらに詳細に説明されるように、仮想回復プロセスおよび要求に応じた物理的回復プロセスにおいて、ボリュームの回復を管理する。
図１Ｂを参照すると、ホスト１００は、プロセッサ１１４ｈ（図１Ｂ）と、オブジェクトまたはボリュームのデータをストレージ・サーバ１０４に提供するためにプロセッサ１１４ｈによって実行されるプログラムを含んでいるメモリ１１６ｈとを含む。メモリ１１６ｈは、ホスト１００の動作を管理するためのオペレーティング・システム１１８ｈと、オブジェクトまたはボリュームのデータをストレージ・サーバ１０４に提供するためのバージョン・マネージャ１２０ｈとを含む。加えて、バージョン・マネージャ１２０ｈは、テープ・ライブラリ１１０、リモート・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納される、テープ・ボリュームなどの、オブジェクト・バージョン３００の管理のためのコマンドをストレージ・サーバ１０４に発行する。バージョン・マネージャ１２０ｈは、カタログ１２１ｈの形態でストレージ・サーバ１０４に格納されるか、またはストレージ・サーバ１０４によって格納される、オブジェクトのさまざまな特性を識別するメタデータを維持する。回復マネージャ１２３ｈは、テープ・ライブラリ１１０、リモート・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納される、テープ・ボリュームなどの、オブジェクト・バージョン３００の回復のためのコマンドをストレージ・サーバ１０４に発行する。
再び図１Ａを参照すると、ストレージ・サーバ１０４（図１Ａ）は、ボリューム・シリアル番号（ＶＯＬＳＥＲ）などのシリアル番号をスクラッチ・プール１２２から取得し、オブジェクト・バージョン３００に使用して、オブジェクト・バージョン３００を作成し、テープ・ライブラリ１１０、リモート・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納してよい。オブジェクト／ボリュームのすべてのバージョンは、同じシリアル番号またはＶＯＬＳＥＲを使用する。テープ・ボリューム・シリアル番号またはＶＯＬＳＥＲは、テープ・ボリュームを一意に識別するために使用される。テープ・ストレージの場合、テープ・ラベル内でＶＯＬＳＥＲが指定され、ＶＯＬＳＥＲは、テープに含まれる情報の最初のセットである。テープ・ラベルに加えて、テープ・ボリュームの内部に格納された他のメタデータも、ボリュームのＶＯＬＳＥＲを識別する。
バージョン・マネージャ１２０は、バージョン・オブジェクト３００に関するメタデータを含んでいるバージョン・メタデータ４００をさらに生成してよく、バージョン・メタデータ４００は、バージョン・オブジェクト３００のデータをより高いバージョン番号のバージョン・オブジェクト３００から復元するために使用されてよい。加えて、バージョン・マネージャ１２０は、テープ・ライブラリ１１０、リモート・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納された、テープ・ボリュームなどの、オブジェクト・バージョン３００の管理のためのホスト１００からのコマンドを処理する。ストレージ・サーバ１０４のバージョン・マネージャ１２０は、カタログ１２１ｂの形態でストレージ・サーバ１０４に格納されたか、またはストレージ・サーバ１０４によって格納された、オブジェクトのさまざまな特性を識別するメタデータも維持する。
スクラッチ・プール１２２から取得されたシリアル番号またはＶＯＬＳＥＲは、ポリシー・プール２００に割り当てられてよく、異なるポリシー・プール２００は、異なるデータ保持ポリシーを維持する。１０６、１１２、または１１０などのストレージに書き込むためのオブジェクト・バージョン３００ｉのインスタンスの作成時に、バージョン・マネージャ１２０は、オブジェクト・バージョン３００ｉをストレージ１１２、１１０、１０６にエクスポートするために、オブジェクト・バージョン３００ｉの指示をエクスポート・キュー１２４に追加してよい。
一実施形態では、ストレージ・サーバ１０４は、例として、インターナショナル・ビジネス・マシンズ・コーポレーション（ＩＢＭ）ＴＳ７００仮想テープ・サーバなどの、オブジェクトのバージョンの作成を管理し、ストレージ１１０、１１２にオフロードするための仮想テープ・サーバを備えてよい。仮想サーバは、接続されたホスト／ストレージ・コントローラ１００に対して、テープ・ドライブを含むテープ・ライブラリをエミュレートする。ストレージ・サーバ１０４は、低コストの物理テープ・ライブラリ１１０、クラウド・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数に格納するための、オブジェクトのアーカイブを提供してよい。
１１８、１２０、１２３を含む、メモリ１１６内のプログラム・コンポーネントが、メモリ１１６に読み込まれ、プロセッサ１１４によって実行されるプログラム・コードとして図１Ａに示されている。同様に、１１８ｈ、１２０ｈ、１２３ｈを含む、メモリ１１６ｈ内のプログラム・コンポーネントが、メモリ１１６ｈに読み込まれ、プロセッサ１１４ｈによって実行されるプログラム・コードとして図１Ｂに示されている。代替として、コンポーネントの機能の一部またはすべてが、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuits）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：Field Programmable Gate Array）などのハードウェア・デバイスにおいて実装されるか、または別々の専用プロセッサによって実行されてよい。
メモリ１１６、１１６ｈは、ダイナミック・ランダム・アクセス・メモリ（ＤＲＡＭ：Dynamic Random Access Memory）、相変化メモリ（ＰＣＭ：phase change memory）、磁気抵抗ランダム・アクセス・メモリ（ＭＲＡＭ：Magnetoresistive random-access memory）、スピン・トランスファー・トルク（ＳＴＴ：Spin Transfer Torque ）－ＭＲＡＭ、ＳＲＡＭストレージ・デバイス、ＤＲＡＭ、強誘電体ランダム・アクセス・メモリ（ＦｅＴＲＡＭ：ferroelectric random-access memory）、ナノワイヤベースの不揮発性メモリ、および不揮発性ダイレクト・インライン・メモリ・モジュール（ＤＩＭＭ：Direct In-Line Memory Modules）、ＮＡＮＤストレージ（例えば、フラッシュ・メモリ）、半導体ドライブ（ＳＳＤ：Solid State Drive）ストレージ、不揮発性ＲＡＭなどの、揮発性または不揮発性の１つまたは複数のメモリ・デバイスを備えてよい。
バージョン・マネージャ１２０は、ネットワークを経由して、オブジェクト・バージョン３００を、テープ・ライブラリ１１０、リモート・ストレージ１０６、および一次ストレージ１１２のうちの１つまたは複数にエクスポートしてよい。例えば、図１Ａは、第２のネットワーク１０８を経由してリモート・クラウド・ストレージ１０６に結合されたストレージ・サーバ１０４を示している。代替の実施形態では、クラウド・ストレージ１０６は、例えば、ストレージ・サーバ１０４と同じ建物にあるなど、ローカルであってよい。クラウド・ストレージ１０６は、クラウド・ストレージ・サービス・プロバイダによって提供されたクラウド・ストレージ・システムを備えてよい。クラウド・ストレージ１０６のサービス・プロバイダの例としては、ＤｒｏｐＢｏｘ（登録商標）、Ｇｏｏｇｌｅ（登録商標）Ｄｒｉｖｅ、Ａｍａｚｏｎ Ｃｌｏｕｄ Ｄｒｉｖｅ（登録商標）、Ａｍａｚｏｎ（登録商標）Ｓ３、ＩＢＭ（登録商標）Ｃｌｏｕｄ Ｏｂｊｅｃｔ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍ（商標）などが挙げられる（ＤｒｏｐｂｏｘはＤｒｏｐｂｏｘ社の登録商標であり、ＧｏｏｇｌｅはＧｏｏｇｌｅ社の登録商標であり、ＡｍａｚｏｎおよびＡｍａｚｏｎ Ｃｌｏｕｄ ＤｒｉｖｅはＡｍａｚｏｎ Ｔｅｃｈｎｏｌｏｇｉｅｓ社の商標であり、ＩＢＭおよびＣｌｏｕｄ Ｏｂｊｅｃｔ Ｓｔｏｒａｇｅ Ｓｙｓｔｅｍは世界中においてＩＢＭの商標である）。
バージョン・マネージャ１２０は、一次ストレージ１１２を仮想テープ・キャッシュとして使用して、作成されるオブジェクト・バージョン３００を、それらがストレージ１０６、１１０、１１２に移行するためにエクスポート・キュー１２４に追加される前に、格納する。さらなる実施形態では、一次ストレージ１１２は、使用可能なストレージ１０６、１１０、１１２がない場合に、オブジェクト・バージョン３００を格納するために使用されてよい。
一次ストレージ１１２は、磁気ハード・ディスク・ドライブ、半導体電子機器（ＥＥＰＲＯＭ（Electrically Erasable Programmable Read-Only Memory：電気的消去可能プログラマブル読み取り専用メモリ）、フラッシュ・メモリ、フラッシュ・ディスク、ランダム・アクセス・メモリ（ＲＡＭ：Random Access Memory）ドライブ、ストレージクラス・メモリ（ＳＣＭ：storage-class memory）など）から成る半導体ストレージ・デバイス（ＳＳＤ：solid state storage device）、相変化メモリ（ＰＣＭ）、抵抗ランダム・アクセス・メモリ（ＲＲＡＭ：resistive random access memory）、スピン・トランスファー・トルク・メモリ（ＳＴＭ－ＲＡＭ：spin transfer torque memory）、導電性ブリッジＲＡＭ（ＣＢＲＡＭ：conductive bridging RAM）、磁気ハード・ディスク・ドライブ、光ディスク、テープなどの、さまざまな種類またはクラスのストレージ・デバイスを備えてよい。一次ストレージ１１２内のボリュームは、単純ディスク束（ＪＢＯＤ：Just a Bunch of Disks）、直接アクセス・ストレージ・デバイス（ＤＡＳＤ：Direct Access Storage Device）、新磁気ディスク制御機構（ＲＡＩＤ：Redundant Array of Independent Disks）アレイ、仮想化デバイスなどの、デバイスのアレイからさらに構成されてよい。さらに、ストレージ１１２は、異なるベンダーからの異種ストレージ・デバイス、および第２の種類のストレージ・デバイス（例えば、ＳＳＤ）より遅いデータ転送速度を有する第１の種類のストレージ・デバイス（例えば、ハード・ディスク・ドライブ）などの、異なる種類のストレージ・デバイスを備えてよい。クラウド・ストレージ１０６およびテープ・ライブラリ１１０は、一次ストレージ１１２と比べて、二次ストレージと見なされてよい。
ボリューム・データをストレージ・サーバ１０４に伝達するためにホスト／ストレージ・コントローラ１００によって使用される第１のネットワーク１０２は、１つまたは複数の相互接続されたローカル・エリア・ネットワーク（ＬＡＮ：Local Area Networks）、ストレージ・エリア・ネットワーク（ＳＡＮ：Storage Area Networks）、広域ネットワーク（ＷＡＮ：Wide Area Network）、ピアツーピア・ネットワーク、ワイヤレス・ネットワークなどの、ストレージ・ネットワークを含んでよい。第２のネットワーク１０８は、クラウド・ストレージ１０６などのリモート・ストレージがアクセスできる、インターネット、広域ネットワーク（ＷＡＮ）などのネットワークを含んでよい。代替の実施形態では、第１のネットワーク１０２および第２のネットワーク１０８は同じネットワークであってよく、一次ストレージ１１２およびテープ・ライブラリ１１０のうちの１つまたは複数は、ネットワークを経由してアクセスできるリモート・ストレージであってもよい。
図２は、インスタンス２００ｉには、書き込むオブジェクトまたはボリュームのオブジェクト・シリアル番号（例えば、ＶＯＬＳＥＲ）が割り当てられる、ポリシー・プール２００のインスタンス２００ｉの実施形態を示しており、プールを識別するプール識別子２０２、プールに割り当てられた割り当て済みオブジェクト・シリアル番号（ＶＯＬＳＥＲ）２０４、オブジェクト・シリアル番号２０４に関してプールに含まれているオブジェクト・バージョン２０６、およびオブジェクト・バージョンをポリシー・プール２００内に保持する期間を決定するための１つまたは複数の保持ポリシー２０８を含んでいる。
保持ポリシーの例としては、以下が挙げられる。
－バージョンのバージョン・メタデータ４００ｉおよびバージョン・オブジェクト３００ｉのデータを含む、保持する以前のバージョンの最大数。
－オブジェクトのバージョン・メタデータ４００ｉおよびバージョン・オブジェクト３００ｉのデータを含む、以前のバージョン情報を保持する日数の最大数。
－バージョン・オブジェクト３００ｉのデータが保持される、以前のバージョンの最大数。
－バージョン・オブジェクト３００ｉのバージョン番号がｋの倍数に１を足した値である場合（例えば、オブジェクトのバージョン番号＝１＋ｘ＊ｋである（ｘはゼロより大きい整数である）場合）に、バージョン・オブジェクト３００ｉのデータが保持されるように、オブジェクトのｋ個のバージョンごとに１つのバージョンを保持する。
図３は、ホスト／ストレージ・コントローラ１００から送信されたオブジェクト・データまたはボリューム・データから作成されるバージョン・オブジェクトのインスタンス３００ｉを示しており、バージョンが作成されるオブジェクト／ボリュームに割り当てられたオブジェクト・シリアル番号（例えば、ＶＯＬＳＥＲ）、オブジェクト・バージョンが作成されたときの作成タイムスタンプ３０４、オブジェクトのバージョン番号３０６、最近追加されたデータを含む、バージョン・オブジェクト３００ｉに含まれているホスト／ストレージ・コントローラ１００からのバージョンＶ１～Ｖｎのオブジェクト・データのバージョンごとのオブジェクト・バージョン・データ３０８１～３０８ｎの１つまたは複数のインスタンス、およびストレージ・サーバ１０４に送信されたオブジェクト・バージョンを作成したホスト／ストレージ・コントローラ１００によってオブジェクト・バージョンの末尾に追加されるホスト・トレーリング・メタデータ（host trailing metadata）３１２を含んでいる。ホスト・トレーリング・メタデータ３１２は、オブジェクトの構造および形式に関する情報、ならびにデータをオブジェクトに生成したホスト／ストレージ・コントローラ１００に関する情報を含んでよい。
図４は、バージョン・オブジェクト３００ｉに関するメタデータを含んでいるバージョン・メタデータ４００のインスタンス４００ｉを示しており、インスタンス４００ｉは、バージョン・オブジェクト３００ｉとは別に維持されてよく、空間を節約するために前のバージョンのバージョン・オブジェクト３００ｉが削除された場合に保持されてよい。バージョン・メタデータのインスタンス４００ｉは、割り当て済みオブジェクト・シリアル番号（例えば、ＶＯＬＳＥＲ）４０２、割り当てられたオブジェクトおよびシリアル番号４０２が含まれているポリシー・プール４０４、バージョン・オブジェクトのバージョン番号４０６、バージョン・オブジェクト３００ｉが作成されたときの作成タイムスタンプ４０８、バージョン番号４０６のデータを含んでいる、より高いバージョンの１つまたは複数のバージョン・オブジェクト３００ｊを示すバージョン位置４１０、バージョン・メタデータ４００ｉによって表されたオブジェクト３００ｉのオブジェクト・サイズ４１２、バージョン・オブジェクトのデータがその後のバージョン・オブジェクト３００ｊに含まれている場合にバージョン・オブジェクトが終了する位置を示す終了オフセット４１４（この位置で、バージョン番号４０６の追加されたデータが終了する）、およびオブジェクト・データを提供するホスト／ストレージ・コントローラ１００によって追加された情報を含んでおり、バージョン・オブジェクト３００ｉの末尾に位置しているホスト・トレーリング・メタデータ４１６を含んでよい。新しいデータおよび変更が追加されるときに、バージョン番号４０６のホスト・トレーリング・メタデータ３１２が上書きされ得るため、ホスト・トレーリング・メタデータ３１２は、４１６としてバージョン・メタデータ４００ｉに保存される。これによって、バージョン・オブジェクト３００ｉが元のホスト・トレーリング・メタデータ３１２を使用して復元されることを可能にする。
バージョン・メタデータ４００ｉは、あるバージョンのデータの開始および終了を識別するために必要とされる任意の他の情報を維持する。
バージョン・マネージャ１２０は、保持ポリシーが、バージョン・メタデータ４００の期限が切れて、バージョン・メタデータ４００を削除する、バージョン保持期間の終了を決定するまで、バージョン・メタデータ４００を維持することに加えて、オブジェクトの実際のデータを含んでいるバージョン・オブジェクト３００も維持する。バージョン・メタデータ４００は、現在のバージョン番号またはより高いバージョン番号のオブジェクト３００からのバージョン・メタデータ４００において識別されるバージョンのいずれかを識別し、復元のためにアクセスするために使用されてよい。したがって、ユーザによって、削除のためにボリュームの特定のバージョンがマーク付けされた場合、それにもかかわらず、そのボリューム・バージョンのデータは、本明細書において説明されているように、削除されたボリュームのそのバージョンに割り当てられた保持ポリシーによって定義された保持期間の期限が切れていない限り、物理的回復プロセスによって、プライベート・ボリュームへの復元のためにアクセスされ得る。したがって、そのボリューム・バージョンを識別するバージョン・メタデータ４００、およびオブジェクトの実際のデータを含んでいるバージョン・オブジェクト３００がまだ存在する場合、削除されたボリュームのデータが、物理的回復プロセスによって、新しいボリュームへの復元のためにアクセスされ得る。しかし、適用可能な保持ポリシーに従って、そのボリューム・バージョンを識別するバージョン・メタデータ４００、およびオブジェクトの実際のデータを含んでいるバージョン・オブジェクト３００が破棄された後に、削除されたボリュームは回復され得ない。
本明細書では、ボリューム回復管理は、ストレージ空間の使用における効率の改善を実現する関連するメタデータ４００と共にオブジェクト３００として格納されたボリュームに関連して説明されたが、本説明に従うボリューム回復管理が、他のデータおよびメタデータの格納技術を利用するデータ・ストレージ・システムにおいて利用され得るということが理解される。例えば、本説明に従うボリューム回復管理は、ボリュームの各バージョンが、ポリシー保持期間の期限切れによって破棄されるまで、別個のユニットとして全体的に格納されて保持されるデータ・ストレージ・システムにおいて、利用されてよい。
上記に示されたように、本説明に従うボリューム回復管理は、回復ボリュームをマウントすることを必要とせず、回復ボリュームのどのような変更も必要としないボリュームの復元を提供する、仮想回復プロセスを提供する。加えて、物理的回復プロセスは、回復ボリュームのデータが実際にアクセスされるまで、ターゲット・プライベート・ボリュームにコピーされたデータの「要求に応じた」再ラベル付けを提供する。
図５Ａは、この例ではターゲット・スクラッチ・ボリュームＶｏｌＰに仮想的に回復される回復ボリュームＶｏｌＲに関する仮想回復プロセスの一実施形態を示している。図５Ａの仮想回復プロセスは、本明細書では仮想復元プロセスとも呼ばれる。図６Ａは、図５Ａに示された仮想回復プロセスの動作のさらに詳細な実施形態を示している。図５Ａおよび図６Ａに関連してさらに詳細に説明されるように、図５Ａの仮想回復プロセスは、ターゲット・スクラッチ・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲにマッピングするマッピング・プロセス５０４（図５Ａ）を含んでいる。本説明に従うボリューム回復の１つの態様では、図５Ａに示された仮想回復の完了時に、ホスト１００が回復ボリュームＶｏｌＲのデータにアクセスする必要がない限り、ボリュームＶｏｌＲの回復が完了したと見なされてよい。
一方、図５Ｂは、ホスト１００が、回復以外の目的で回復ボリュームＶｏｌＲのデータに実際にアクセスする必要がある場合の、本説明に従う物理的回復プロセスの一例を示している。図５Ｂの物理的回復プロセスは、本明細書では物理的復元プロセスとも呼ばれる。下記にさらに詳細に説明されるように、回復ボリュームＶｏｌＲに格納されているユーザ・データに対するホスト１００による要求に応答して、図５Ａの仮想回復プロセスによって回復ボリュームＶｏｌＲにマッピングされているターゲット・スクラッチ・ボリュームＶｏｌＰを使用して、回復ボリュームＶｏｌＲの物理的復元（図５Ｂ）が実行される。物理的復元は、回復ボリュームＶｏｌＲから、図５Ａの仮想復元によってターゲット・スクラッチ・ボリュームＶｏｌＰがマッピングされたターゲット・プライベート・ボリュームＶｏｌＰへの、要求に応じたデータのコピー（矢印５１４によって表されている）を含み、ＶｏｌＲデータの代わりにＶｏｌＰデータとしてコピーされたデータを再ラベル付けするための、要求に応じたデータ・ヘッダーの変更（矢印５１８によって表されている）も含む。このようにして、回復ボリュームＶｏｌＲのデータにアクセスしてコピーすることは、要求に応じるときまで、すなわち、データへのアクセスがホストによって要求されるまで延期される。さらに、データの再ラベル付けも、要求に応じたプロセスであり、ヘッダーの変更も、データへのアクセスがホストによって要求されるまで延期される。テープ・ラベルに加えて、テープ・ボリュームの内部に格納された他のメタデータが、ボリュームのＶＯＬＳＥＲを識別する。したがって、ＶＯＬＳＥＲの変更に起因してテープ・ボリュームのデータを再ラベル付けするために、このＶＯＬＳＥＲを参照するすべてのファイル名およびファイル内のメタデータも、再ラベル付けプロセスの一部として更新される。その結果、ソース・ボリューム・シリアル番号（ＶＯＬＳＥＲ）を直接参照するボリュームの内部の、ターゲット・プライベート・ボリュームＶｏｌＰに格納するために回復ボリュームＶｏｌＲから読み取られたすべての既知のメタデータが、物理的復元の一部として、ターゲット・ボリュームに格納するために更新される。
一実施形態では、図５Ａの仮想回復プロセスのマッピング・プロセス５０４は、ホスト１００がターゲット・プライベート・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲであるかのように扱うように、ホストによって維持されかつターゲット・プライベート・ボリュームＶｏｌＰに関連付けられたメタデータを構成することによって、実現される。加えて、ストレージ・システムのＶＴＳは、後に図５Ａの仮想回復プロセスが完了するとホスト１００が回復ボリュームＶｏｌＲ内のデータに実際にアクセスすることが必要になる場合に備えて、回復ボリュームＶｏｌＲを指し示すように、ＶＴＳによって維持されかつターゲット・スクラッチ・ボリュームＶｏｌＰに関連付けられたメタデータを構成する。
本説明に従うボリューム回復の一態様に従って、ホスト１００が回復ボリュームＶｏｌＲ内のデータにアクセスする必要がない限り、ホスト１００が、単に回復の目的ではなく適用の目的で、回復ボリュームＶｏｌＲのデータにアクセスすることを実際に必要とするまで、図５Ａに示された仮想回復プロセスが、回復ボリュームＶｏｌＲからスクラッチ・ボリュームＶｏｌＰにデータを実際に転送する必要性を未然に防ぐということが理解される。したがって、図５Ａの仮想回復プロセスの場合、実際のデータ転送が必要とされないため、ターゲット・スクラッチ・ボリュームＶｏｌＰおよび回復ボリュームＶｏｌＲは、図５Ａではアンマウントされているとして示されている。図５Ａの仮想回復プロセスが、回復ボリュームＶｏｌＲからターゲット・スクラッチ・ボリュームＶｏｌＰにデータをコピーする代わりに、ターゲット・スクラッチ・ボリュームＶｏｌＰに関連付けられたメタデータを構成することを対象にするため、図５Ａの仮想回復プロセスは、ボリュームＶｏｌＲからボリュームＶｏｌＰへの実際のデータ転送と比較して、素早く完了され得る。
一方、ボリュームが「復元された」と見なされる前に、ボリュームが回復され、スクラッチ・ボリュームに物理的にコピーまたは移動されることを必要とする回復方法がすでに知られている。データを移動（コピー）する必要があることには、次のような複数の不利益がある。テープ・ボリュームが非常に大きく（通常は４ＧＢ以上のサイズに）なり得るため、データの移動（コピー）は時間がかかる可能性がある。また、そのデータが、極端な状況下を除いて全くアクセスされないことがあるアーカイブ・データである場合、データをコピーして新しいＶＯＬＳＥＲに格納することには、時間がかかる。通常、ユーザは、プロセスが確実に完了するように、プロセスを監視することも行うため、単一の大きいボリュームを処理するのに１時間かかる場合、誰かが、そのプロセスを完了まで監視する。データの移動（コピー）は、メモリ、ＣＰＵ、およびディスクの利用などの、システム・リソースも必要とする。データの移動（コピー）は、ＶＴＳまたは物理テープ・ライブラリによって実施される場合にテープ・デバイスの使用も必要とする。これらのテープ・デバイスは、より重要な生産作業の代わりに、この作業を行うことに束縛される。データが、読み取られるときに追加コストが発生する（クラウド・ストレージ・システムなどの）システムのみに存在する場合、そのデータを読み取る必要があることは、費用がかかる可能性がある。
さらに、一部の環境では、アーカイブ・インスタンスは、法的にホールドされると見なされ、変更または置き換えが法的に許可されず、「読み取り専用」として扱われるようなものであることがある。既知の回復方法を妨げることがある環境の他の例としては、ＷＲＯＭ（ライト・ワンス・リード・メニー）などの、厳密な保持ポリシーまたは媒体ポリシーを有するボリュームが挙げられる。
一方、本説明に従う仮想回復は、どのような物理的データ移動も伴わずに、ボリュームのより古いバージョンをスクラッチ・ボリュームに復元する能力をユーザに提供する。実際のデータを移動する代わりに、新しいスクラッチ・ボリュームをボリュームの古いバージョンにマッピングするメタデータを変更することのみが必要である。ボリュームのメタデータを変更することは、通常、完了するために１秒未満しか必要とせず、大きいボリュームの実際のデータ・コピーに通常使用されるリソースの量と比較して、無視できる量のリソースしか必要としないことがある。さらに、回復ボリュームが、読み取り動作によって課金するクラウド・システムなどのシステムに格納される場合に、本説明に従う仮想回復は、追加コストを取り除くことができる。データが物理的にコピーされかつボリュームのヘッダー・データが変更される物理的回復は、ホストがデータを実際に必要とするまで延期され、ゆえに、ホストがボリュームをマウントするまで延期され得るため、ホストがデータを実際に読み取ることを常に必要としない場合、回復プロセスにおいて、データを読み込むことに対するクラウドの課金が完全に回避され得る。
図６Ａのブロック６０２～６２２は、ホスト１００の視点から、図５Ａの仮想回復プロセスのさらに詳細な例を示している。図６Ｂのブロック６３０～６５０は、ホスト１００の視点から、図５Ｂの物理的回復プロセスのさらに詳細な例を示している。
図６Ａの例では、ホスト１００の回復マネージャ１２３ｈは、コマンド（「コマンド」とラベル付けされた矢印６０４によって表されている）をＶＴＳストレージ・システムのテープ・ライブラリに発行すること（図６Ａのブロック６０２）によって仮想回復（図５Ａ）を開始し、このコマンドはボリュームの復元を要求する。一実施形態では、このコマンドは、ホスト１００が回復するために必要とするボリュームの数、およびどのスクラッチ・カテゴリからターゲット・ボリュームが選ばれ得るかを示す。そのようなコマンドまたは要求は、手動で、または管理インターフェイスなどの適切なインターフェイスを介して自動的に、発行されてよい。一実施形態では、要求は、次のような形式であってよい。
LIBRARY REQUEST, library-name, RECOVER, NUM, N, C
ここで、コマンドの名前が「LIBRARY REQUEST」であり、パラメータ「library-name」が、コマンドが対象にするターゲット・ライブラリを識別し、パラメータ「RECOVER」が、実行される動作を識別し、パラメータ「NUM, N」が、回復されるボリュームの数を識別し、パラメータ「C」が、ターゲット・スクラッチ・ボリュームが選ばれるスクラッチ・カテゴリを識別する。したがって、要求
LIBRARY REQUEST, library-name, RECOVER, NUM, 1, 0002
は、スクラッチ・カテゴリ０００２をターゲット・カテゴリとして使用する単一の論理ボリュームの復元を要求する。特定のアプリケーションに応じて、他のコマンドまたは要求の形式の名前、およびパラメータが使用されてよいということが理解される。
実施形態例では、図６Ａのブロック７０２～７２６は、例えばＶＴＳ（仮想テープ・サーバ）１０４などのストレージ・サーバ１０４のテープ・ライブラリの視点から、図５Ａの仮想回復プロセスの１つの例を示しており、図６Ｂのブロック７３８～７６０は、ストレージ・システムのＶＴＳストレージ・サーバ１０４のテープ・ライブラリの視点から、図５Ｂの物理的回復プロセスの一例を示している。図６Ａの例では、指定されたスクラッチ・カテゴリから取得される指定された数のボリュームに対する仮想回復プロセスの開始を要求するブロック６０２（図６Ａ）のコマンド６０４に応答して、ＶＴＳ１０４の回復マネージャ１２３がコマンドを受信し（図６Ａのブロック７０２）、識別されたスクラッチ・カテゴリから特定の１つまたは複数のボリュームを選択し（図６Ａのブロック７０２）、特殊なホールド・カテゴリに入れる。
図７Ａは、本明細書ではテープ・ライブラリ・カタログと呼ばれる適切なデータベース内の、ストレージ・デバイスのＶＴＳ１０４のテープ・ライブラリによって維持されるメタデータを、表形式で示している。図７Ａの例は、ボリューム・シリアル番号Ｌ０００００、バージョンＶ１、ボリューム・シリアル番号Ｌ０００００、バージョンＶ２、およびスクラッチ・カテゴリ０００２内にあるとして分類されるスクラッチ・ボリュームＳ９９９９９、という３つのボリュームの３つのエントリを示している。簡単にするために、ＶＴＳカタログが、３つのエントリを含んでいるように示されているが、ＶＴＳテープ・ライブラリ・カタログが、特定のアプリケーションに応じて数千個以上のエントリを含むことがあるということが理解される。
ホストからのコマンド
LIBRARY REQUEST, library-name, RECOVER, NUM, 1, 0002
に応答して、ＶＴＳ１０４の回復マネージャ１２３は、図５Ａに示された仮想回復プロセスのために、例えば、一般的なスクラッチ・カテゴリ０００２のスクラッチ・ボリュームＳ９９９９９（図７Ａ）を選択してよい（図６Ａのブロック７０２）。その場合、ＶＴＳ１０４は、一般的なスクラッチ・カテゴリ０００２からスクラッチ・ボリュームＳ９９９９９を選択し、このボリュームを、例えば図７Ｂに示されているようなカテゴリＹ０００などの、特殊なホールド・カテゴリに一時的に入れる（図６Ａのブロック７１０）。加えて、ＶＴＳ１０４の回復マネージャ１２３は、矢印７１２によって表されているように、ホストによって発行された要求に応答して、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームが指定されたスクラッチ・カテゴリ０００２から取得されたことをホスト１００の回復マネージャ１２３ｈに知らせる応答を、ホストに発行する。
ホスト１００の回復マネージャ１２３ｈは、ボリューム・シリアル番号Ｓ９９９９９を有するものとして要求されたスクラッチ・ボリュームの識別情報を受信した場合（図６Ａのブロック６０６）、ボリューム・シリアル番号Ｓ９９９９９を有するターゲット・スクラッチ・ボリュームが他のホストまたは他のホストのプロセスによって別の目的に使用されないことを保証するために、矢印６１２によって提示されているように、このターゲット・スクラッチ・ボリュームをプライベート・カテゴリに入れられることを要求する別のコマンドを、ＶＴＳ１０４に発行する（図６Ａのブロック６１０）。下記に説明されるように、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームは、図５Ａに示された仮想回復プロセスのために、ボリュームＶｏｌＰ（図５Ａ）によって表されたターゲット・スクラッチ・ボリュームとして使用される。コマンド６１２に応答して、ＶＴＳ１０４の回復マネージャ１２３は、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームを、図７Ｃに示されているカテゴリＣ０００などのプライベート・カテゴリに入れる（図６Ａのブロック７１８）。
ホスト１００の回復マネージャ１２３ｈは、それ自身のプライベートな使用のために、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームを予約した場合、矢印６１６によって表されているように、１つまたは複数の保持ポリシーをボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームに割り当てるためのコマンドを、ＶＴＳ１０４に発行する（図６Ａのブロック６１４）。これらのポリシーは、例えばボリュームが破棄され得る前の、ボリュームが保持される期間を定義する。
例えば、ホスト１００は、既存のMVS LIBRARY LMPOLICYコマンドなどの既知のコマンドを使用して、ポリシーを、回復において使用される「ｎ個」の（現在はプライベートである）要求されたボリュームに割り当ててよい（図６Ａのブロック６１４）。この例では、保持ポリシーをスクラッチ・ボリュームＳ９９９９９に割り当てるために、次のパラメータと共にLIBRARY LMPOLICYコマンドが使用される。
LIBRARY LMPOLICY, S99999, SG=SGRECOVER, MC=MCRECOVER, SC=SCRECOVER, DC=DCRECOVER
ＶＴＳ１０４のテープ・ライブラリで確立されたポリシーは、他のデータに使用される既存のポリシーとするか、または回復の目的のための新しいポリシーとすることができる。
ポリシー割り当てコマンド６１６の受信に応答して、ＶＴＳ１０４は、コマンド６１６によって示された１つまたは複数のポリシーを、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームに割り当てる（ブロック７１８）。ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームへのポリシーの割り当ては、図７Ｄでは、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームがボリューム・カテゴリＣ０００に割り当てられることとして表されている。このようにして、ポリシーの動作が、ＶＴＳのテープ・ライブラリで指定されたポリシー名に関連付けられる（図６Ａのブロック７１８）。
ホスト１００の回復マネージャ１２３ｈは、それ自身のプライベートな使用のために、ボリューム・シリアル番号Ｓ９９９９９を有するスクラッチ・ボリュームを予約し、適切な保持ポリシーをそのスクラッチ・ボリュームに割り当てた場合、矢印６２０によって表されているように、回復コマンドをＶＴＳ１０４に発行する（図６Ａのブロック６１８）。本明細書ではMVS LIBRARY RECOVERと呼ばれる回復コマンドは、回復されるために選択されたボリューム、およびターゲット・スクラッチ・ボリュームになるように選択されたボリュームを識別する。例えば、MVS LIBRARY RECOVERコマンドは、次のようにパラメータが指定されてよい。
LIBRARY REQUEST, library-name, RECOVER, S99999, L00000, V2
したがって、この例の回復コマンド６２０は、この例ではＶＴＳカタログ（図７Ｄ）の３番目のエントリに表されているプライベート・スクラッチ・ボリューム（private scratch volume）Ｓ９９９９９を、ターゲット・スクラッチ・ボリュームとして識別する。したがって、この例では、プライベート・スクラッチ・ボリュームＳ９９９９９が、図５Ａの仮想回復プロセスにおけるターゲット・スクラッチ・ボリュームＶｏｌＰになるように、回復コマンド６２０によって選択されている。
この例では、回復コマンド６２０は、図７ＤのＶＴＳテープ・ライブラリ・カタログの２番目のエントリによって表されているように、回復ボリュームを、ボリューム・シリアル番号Ｌ０００００、バージョンＶ２であり、ボリューム・カテゴリＣ０００に分類されているとしてやはり識別する。したがって、この例では、回復ボリュームＬ０００００、バージョンＶ２が、図５Ａの仮想回復プロセスにおける回復ボリュームＶｏｌＲになるように選択されている。
一部の実施形態では、図５Ａの仮想回復プロセスは、適切なユーザ・インターフェイスを介してユーザによって開始されてよい。仮想回復プロセスが開始された後に、ホスト１００は、一実施形態では、図６Ａのコマンドを自動的に発行することができる。他の実施形態では、図６Ａに関連して説明されたコマンドのうちの１つまたは複数は、ホストの適切なユーザ・インターフェイスを介して、ホスト１００からユーザによって手動で発行されてよい。
仮想回復プロセス（図５Ａ）のための回復ボリュームＶｏｌＲおよびターゲット・スクラッチ・ボリュームＶｏｌＰを識別する、ホスト１００によって発行された回復コマンド６２０に応答して、ＶＴＳ１０４の回復マネージャ１２３は、図５Ａに示された仮想回復プロセスを実施し（図６Ａのブロック７２０）、ターゲット・スクラッチ・ボリュームＶｏｌＰを使用してボリュームＶｏｌＲを仮想的に回復する。仮想回復プロセスの一実施形態では、ＶＴＳ１０４は、回復ボリュームＶｏｌＲ（この例では、ボリュームＬ０００００、Ｖ２）の状態を、ＶＴＳテープ・ライブラリ・カタログに関して図７Ｃに示されている前の保持状態から、ＶＴＳテープ・ライブラリ・カタログに関して図７Ｄに示されているホールド状態に変更する（図６Ａのブロック７２２）。
この例では、ホールド状態において、回復ボリュームＶｏｌＲは、以前のすべてのプロパティが維持され、回復プロセスによって回復ボリュームＶｏｌＲが変更されない、すなわち、回復ボリュームＶｏｌＲが変更不可能であることを保証するために、読み取り専用としてマーク付けされる（図６Ａのブロック７２２）。ターゲット・スクラッチ・ボリュームＶｏｌＰ（この例では、ボリュームＳ９９９９９）も、クライアントの選好に応じて、変更不可能として、または読み取り／書き込みボリュームとして扱われ得る。
したがって、図５Ａの仮想回復の一部として、ホスト１００は、仮想回復プロセスのための回復ボリュームＶｏｌＲまたはプライベート・ターゲット・スクラッチ・ボリュームＶｏｌＰのいずれかのどのような監視も完全に回避し、仮想回復プロセスの間に、ストレージ・サーバのテープ・ドライブまたは他のストレージ・ドライブを、他の使用のために解放したままにすることができる。ホスト１００に、回復ボリュームＶｏｌＲのデータにアクセスする実際の必要性が生じない限り、回復ボリュームＶｏｌＲおよびターゲット・スクラッチ・ボリュームＶｏｌＰの両方がアンマウントされたままであり得る。しかし、回復ボリュームＶｏｌＲのデータにアクセスする必要性が生じた場合、下記に説明されるように、図５Ｂの物理的回復が実施されてよい。
仮想回復プロセスの別の態様では、回復コマンド６２０の受信（図６Ａのブロック７２２）にさらに応答して、ＶＴＳ１０４の回復マネージャ１２３は、仮想回復プロセスのために、回復ボリュームＶｏｌＲ（この例では、ボリュームＬ０００００、Ｖ２）をターゲット・スクラッチ・ボリュームＶｏｌＰ（この例では、ボリュームＳ９９９９９、バージョンＶ１）に関連付ける（図６Ａのブロック７２６）。一実施形態では、ＶＴＳ１０４が回復ボリュームＶｏｌＲおよびターゲット・スクラッチ・ボリュームＶｏｌＰを関連付けることは、図５Ａにおいて「マッピング」とラベル付けされた矢印５０４によって表されているように、ターゲット・スクラッチ・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲにマッピングすることを含む。実施形態例の場合、このマッピングは、回復ボリュームＶｏｌＲ（この例では、Ｌ０００００、Ｖ２）に格納されたデータを指し示すようにターゲット・スクラッチ・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）のメタデータを変更することによって実現されてよい。例えば、ＶＴＳ１０４のテープ・ライブラリ・カタログ・エントリ（tape library catalog entry）の形態でのメタデータは、図８Ａの表によって表されたマッピング・カタログ・エントリ（mapping catalog entry）に示されているように、ターゲット・スクラッチ・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲにマッピングするように構成されてよく、図８ＡのＶＴＳマッピング・カタログ・エントリによって表された、ターゲット・スクラッチ・ボリュームＶｏｌＰに関連付けられたメタデータが、回復ボリュームＶｏｌＲを指し示すようにする。
図５Ｂに示された物理的回復などの物理的回復に関連してさらに詳細に説明されたように、図５Ａおよび図８Ａに示されているような回復ボリュームＶｏｌＲへのターゲット・スクラッチ・ボリュームＶｏｌＰのマッピングは、仮想回復が完了された後にホスト１００が回復ボリュームＶｏｌＲのデータにアクセスすることを必要とする場合に、回復ボリュームＶｏｌＲのデータを捜し出して読み取るために、その後の物理的回復において利用され得る。しかし、実施形態例の仮想回復自体は、回復ボリュームＶｏｌＲまたはターゲット・スクラッチ・ボリュームＶｏｌＰのどちらかがマウントされて読み取られることも書き込まれることも必要としない。代わりに、図５Ａの矢印５０４および図８ＡのＶＴＳカタログ・エントリによって表されたようなマッピング（図５Ａ）は、ボリュームのうちのどちらかをマウントすることを必要とせずに、ボリュームＶｏｌＲおよびＶｏｌＰに関連付けられたメタデータを構成することによって実現される。したがって、仮想回復は、物理テープ・ドライブまたはクラウドなどの、どのバックエンド・ストレージ・デバイスからも読み取ることなく実現され得る。また、仮想回復を完了するために、ボリュームに格納されたデータの内部のどのヘッダー情報も変更する必要がない。
一方、さまざまな既知の回復方法では、回復は、回復ボリュームが外部ストレージ・デバイスから読み取られ、読み取れたデータが、異なるＶＯＬＳＥＲを示すように変更され、ストレージ・デバイスに再び書き込まれることを必要とする。これに対して、前述したように、図５Ａ、図６Ａ、および図８Ａの仮想回復では、回復ボリュームＶｏｌＲ（この例では、Ｌ０００００ Ｖ２）に格納されたデータは、アクセスされないままとすることができ、したがって、仮想回復全体を通じてアンマウントされ、読み取られず書き込まれないままとすることができる。
ホスト１００が、矢印６２０によって表されているように、回復コマンドをＶＴＳ１０４に発行しており（図６Ａのブロック６１８）、回復されるために選択されたボリュームＶｏｌＲおよびターゲット・スクラッチ・ボリュームになるように選択されたボリュームＶｏｌＰを識別し、ホスト１００の回復マネージャ１２３ｈは、仮想回復プロセスのために、回復ボリュームＶｏｌＲ（この例では、ボリュームＬ０００００、ｖ２）をターゲット・スクラッチ・ボリュームＶｏｌＰ（この例では、ボリュームＳ９９９９９、バージョンＶ１）に関連付ける（図６Ａのブロック６２２）。一実施形態では、ホスト１００が回復ボリュームＶｏｌＲおよびターゲット・スクラッチ・ボリュームＶｏｌＰを関連付けることは、ターゲット・スクラッチ・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲにマッピングすることを含む。ホスト１００がターゲット・スクラッチ・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲにマッピングすることは、図５Ａにおいて「マッピング」とラベル付けされた矢印５０４によって表されたマッピングの構成要素でもある。
実施形態例では、ホスト１００によるマッピングは、ターゲット・スクラッチ・ボリュームＶｏｌＰが回復ボリュームＶｏｌＲ（この例では、Ｌ０００００、Ｖ２）であるかのように、ターゲット・スクラッチ・ボリュームＶｏｌＰを参照するように、ターゲット・スクラッチ・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）のメタデータを変更することによって実現されてよい。例えば、ホスト１００のマッピング・カタログ・エントリの形態でのメタデータは、図８Ａの表によって表されたホスト・カタログ・エントリ（host catalog entry）に示されているように、ターゲット・スクラッチ・ボリュームＶｏｌＰが、回復ボリュームＶｏｌＲに現在格納されているデータをすでに含んでいるかのように、ターゲット・スクラッチ・ボリュームＶｏｌＰを参照するように構成されてよい。一実施形態では、回復ボリュームＶｏｌＲ（この例では、ボリュームＬ０００００）のＶＯＬＳＥＲへの参照は、ターゲット・スクラッチ・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）のＶＯＬＳＥＲに置き換えられる。したがって、ホストが、例えば、回復ボリュームＶｏｌＲ内に現在格納されているデータ・セットを特定することを必要とする場合、図８Ｂに示されているように、回復ボリュームＶｏｌＲへの参照が、ターゲット・スクラッチ・ボリュームＶｏｌＰへの参照に置き換えられる。実施形態例では、マッピング・メタデータがカタログ・エントリとして説明されているが、そのようなマッピング・メタデータが、特定のアプリケーションに応じて、例えばアプリケーション内のデータ構造などの、他の形態であってよいということが理解される。
図５Ｂに示された物理的回復などの物理的回復に関連してさらに詳細に説明されたように、図５Ａ、図８Ａ、および図８Ｂに示されているような回復ボリュームＶｏｌＲへのターゲット・スクラッチ・ボリュームＶｏｌＰのマッピングは、仮想回復が完了された後に、ホスト１００が回復ボリュームＶｏｌＲのデータにアクセスすることを必要とする場合に、ホスト１００がターゲット・スクラッチ・ボリュームＶｏｌＰをマウントするように、その後の物理的回復において利用され得る。しかし、前述したように、実施形態例の仮想回復自体は、回復ボリュームＶｏｌＲまたはターゲット・スクラッチ・ボリュームＶｏｌＰのどちらかがマウントされることも、読み取られることも、書き込まれることも必要としない。代わりに、図５Ａの矢印５０４によって、ならびに図８ＡのＶＴＳマッピング・カタログ・エントリおよび図８Ｂのホスト・マッピング・カタログ・エントリによって表されたようなマッピング（図５Ａ）は、ボリュームのうちのどちらかをマウントすることを必要とせずに、ボリュームＶｏｌＲおよびＶｏｌＰに関連付けられたメタデータを構成するＶＴＳ１０４およびホスト１００によってそれぞれ実現される。したがって、仮想回復は、物理テープ・ドライブまたはクラウドなどの、どのバックエンド・ストレージ・デバイスからも読み取ることなく実現され得る。また、仮想回復を完了するために、ボリュームに格納されたデータの内部のどのヘッダー情報も変更する必要がない。
一方、さまざまな既知の回復方法では、回復は、回復ボリュームが外部ストレージ・デバイスから読み取られ、読み取られたデータが、異なるＶＯＬＳＥＲを示すように変更され、ストレージ・デバイスに再び書き込まれることを必要とする。これに対して、前述したように、図５Ａ、図６Ａ、図８Ａ、および図８Ｂの仮想回復では、回復ボリュームＶｏｌＲ（この例では、Ｌ０００００ Ｖ２）に格納されたデータは、アクセスされないままとすることができ、したがって、仮想回復全体を通じて読み取られず書き込まれない（変更不可能な）ままとすることができる。
前述したように、図５Ｂは、ホスト１００が、回復以外の目的で回復ボリュームＶｏｌＲのデータに実際にアクセスする必要がある場合の、本説明に従う物理的回復プロセスの一例を示している。図６Ｂは、図５Ａの物理的回復プロセスの動作のさらに詳細な例を示している。この実施形態では、ホスト１００が、前述したように、ターゲット・ボリュームＶｏｌＰに含まれているかのように、仮想回復プロセスによってターゲット・スクラッチ・ボリュームＶｏｌＰにマッピングされた（図８Ｂ）回復ボリュームＶｏｌＲのデータに実際にアクセスする必要があるということを決定した場合（図６Ｂのブロック６３０）、ホスト１００の回復マネージャ１２３ｈは、ホスト１００によって回復ＶｏｌＲにマッピングされたターゲット・スクラッチ・ボリュームＶｏｌＰをマウントするためのコマンドをＶＴＳ１０４に発行する（図６Ｂのブロック６３４）。この時点で、ターゲット・スクラッチ・ボリュームＶｏｌＰは、スクラッチ・ボリュームの代わりに、ターゲット・プライベート・ボリュームＶｏｌＰと呼ばれる。このようにして、ホスト１００は、前述したように、ターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）を回復ボリュームＶｏｌＲ（この例では、Ｌ０００００、Ｖ２）であるかのように扱う。ターゲット・プライベート・ボリュームＶｏｌＰをマウントするためのＶＴＳ１０４へのコマンドが、「コマンド」とラベル付けされた矢印６３６によって図６Ｂに表されており、ターゲット・プライベート・ボリュームＶｏｌＰを回復ボリュームＶｏｌＲに対して使用して図５Ｂの物理的回復プロセスを開始する。
ターゲット・プライベート・ボリュームＶｏｌＰをマウントするためのホスト１００のコマンド６３６に応答して、ＶＴＳ１０４の回復マネージャ１２３は、ターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）をマウントする（図６Ｂのブロック７３８）が、また、前述の仮想回復プロセスにおいてＶＴＳ１０４によってターゲット・スクラッチ・ボリュームＶｏｌＰがマッピングされた回復ボリュームＶｏｌＲ（この例では、Ｌ０００００、Ｖ２）もマウントする（図６Ｂのブロック７３８）。この例では、回復ボリュームＶｏｌＲを指し示すように、ターゲット・プライベート・ボリュームＶｏｌＰに関連付けられたメタデータを構成して、ＶＴＳ１０４によってターゲット・スクラッチ・ボリュームＶｏｌＰがマッピングされた。ＶＴＳ１０４は、図７Ｅに表されているように、ターゲット・プライベート・ボリュームＶｏｌＰの「マウント」状態を示すようにＶＴＳテープ・ライブラリ・カタログも更新する。
「データをコピーする」とラベル付けされた矢印５１４（図５Ｂ）によって表されているように、回復ボリュームＶｏｌＲ（この例では、Ｌ０００００、Ｖ２）へのターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）のマッピングを使用して、マウントされた回復ボリュームＶｏｌＲのデータが、回復マネージャ１２３によってアクセスされてターゲット・プライベート・ボリュームＶｏｌＰにコピーされる（ブロック７４２）。図９Ａは、マウントされた回復ボリュームＶｏｌＲから読み取られたデータの例を概略図の形態で示しており、データのソースを回復ボリュームＶｏｌＲとして識別するメタデータを含んでいるヘッダー部９０２を含む。ヘッダー部９０２は、特定のアプリケーションに応じて、回復ボリュームＶｏｌＲから読み取られたデータの他の特性を表す他のメタデータを含んでよい。
回復ボリュームＶｏｌＲ（この例では、Ｌ０００００、Ｖ２）から読み取られたデータの残りの部分は、図９Ａでは非ヘッダー・データ９０４と呼ばれ、回復ボリュームＶｏｌＲに格納されたユーザ・データを含み、特定のアプリケーションに応じて、他の種類のデータを含んでよい。非ヘッダー・データ９０４は、図９Ｂに示され、「データをコピーする」とラベル付けされた矢印５１４（図５Ｂ）によって表されているように、マウントされた回復ボリュームＶｏｌＲからアクセスされ、ターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）にコピーされる（図６Ｂのブロック７４２）。
図９Ｂに示され、図５Ｂに「ヘッダーを変更する」とラベル付けされた矢印５１８（図５Ｂ）によって表されているように、非ヘッダー・データ９０４がターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）にコピーされるときに、回復ボリュームＶｏｌＲから読み取られたヘッダー・データ９０２が、データ９０４と共にターゲット・プライベート・ボリュームＶｏｌＰに格納されている置換ヘッダー９０６（図９Ｂ）に置き換えられる（図６Ｂのブロック７４６）。このようにして、回復ボリュームＶｏｌＲから読み取られたデータは、ボリュームＶｏｌＰからのそのデータのその後の読み取りにおいて、データのソースをターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）として示すために、ターゲット・プライベート・ボリュームＶｏｌＰに格納されるときに再ラベル付けされる。これで、回復されたボリュームは、すべての使用においてボリューム・シリアル番号Ｓ９９９９９としてアクセスされ得るようになった。
さらに、回復ボリュームＶｏｌＲのデータにアクセスしてコピーすることは、データへのアクセスがホストによって要求されるまで延期される。さらに、データ・ソースの再ラベル付けも、要求に応じたプロセスであり、ターゲット・プライベート・ボリュームＶｏｌＰを対象にするコピー動作のためのヘッダーの変更も、ターゲット・プライベート・ボリュームＶｏｌＰのマウントを要求することによって、ホスト１００によって回復ボリュームＶｏｌＲのデータへのアクセスが要求されるまで、延期される。この実施形態では、前述したように、回復ボリュームＶｏｌＲは、仮想回復だけでなく物理的回復の間にも、変更不可能なままとすることができ、すなわち、変更されないままとすることができる（図６Ｂのブロック７４８）。したがって、回復ボリュームＶｏｌＲは、将来、外部ストレージ・デバイスのクラウドまたはテープからの読み取りが要求された場合に、ソースとしてまだ使用され得る。
回復ボリュームＶｏｌＲからターゲット・ボリュームＶｏｌＰへのデータのコピーおよび再ラベル付けの完了（図６Ｂのブロック７５２）時に、「報告」とラベル付けされた矢印７５６（図６Ｂ）によって表されているように、ＶＴＳ１０４の回復マネージャ１２３は、ターゲット・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９）への回復ボリュームＶｏｌＲの物理的回復が完了したことをホスト１００に報告する（図６Ｂのブロック７５４）。データのコピーおよび再ラベル付けの完了は、「マウント完了」と呼ばれることがある。加えて、ＶＴＳ１０４は、図７Ｆに表されているように、ターゲット・プライベート・ボリュームＶｏｌＰのアクティブな状態を示すようにＶＴＳテープ・ライブラリ・カタログを更新する。
それに応じて、この実施形態では、ホスト１００の回復マネージャ１２３ｈは、ターゲット・ボリュームＶｏｌＰのデータを検証し（図６Ｂのブロック６４４）、「コマンド」とラベル付けされた矢印６５０によって表されているように、回復ボリュームＶｏｌＲでのホールド状態を解放する（図６Ｂのブロック６４８）ためのコマンドをＶＴＳ１０４に発行する。それに応じて、ＶＴＳ１０４は、図７Ｇに示されているように、「ホールド」状態を解放し、「保持」状態を復元するように、ＶＴＳテープ・ライブラリ・カタログ内の回復ボリュームＶｏｌＲの状態を更新する。
実施形態例では、回復ボリュームＶｏｌＲ（この例では、Ｌ０００００ Ｖ２）からターゲット・プライベート・ボリュームＶｏｌＰ（この例では、Ｓ９９９９９、Ｖ１）へのデータの仮想回復が完了した後に、ホストは、回復ボリュームＶｏｌＲへのプライベート・ボリュームＶｏｌＰのマッピングを記録する必要がない。ホストが知る限り、データはＳ９９９９９に完全に回復される。この時点で、ホストがデータを読み取りたい場合、ホストは、単にターゲット・プライベート・ボリュームＶｏｌＰの標準的なライブラリのマウント（実施形態例では、「ＬＵＭ」と呼ばれる）を実行し、他のボリュームを読み取るのと同様に、回復データを読み取る。物理的回復がまだ発生していない場合、マッピング情報を維持するＶＴＳ１０４は、図５Ｂに関連して説明されたように、回復ボリュームＶｏｌＲからターゲット・プライベート・ボリュームＶｏｌＰへの物理的回復のために、データをコピーし、ヘッダーを変更することを開始する。
本説明に従うデータ・ストレージ回復管理の別の態様では、異なるか、または競合するボリューム・シリアル付番方式または規則を有することがある別のソースから素早く効率的にボリュームをインポートするために、図５Ａおよび図６Ａの仮想回復プロセスが使用されてよい。一実施形態では、ボリュームＶｏｌＲ（図５Ａ）などのインポートされるボリュームの各々は、新しいターゲット・プライベート・ボリュームＶｏｌＰに（図６Ａの矢印５０４によって表されているように）マッピングまたは再マッピングされてよく、例えば、そのような各ボリュームＶｏｌＰは、ターゲット・データ・ストレージ・システムのホスト１００またはストレージ・サーバ１０４の既存のボリューム・シリアル番号規則に従うＶＯＬＳＥＲを有する。したがって、インポートされるボリュームＶｏｌＲ（図５Ａ）の各々は、例えばホストまたはストレージ・サーバの既存のアクティブなＶＯＬＳＥＲに一致しないか、または他の方法で既存のＶＯＬＳＥＲと競合する、ターゲット・データ・ストレージ・システムの新しいＶＯＬＳＥＲにマッピングまたは再マッピングされてよい。加えて、インポートされるボリュームＶｏｌＲは、既存のボリューム・シリアル番号範囲規則に従い、それによって、既存のボリューム・シリアル番号範囲規則を維持する、ターゲット・プライベート・ボリュームＶｏｌＰのＶＯＬＳＥＲにマッピングまたは再マッピングされてよい。
例えばターゲットＶＴＳにインポートされるボリュームが、特定のアプリケーションに応じて、数百個、数千個、数百万個以上に達することがあるということが理解される。実施形態例の仮想回復プロセスは、仮想回復プロセスを使用してインポートされているどのボリュームもマウントせず、別途ボリュームにアクセスすることもなく、多数のボリュームが迅速にターゲットＶＴＳにインポートされることを可能にする。その結果、各インポートされたボリュームは変更不可能なままとすることができ、かつその後の物理的回復の未来の再呼び出し要求の一部としてオンデマンドで再ラベル付けされるのみであることが分かっているので、インポートされているボリュームは、そのボリュームの内容の有効性を維持するように堅牢にされ得る。例えば、法的な理由のため、インポート時のデータの状態が、ワークロード取得の一貫性のある位置を維持するために、変更不可能なままであることを必要とすることがある。実施形態例の仮想回復プロセスは、ボリューム・シリアル番号（ＶＯＬＳＥＲ）の競合がなく、各インスタンスにアクセスする必要がなく、ソース・インスタンスを変更する必要がない、ボリュームのインポートを可能にする。インポートされたボリュームのデータにアクセスする必要性が生じた場合、図５Ｂおよび図６Ｂに関連して上記に説明されたように、インポートされたボリュームの要求に応じた物理的回復が実行されてよい。
さらに別の態様では、回復ボリュームは、変更不可能なままとすることができ、したがって、実施形態例の回復プロセスによって変更されないままとすることができるため、本説明に従うストレージ・ボリューム回復は、必要とされる回数にわたってボリュームを回復するために、再帰的に適用されてよい。したがって、前述したように、回復ボリュームＶｏｌＲがターゲット・プライベート・ボリュームＶｏｌＰに復元された後に、ＶｏｌＰが削除され、その後、ホストがボリュームＶｏｌＰまたは回復ボリュームＶｏｌＲの回復を再び要求した場合、回復ボリュームＶｏｌＲを、例えばターゲット・ボリュームＶｏｌＰ１などの新しいターゲット・スクラッチ・ボリュームに回復する、前述の仮想回復プロセスが繰り返されてよい。この例では、回復ボリュームＶｏｌＲが変更不可能であり、したがって、第２の仮想回復時に回復データをまだ含んでいるため、新しいターゲット・ボリュームＶｏｌＰ１は、仮想回復において、削除されたボリュームＶｏｌＰの代わりに、回復ボリュームＶｏｌＲに直接マッピングされてよい。第１のターゲット・ボリュームＶｏｌＰに関連して上記に説明されたように、必要に応じて、その後、回復ボリュームＶｏｌＲから新しいターゲット・ボリュームＶｏｌＰ１にデータを転送して再ラベル付けする物理的回復が実行されてよい。
次に、ターゲット・ボリュームＶｏｌＰ１が削除され、その後、ホストがボリュームＶｏｌＰ１または回復ボリュームＶｏｌＲの回復を再び要求した場合、回復ボリュームＶｏｌＲを、例えばターゲット・ボリュームＶｏｌＰ２などの、さらに別の新しいターゲット・スクラッチ・ボリュームに回復する、ターゲット・ボリュームＶｏｌＰおよびＶｏｌＰ１に関連して上で説明された仮想回復プロセスが再度繰り返されてよい。したがって、この例では、回復ボリュームＶｏｌＲが変更不可能であり、したがって、第３の仮想回復時に回復データをまだ含んでいるため、新しいターゲット・ボリュームＶｏｌＰ２は、仮想回復において、削除されたボリュームＶｏｌＰの代わりに、回復ボリュームＶｏｌＲに直接マッピングされてよい。前のターゲット・ボリュームＶｏｌＰおよびＶｏｌＰ１に関連して上で説明されたように、必要に応じて、回復ボリュームＶｏｌＲから最新のターゲット・ボリュームＶｏｌＰ２にデータを転送して再ラベル付けする物理的回復が実行されてよい。したがって、本説明に従うボリューム回復管理は、無期限にボリュームが回復されること、および無期限に変更不可能なままであることを可能にする。
本発明は、システム、方法、もしくはコンピュータ・プログラム製品、またはそれらの組合せであってよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を含んでいるコンピュータ可読ストレージ媒体を含んでよい。
コンピュータ可読ストレージ媒体は、命令実行デバイスによって使用するための命令を保持および格納できる有形のデバイスとすることができる。コンピュータ可読ストレージ媒体は、例えば、電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁ストレージ・デバイス、半導体ストレージ・デバイス、またはこれらの任意の適切な組合せであってよいが、これらに限定されない。コンピュータ可読ストレージ媒体のさらに具体的な例の非網羅的リストは、ポータブル・フロッピー・ディスク、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ：read-only memory）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭ：erasable programmable read-only memoryまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：static random access memory）、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ－ＲＯＭ：compact disc read-only memory）、デジタル・バーサタイル・ディスク（ＤＶＤ：digital versatile disk）、メモリ・スティック、フロッピー・ディスク、命令が記録されているパンチカードまたは溝の中の隆起構造などの機械的にエンコードされるデバイス、およびこれらの任意の適切な組合せを含む。本明細書において使用されるとき、コンピュータ可読ストレージ媒体は、それ自体が、電波または他の自由に伝搬する電磁波、導波管もしくは他の送信媒体を伝搬する電磁波（例えば、光ファイバ・ケーブルを通過する光パルス）、またはワイヤを介して送信される電気信号などの一過性の信号であると解釈されるべきではない。
本明細書に記載されたコンピュータ可読プログラム命令は、コンピュータ可読ストレージ媒体から各コンピューティング・デバイス／処理デバイスへ、またはネットワーク（例えば、インターネット、ローカル・エリア・ネットワーク、広域ネットワーク、もしくはワイヤレス・ネットワーク、またはそれらの組合せ）を介して外部コンピュータまたは外部ストレージ・デバイスへダウンロードされ得る。このネットワークは、銅伝送ケーブル、光伝送ファイバ、無線送信、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはそれらの組合せを備えてよい。各コンピューティング・デバイス／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェイスは、コンピュータ可読プログラム命令をネットワークから受信し、それらのコンピュータ可読プログラム命令を各コンピューティング・デバイス／処理デバイス内のコンピュータ可読ストレージ媒体に格納するために転送する。
本発明の動作を実行するためのコンピュータ可読プログラム命令は、アセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：instruction-set-architecture）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、またはＪａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などのオブジェクト指向プログラミング言語、および「Ｃ」プログラミング言語または同様のプログラミング言語などの従来の手続き型プログラミング言語を含む１つもしくは複数のプログラミング言語の任意の組合せで記述されたソース・コードまたはオブジェクト・コードであってよい。コンピュータ可読プログラム命令は、ユーザのコンピュータ上で全体的に実行すること、ユーザのコンピュータ上でスタンドアロン・ソフトウェア・パッケージとして部分的に実行すること、ユーザのコンピュータ上およびリモート・コンピュータ上でそれぞれ部分的に実行すること、またはリモート・コンピュータ上またはサーバ上で全体的に実行することができる。後者のシナリオでは、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてよく、または接続は、（例えば、インターネット・サービス・プロバイダを使用してインターネットを介して）外部コンピュータに対して行われてよい。一部の実施形態では、本発明の態様を実行するために、例えばプログラマブル・ロジック回路、フィールドプログラマブル・ゲート・アレイ（ＦＰＧＡ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：programmable logic arrays）を含む電子回路は、コンピュータ可読プログラム命令の状態情報を利用することによって、電子回路をカスタマイズするためのコンピュータ可読プログラム命令を実行してよい。
本発明の態様は、本明細書において、本発明の実施形態に従って、方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して説明される。フローチャート図もしくはブロック図またはその両方の各ブロック、ならびにフローチャート図もしくはブロック図またはその両方に含まれるブロックの組合せが、コンピュータ可読プログラム命令によって実装され得るということが理解されるであろう。
これらのコンピュータ可読プログラム命令は、コンピュータまたは他のプログラム可能なデータ処理装置のプロセッサを介して実行される命令が、フローチャートもしくはブロック図またはその両方の１つまたは複数のブロックに指定される機能／動作を実施する手段を作り出すべく、汎用コンピュータ、専用コンピュータ、または他のプログラム可能なデータ処理装置のプロセッサに提供されてマシンを作り出すものであってよい。これらのコンピュータ可読プログラム命令は、命令が格納されたコンピュータ可読ストレージ媒体がフローチャートもしくはブロック図またはその両方の１つまたは複数のブロックに指定される機能／動作の態様を実施する命令を含んでいる製品を備えるように、コンピュータ可読ストレージ媒体に格納され、コンピュータ、プログラム可能なデータ処理装置、もしくは他のデバイス、またはそれらの組合せに特定の方式で機能するように指示できるものであってもよい。
コンピュータ可読プログラム命令は、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で実行される命令が、フローチャートもしくはブロック図またはその両方のブロックに指定される機能／動作を実施するように、コンピュータ実装プロセスを生成すべく、コンピュータ、その他のプログラム可能なデータ処理装置、またはその他のデバイスに読み込まれ、コンピュータ上、その他のプログラム可能な装置上、またはその他のデバイス上で一連の動作可能なステップを実行させるものであってもよい。
図内のフローチャートおよびブロック図は、本発明のさまざまな実施形態に従って、システム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示す。これに関連して、フローチャートまたはブロック図内の各ブロックは、規定された論理機能を実装するための１つまたは複数の実行可能な命令を備える、命令のモジュール、セグメント、または部分を表してよい。一部の代替の実装では、ブロックに示された機能は、図に示された順序とは異なる順序で発生してよい。例えば、連続して示された２つのブロックは、実際には、含まれている機能に応じて、実質的に同時に実行されるか、または場合によっては逆の順序で実行されてよい。ブロック図もしくはフローチャート図またはその両方の各ブロック、ならびにブロック図もしくはフローチャート図またはその両方に含まれるブロックの組合せは、規定された機能または動作を実行するか、または専用ハードウェアとコンピュータ命令の組合せを実行する専用ハードウェアベースのシステムによって実装され得るということにも注意する。
各図の計算コンポーネントは、図１０に示されたコンピュータ・システム１００２などの１つまたは複数のコンピュータ・システムにおいて実装されてよい。コンピュータ・システム／サーバ１００２は、コンピュータ・システムによって実行されているプログラム・モジュールなどの、コンピュータ・システムによって実行可能な命令との一般的な関連において説明されてよい。通常、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、論理、データ構造などを含んでよい。コンピュータ・システム／サーバ１００２は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散クラウド・コンピューティング環境で実行されてよい。分散クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含む、ローカルおよびリモートの両方のコンピュータ・システム・ストレージ媒体に配置されてよい。
図１０に示されているように、コンピュータ・システム／サーバ１００２は、汎用コンピューティング・デバイスの形態で示されている。コンピュータ・システム／サーバ１００２のコンポーネントは、１つまたは複数のプロセッサまたはプロセッシング・ユニット１００４、システム・メモリ１００６、およびシステム・メモリ１００６を含むさまざまなシステム・コンポーネントをプロセッサ１００４に結合するバス１００８を含んでよいが、これらに限定されない。バス１００８は、メモリ・バスまたはメモリ・コントローラ、ペリフェラル・バス、アクセラレーテッド・グラフィックス・ポート、およびさまざまなバス・アーキテクチャのいずれかを使用するプロセッサまたはローカル・バスを含む、複数の種類のバス構造のいずれかのうちの１つまたは複数を表す。そのようなアーキテクチャの例としては、ＩＳＡ（Industry Standard Architecture）バス、ＭＣＡ（Micro Channel Architecture）バス、ＥＩＳＡ（Enhanced ISA）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカル・バス、およびＰＣＩ（Peripheral Component Interconnects）バスが挙げられるが、これらに限定されない。
コンピュータ・システム／サーバ１００２は、通常、さまざまなコンピュータ・システム可読媒体を含む。そのような媒体は、コンピュータ・システム／サーバ１００２によってアクセスできる任意の使用可能な媒体であってよく、揮発性および不揮発性媒体、取り外し可能および取り外し不可の媒体を含む。
システム・メモリ１００６は、ランダム・アクセス・メモリ（ＲＡＭ）１０１０もしくはキャッシュ・メモリ１０１２またはその両方などの、揮発性メモリの形態でのコンピュータ・システム可読媒体を含むことができる。コンピュータ・システム／サーバ１００２は、他の取り外し可能／取り外し不可、揮発性／不揮発性のコンピュータ・システム・ストレージ媒体をさらに含んでよい。単に例として、取り外し不可、不揮発性の磁気媒体（図示されておらず、通常は「ハード・ドライブ」と呼ばれる）に対する読み取りと書き込みを行うために、ストレージ・システム１０１３を提供することができる。図示されていないが、取り外し可能、不揮発性の磁気ディスク（例えば、「フロッピー・ディスク」）に対する読み取りと書き込みを行うための磁気ディスク・ドライブ、およびＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、またはその他の光媒体などの取り外し可能、不揮発性の光ディスクに対する読み取りと書き込みを行うための光ディスク・ドライブを提供することができる。そのような例では、それぞれを、１つまたは複数のデータ媒体インターフェイスによってバス１００８に接続することができる。下記に詳細に示され、説明されているように、メモリ１００６は、本発明の実施形態の機能を実行するように構成された一連の（例えば、少なくとも１つの）プログラム・モジュールを備える少なくとも１つのプログラム製品を含んでよい。
例えば、一連の（少なくとも１つの）プログラム・モジュール１０１６を含んでいるプログラム／ユーティリティ１０１４がメモリ１００６に格納されてよいが、これに限定されず、オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、他のプログラム・モジュール、およびプログラム・データも格納されてよい。オペレーティング・システム、１つまたは複数のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データまたはこれらの組合せの各々は、ネットワーク環境の実装を含んでよい。コンピュータ１００２のコンポーネントは、通常、本明細書に記載された本発明の実施形態の機能もしくは方法またはその両方を実行するプログラム・モジュール１０１６として実装されてよい。図１Ａのシステムは、１つまたは複数のコンピュータ・システム１００２において実装されてよく、システムが複数のコンピュータ・システム１００２において実装された場合、コンピュータ・システムはネットワークを経由して通信してよい。
コンピュータ・システム／サーバ１００２は、キーボード、ポインティング・デバイス、ディスプレイ１０２０などの１つもしくは複数の外部デバイス１０１８、ユーザがコンピュータ・システム／サーバ１００２と情報をやりとりできるようにする１つもしくは複数のデバイス、またはコンピュータ・システム／サーバ１００２が１つもしくは複数の他のコンピューティング・デバイスと通信できるようにする任意のデバイス（例えば、ネットワーク・カード、モデムなど）、またはそれらの組合せと通信してもよい。そのような通信は、入出力（Ｉ／Ｏ：Input/Output）インターフェイス１０２２を介して発生することができる。さらに、コンピュータ・システム／サーバ１００２は、ローカル・エリア・ネットワーク（ＬＡＮ）、一般的な広域ネットワーク（ＷＡＮ）、もしくはパブリック・ネットワーク（例えば、インターネット）、またはそれらの組合せなどの１つまたは複数のネットワークと、ネットワーク・アダプタ１０２４を介して通信することができる。図示されているように、ネットワーク・アダプタ１０２４は、バス１００８を介してコンピュータ・システム／サーバ１００２の他のコンポーネントと通信する。図示されていないが、他のハードウェア・コンポーネントもしくはソフトウェア・コンポーネントまたはその両方を、コンピュータ・システム／サーバ１００２と併用できるということが理解されるべきである。その例として、マイクロコード、デバイス・ドライバ、冗長プロセッシング・ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイブ・ストレージ・システムなどが挙げられるが、これらに限定されない。
用語「実施形態（an embodiment）」、「実施形態（embodiment）」、「実施形態（embodiments）」、「実施形態（the embodiment）」、「実施形態（the embodiments）」、「１つまたは複数の実施形態」、「一部の実施形態」、および「一実施形態」は、特に明示的に指定されない限り、「本発明の１つまたは複数の（ただし、すべてではない）実施形態」を意味する。
用語「含む」、「備える」、「有する」、およびこれらの変形は、特に明示的に指定されない限り、「含むが、これに限定されない」ということを意味する。
項目の列挙されたリストは、特に明示的に指定されない限り、項目のいずれかまたはすべてが相互に排他的であることを意味しない。
用語「ａ」、「ａｎ」、および「ｔｈｅ」は、特に明示的に指定されない限り、「１つまたは複数」を意味する。
互いに通信するデバイスは、特に明示的に指定されない限り、継続的に互いに通信する必要はない。加えて、互いに通信するデバイスは、直接的に、または１つまたは複数の仲介を介して間接的に通信してよい。
互いに通信する複数のコンポーネントを含む実施形態の説明は、そのようなすべてのコンポーネントが必要とされるということを意味しない。反対に、本発明の多種多様な可能性のある実施形態を例示するために、さまざまな任意選択的コンポーネントが説明される。
本明細書において単一のデバイスまたは品目が説明される場合、単一のデバイス／品目の代わりに２つ以上のデバイス／品目が（協力しているかどうかに関わりなく）使用されてよいということが容易に明らかであろう。同様に、本明細書において２つ以上のデバイスまたは品目が（協力しているかどうかに関わりなく）説明される場合、２つ以上のデバイスまたは品目の代わりに単一のデバイス／品目が使用されてよく、または示された数のデバイスまたはプログラムの代わりに、異なる数のデバイス／品目が使用されてよいということが容易に明らかであろう。デバイスの機能もしくは特徴またはその両方が、代替として、そのような機能／特徴を有していると明示的に説明されない１つまたは複数の他のデバイスによって具現化されてよい。したがって、本発明の他の実施形態は、デバイス自体を含む必要がない。
本発明のさまざまな実施形態に関する前述の説明は、例示および説明の目的で提供されている。これらの説明が本発明を網羅すること、または開示された厳密な形態に制限することは意図されていない。上記の内容を踏まえて、多くの変更および変形が可能である。本発明の範囲が、この「発明を実施するための形態」によってではなく、本明細書に添付された「特許請求の範囲」によって制限されるということが意図される。上記の仕様、実施例、およびデータは、本発明の構成の製造および使用の完全な説明を提供する。本発明の思想および範囲から逸脱することなく本発明の多くの実施形態が作られ得るため、本発明は、本明細書において後で添付される特許請求の範囲に存在する。

Claims (25)

  1. ストレージに格納されたデータのボリュームを復元するためのコンピュータ・プログラム製品であって、前記コンピュータ・プログラム製品が、動作を引き起こすためにプロセッサによって実行可能なプログラム命令を有するコンピュータ可読ストレージ媒体を備え、前記動作は、
    第２のボリュームを第１のボリュームの仮想復元として前記第１のボリュームにマッピングするように、前記第２のボリュームに関連付けられたメタデータを構成することを含む、前記第２のボリュームを使用して前記ストレージに格納されたデータの前記第１のボリュームの第１の仮想復元を実行することと、
    前記第１のボリュームに格納されたデータに対するホストによる要求に応答して、前記仮想復元によって前記第２のボリュームがマッピングされた前記第１のボリュームから、前記第２のボリュームにデータを転送し、転送されたデータを、第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることを含む、前記第２のボリュームを使用して前記第１のボリュームのデータの物理的復元を実行することであって、結果として、前記第１のボリュームのデータにアクセスすることは、前記データに対するアクセスが前記ホストによって要求されるまで延期され、前記第１のボリュームの仮想復元および物理的復元の間に、前記第１のボリュームの復元に関連する前記第１のボリューム上のデータの変更が回避されること
    とを含むコンピュータ・プログラム製品。
  2. データを前記第１のボリュームから前記第２のボリュームに前記転送することは、前記第２のボリュームをストレージ・ドライブにマウントするための前記ホストによる要求を受信することに応答し、ならびに前記要求に応答して、
    前記第２のボリュームをストレージ・ドライブにマウントすることと、
    前記第１のボリュームをストレージ・ドライブにマウントすることと、
    前記第２のボリュームの前記メタデータによって前記第２のボリュームにマッピングされた前記第１のボリュームのデータをコピーすることであって、結果として、前記第２のボリュームを使用する前記第１のボリュームの復元に関連する前記第１のボリュームからのデータのコピーが、前記第２のボリュームの前記物理的復元まで延期されることと
    を含む、請求項１に記載のコンピュータ・プログラム製品。
  3. 転送されたデータを第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることは、前記第１のボリュームからコピーされたデータを前記第１のボリュームの代わりに前記第２のボリュームのデータであるとして識別するために、データが前記第２のボリュームに格納されるときに、前記第１のボリュームから読み取られたヘッダー・データを変更することであって、結果として、前記第１のボリュームから読み取られたヘッダー・データを変更することが、前記データに対するアクセスが前記ホストによって要求されるまで延期されることを含む、請求項２に記載のコンピュータ・プログラム製品。
  4. 前記第１のボリュームは、第１のボリューム・シリアル番号を有し、前記第２のボリュームは、前記第１のボリューム・シリアル番号と異なる第２のシリアル番号を有し、ユーザ・データが前記第１のボリュームから読み取られ、読み取られたデータが前記第２のボリュームにコピーされた際に、前記第１のボリュームの前記物理的復元の間に前記第２のボリュームに格納するためにヘッダー・データを変更することは、ヘッダー・データ内の前記第１のボリュームの前記第１のシリアル番号を、ヘッダー・データとして、前記第２のボリュームの前記第２のボリューム・シリアル番号に置き換えることを含む、請求項３に記載のコンピュータ・プログラム製品。
  5. 前記動作は、前記第１のボリュームの前記仮想復元および物理的復元の両方の間に、前記第１のボリュームの前記復元による前記第１のボリュームの変更を防ぐために、前記第１のボリュームをマウントする前に、前記第１のボリュームを読み取り専用ボリュームとして分類することをさらに含む、請求項２に記載のコンピュータ・プログラム製品。
  6. 前記第１のボリュームの前記仮想復元の開始前に、前記第１のボリュームは保持カテゴリに分類され、前記保持カテゴリでは、削除を指定された後のある期間の間、ボリュームは保持され、ストレージに格納されたデータの前記第１のボリュームの前記仮想復元は、前記第１のボリュームをホールド・カテゴリに再分類することであって、前記ホールド・カテゴリではボリュームの変更が防がれる、前記再分類することと、前記第１のボリュームの前記物理的復元中の、前記第１のボリュームから前記第２のボリュームへのデータの前記転送の完了にさらに応答して、前記第１のボリュームを前記ホールド・カテゴリから前記保持カテゴリへ再分類することと、をさらに含み、前記第１のボリュームの前記復元による前記第１のボリュームの変更は、前記第１のボリュームの前記仮想復元および前記物理的復元の両方の間では回避される、請求項１に記載のコンピュータ・プログラム製品。
  7. 前記動作は、少なくとも１つのポリシーを前記第２のボリュームに割り当てることをさらに含み、前記ポリシーが、ボリュームを維持する期間および前記ボリュームのバージョンの許可された数のうちの少なくとも１つに関するパラメータを定義する、請求項１に記載のコンピュータ・プログラム製品。
  8. 前記動作は、前記ストレージのボリューム・シリアル付番規則に従うボリューム・シリアル番号を有する第４のボリュームを使用して第３のボリュームの仮想復元を実行することを含む、前記第３のボリュームを前記ストレージにインポートすることをさらに含み、前記第３のボリュームの前記仮想復元は、前記第４のボリュームを前記第３のボリュームの仮想復元として前記第３のボリュームにマッピングするように、前記第４のボリュームに関連付けられたメタデータを構成することを含む、請求項１に記載のコンピュータ・プログラム製品。
  9. 前記動作は、
    前記第２のボリュームを削除することと、
    第３のボリュームを前記第１のボリュームの第２の仮想復元として前記第１のボリュームにマッピングするように、前記第３のボリュームに関連付けられたメタデータを構成することを含む、前記第３のボリュームを使用して前記第１のボリュームの第２の仮想復元を実行することとをさらに含み、前記第１のボリュームは、前記第１のボリュームの前記第１および第２の仮想復元にわたって変更不可能なままである、請求項１に記載のコンピュータ・プログラム製品。
  10. 前記第１のボリュームは、一次ストレージを有するストレージ・サーバに結合された二次ストレージに格納され、前記第１のボリュームは、前記第１のボリュームの前記仮想復元全体を通じて、前記二次ストレージにおいてアンマウントされたままである、請求項１に記載のコンピュータ・プログラム製品。
  11. ホストと共に使用するため、およびデータのボリュームを復元するためのシステムであって、前記システムが、
    データの複数のボリュームを有するストレージと、
    プロセッサと、
    前記プロセッサによって実行された場合に動作を引き起こすプログラム命令を有するコンピュータ可読ストレージ媒体とを備え、前記動作は、
    第２のボリュームを第１のボリュームの仮想復元として前記第１のボリュームにマッピングするように、前記第２のボリュームに関連付けられたメタデータを構成することを含む、前記第２のボリュームを使用して前記ストレージに格納されたデータの前記第１のボリュームの第１の仮想復元を実行することと、
    前記第１のボリュームに格納されたデータに対するホストによる要求に応答して、前記仮想復元によって前記第２のボリュームがマッピングされた前記第１のボリュームから、前記第２のボリュームにデータを転送し、転送されたデータを、第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることを含む、前記第２のボリュームを使用して前記第１のボリュームのデータの物理的復元を実行することであって、結果として、前記第１のボリュームのデータにアクセスすることが、前記データに対するアクセスが前記ホストによって要求されるまで延期され、前記第１のボリュームの仮想復元および物理的復元の間に、前記第１のボリュームの復元に関連する前記第１のボリューム上のデータの変更が回避されること
    とを含む、システム。
  12. 前記ストレージは、ストレージ・ドライブを含み、データを前記第１のボリュームから前記第２のボリュームに転送することは、前記第２のボリュームをストレージ・ドライブにマウントするための前記ホストによる要求を受信することに応答し、ならびに前記要求に応答して、
    前記第２のボリュームをストレージ・ドライブにマウントすることと、
    前記第１のボリュームをストレージ・ドライブにマウントすることと、
    前記第２のボリュームの前記メタデータによって前記第２のボリュームにマッピングされた前記第１のボリュームのデータをコピーすることであって、結果として、前記第２のボリュームを使用する前記第１のボリュームの復元に関連する前記第１のボリュームからのデータのコピーが、前記第２のボリュームの前記物理的復元まで延期されることと
    を含む、請求項１１に記載のシステム。
  13. 転送されたデータを第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることは、前記第１のボリュームからコピーされたデータを前記第１のボリュームの代わりに前記第２のボリュームのデータであるとして識別するために、データが前記第２のボリュームに格納されるときに、前記第１のボリュームから読み取られたヘッダー・データを変更することであって、結果として、前記第１のボリュームから読み取られたヘッダー・データを変更することが、前記データに対するアクセスが前記ホストによって要求されるまで延期されることを含む、請求項１２に記載のシステム。
  14. 前記第１のボリュームは、第１のボリューム・シリアル番号を有し、前記第２のボリュームは、前記第１のボリューム・シリアル番号と異なる第２のシリアル番号を有し、ユーザ・データが前記第１のボリュームから読み取られ、読み取られたデータが前記第２のボリュームにコピーされた際に、前記第１のボリュームの前記物理的復元の間に前記第２のボリュームに格納するためにヘッダー・データを変更することは、ヘッダー・データ内の前記第１のボリュームの前記第１のシリアル番号を、ヘッダー・データとして、前記第２のボリュームの前記第２のボリューム・シリアル番号に置き換えることを含む、請求項１３に記載のシステム。
  15. 前記動作は、前記第１のボリュームの前記仮想復元および物理的復元の両方の間に、前記第１のボリュームの前記復元による前記第１のボリュームの変更を防ぐために、前記第１のボリュームをマウントする前に、前記第１のボリュームを読み取り専用ボリュームとして分類することをさらに含む、請求項１２に記載のシステム。
  16. 前記第１のボリュームの前記仮想復元の開始前に、前記第１のボリュームは保持カテゴリに分類され、前記保持カテゴリでは、削除を指定された後のある期間の間、ボリュームは保持され、ストレージに格納されたデータの前記第１のボリュームの前記仮想復元は、前記第１のボリュームをホールド・カテゴリに再分類することであって、前記ホールド・カテゴリではボリュームの変更が防がれる、前記再分類することと、前記第１のボリュームの前記物理的復元中の、前記第１のボリュームから前記第２のボリュームへのデータの前記転送の完了にさらに応答して、前記第１のボリュームを前記ホールド・カテゴリから前記保持カテゴリへ再分類することと、をさらに含み、前記第１のボリュームの前記復元による前記第１のボリュームの変更は、前記第１のボリュームの前記仮想復元および前記物理的復元の両方の間では回避される、請求項１１に記載のシステム。
  17. 前記動作は、少なくとも１つのポリシーを前記第２のボリュームに割り当てることをさらに含み、前記ポリシーが、ボリュームを維持する期間および前記ボリュームのバージョンの許可された数のうちの少なくとも１つに関するパラメータを定義する、請求項１１に記載のシステム。
  18. 前記動作は、前記ストレージのボリューム・シリアル付番規則に従うボリューム・シリアル番号を有する第４のボリュームを使用して第３のボリュームの仮想復元を実行することを含む、前記第３のボリュームを前記ストレージにインポートすることをさらに含み、前記第３のボリュームの前記仮想復元は、前記第４のボリュームを前記第３のボリュームの仮想復元として前記第３のボリュームにマッピングするように、前記第４のボリュームに関連付けられたメタデータを構成することを含む、請求項１１に記載のシステム。
  19. 前記動作は、
    前記第２のボリュームを削除することと、
    第３のボリュームを前記第１のボリュームの第２の仮想復元として前記第１のボリュームにマッピングするように、前記第３のボリュームに関連付けられたメタデータを構成することを含む、前記第３のボリュームを使用して前記第１のボリュームの第２の仮想復元を実行することとをさらに含み、前記第１のボリュームは、前記第１のボリュームの前記第１および第２の仮想復元にわたって変更不可能なままである、請求項１１に記載のシステム。
  20. 前記ストレージが、一次ストレージおよび二次ストレージを有するストレージ・サーバを含み、前記第１のボリュームは、前記二次ストレージに格納され、前記第１のボリュームは、前記第１のボリュームの前記仮想復元全体を通じて、前記二次ストレージにおいてアンマウントされたままである、請求項１１に記載のシステム。
  21. 第２のボリュームを第１のボリュームの仮想復元として前記第１のボリュームにマッピングするように、前記第２のボリュームに関連付けられたメタデータを構成することを含む、前記第２のボリュームを使用してストレージに格納されたデータの前記第１のボリュームの第１の仮想復元を実行することと、
    前記第１のボリュームに格納されたデータに対するホストによる要求に応答して、前記仮想復元によって前記第２のボリュームがマッピングされた前記第１のボリュームから、前記第２のボリュームにデータを転送し、転送されたデータを、第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることを含む、前記第２のボリュームを使用して前記第１のボリュームのデータの物理的復元を実行することであって、結果として、前記第１のボリュームのデータにアクセスすることは、前記データに対するアクセスが前記ホストによって要求されるまで延期され、前記第１のボリュームの仮想復元および物理的復元の間に、前記第１のボリュームの復元に関連する前記第１のボリューム上のデータの変更が回避されること
    とを含む方法。
  22. データを前記第１のボリュームから前記第２のボリュームに前記転送することが、前記第２のボリュームをストレージ・ドライブにマウントするための前記ホストによる要求を受信することに応答し、前記要求に応答して、
    前記第２のボリュームをストレージ・ドライブにマウントすることと、
    前記第１のボリュームをストレージ・ドライブにマウントすることと、
    前記第２のボリュームの前記メタデータによって前記第２のボリュームにマッピングされた前記第１のボリュームのデータをコピーすることであって、結果として、前記第２のボリュームを使用する前記第１のボリュームの復元に関連する前記第１のボリュームからのデータのコピーが、前記第２のボリュームの前記物理的復元まで延期されることとを含み、前記第１のボリュームは、一次ストレージを有するストレージ・サーバに結合された二次ストレージに格納され、前記第１のボリュームは、前記第１のボリュームの前記仮想復元全体を通じて、前記二次ストレージにおいてアンマウントされたままであり、転送されたデータを第１のボリューム・データの代わりに第２のボリューム・データとして再ラベル付けすることは、前記第１のボリュームからコピーされたデータを前記第１のボリュームの代わりに前記第２のボリュームのデータであるとして識別するために、データが前記第２のボリュームに格納されるときに、前記第１のボリュームから読み取られたヘッダー・データを変更することであって、結果として、前記第１のボリュームから読み取られたヘッダー・データを変更することが、前記データに対するアクセスが前記ホストによって要求されるまで延期されることを含み、
    前記第１のボリュームは、第１のボリューム・シリアル番号を有し、前記第２のボリュームは、前記第１のボリューム・シリアル番号と異なる第２のシリアル番号を有し、ユーザ・データが前記第１のボリュームから読み取られ、読み取られたデータが前記第２のボリュームにコピーされた際に、前記第１のボリュームの前記物理的復元の間に前記第２のボリュームに格納するためにヘッダー・データを変更することは、ヘッダー・データ内の前記第１のボリュームの前記第１のシリアル番号を、ヘッダー・データとして、前記第２のボリュームの前記第２のボリューム・シリアル番号に置き換えることを含む、請求項２１に記載の方法。
  23. 前記第１のボリュームの前記仮想復元および物理的復元の両方の間に、前記第１のボリュームの前記復元による前記第１のボリュームの変更を防ぐために、前記第１のボリュームをマウントする前に、前記第１のボリュームを読み取り専用ボリュームとして分類することをさらに含み、
    前記第１のボリュームの前記仮想復元の開始前に、前記第１のボリュームは保持カテゴリに分類され、前記保持カテゴリでは、削除を指定された後のある期間の間、ボリュームは保持され、ストレージに格納されたデータの前記第１のボリュームの前記仮想復元は、前記第１のボリュームをホールド・カテゴリに再分類することであって、前記ホールド・カテゴリでは、ボリュームの変更が防がれる、前記再分類することと、前記第１のボリュームの前記物理的復元中の、前記第１のボリュームから前記第２のボリュームへのデータの前記転送の完了にさらに応答して、前記第１のボリュームを前記ホールド・カテゴリから前記保持カテゴリへ再分類することと、をさらに含み、前記第１のボリュームの前記復元による前記第１のボリュームの変更は、前記第１のボリュームの前記仮想復元および前記物理的復元の両方の間では回避され、
    前記方法は、少なくとも１つのポリシーを前記第２のボリュームに割り当てることをさらに含み、前記ポリシーが、ボリュームを維持する期間および前記ボリュームのバージョンの許可された数のうちの少なくとも１つに関するパラメータを定義する、請求項２２に記載の方法。
  24. 前記ストレージのボリューム・シリアル付番規則に従うボリューム・シリアル番号を有する第４のボリュームを使用して第３のボリュームの仮想復元を実行することを含む、前記第３のボリュームを前記ストレージにインポートすることをさらに含み、前記第３のボリュームの前記仮想復元は、前記第４のボリュームを前記第３のボリュームの仮想復元として前記第３のボリュームにマッピングするように、前記第４のボリュームに関連付けられたメタデータを構成することを含む、請求項２１に記載の方法。
  25. 前記第２のボリュームを削除することと、
    第３のボリュームを前記第１のボリュームの第２の仮想復元として前記第１のボリュームにマッピングするように、前記第３のボリュームに関連付けられたメタデータを構成することを含む、前記第３のボリュームを使用して前記第１のボリュームの第２の仮想復元を実行することとをさらに含み、前記第１のボリュームは、前記第１のボリュームの前記第１および第２の仮想復元にわたって変更不可能なままである、請求項２１に記載の方法。
JP2023515642A 2020-09-24 2021-09-16 データ・ストレージ・ボリューム回復管理 Pending JP2023542287A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US17/031,276 2020-09-24
US17/031,276 US11461193B2 (en) 2020-09-24 2020-09-24 Data storage volume recovery management
PCT/CN2021/118734 WO2022063020A1 (en) 2020-09-24 2021-09-16 Data storage volume recovery management

Publications (1)

Publication Number Publication Date
JP2023542287A true JP2023542287A (ja) 2023-10-06

Family

ID=80740420

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023515642A Pending JP2023542287A (ja) 2020-09-24 2021-09-16 データ・ストレージ・ボリューム回復管理

Country Status (8)

Country Link
US (2) US11461193B2 (ja)
JP (1) JP2023542287A (ja)
KR (1) KR20230056707A (ja)
CN (1) CN116324732A (ja)
AU (1) AU2021348394B2 (ja)
DE (1) DE112021004991T5 (ja)
GB (1) GB2614675A (ja)
WO (1) WO2022063020A1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11461193B2 (en) 2020-09-24 2022-10-04 International Business Machines Corporation Data storage volume recovery management
US11983430B2 (en) * 2022-08-01 2024-05-14 International Business Machines Corporation Replicating data to a plurality of replication devices through a tape device

Family Cites Families (49)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6703228B1 (en) * 1998-09-25 2004-03-09 Massachusetts Institute Of Technology Methods and products related to genotyping and DNA analysis
US7630986B1 (en) * 1999-10-27 2009-12-08 Pinpoint, Incorporated Secure data interchange
US6513101B1 (en) * 2000-01-04 2003-01-28 International Business Machines Corporation Expiring host selected scratch logical volumes in an automated data storage library
WO2002017207A2 (en) * 2000-08-23 2002-02-28 Arexis Ab System and method of storing genetic information
WO2002033520A2 (en) * 2000-10-18 2002-04-25 Genomic Health, Inc. Genomic profile information systems and methods
AU1234402A (en) * 2000-10-20 2002-04-29 Virco Nv Establishment of biological cut-off values for predicting resistance to therapy
US8898021B2 (en) * 2001-02-02 2014-11-25 Mark W. Perlin Method and system for DNA mixture analysis
US7783665B1 (en) * 2002-03-27 2010-08-24 Parallels Holdings, Ltd. Effective file-sharing among virtual environments
US20050152905A1 (en) * 2002-08-22 2005-07-14 Omoigui Osemwota S. Method of biochemical treatment of persistent pain
US7020755B2 (en) 2002-08-29 2006-03-28 International Business Machines Corporation Method and apparatus for read-only recovery in a dual copy storage system
US6954831B2 (en) * 2002-08-29 2005-10-11 International Business Machines Corporation Method, system, and article of manufacture for borrowing physical volumes
US6985916B2 (en) * 2002-08-29 2006-01-10 International Business Machines Corporation Method, system, and article of manufacture for returning physical volumes
US20070166728A1 (en) * 2005-07-22 2007-07-19 Alphagenics, Inc. Genetic profile imaging and data-sharing device and methodology for socially relevant traits
US20070198485A1 (en) * 2005-09-14 2007-08-23 Jorey Ramer Mobile search service discovery
US20080009268A1 (en) * 2005-09-14 2008-01-10 Jorey Ramer Authorized mobile content search results
US20080015968A1 (en) * 2005-10-14 2008-01-17 Leviathan Entertainment, Llc Fee-Based Priority Queuing for Insurance Claim Processing
WO2007143166A2 (en) * 2006-06-02 2007-12-13 University Of Louisville Research Foundation, Inc. Interoperable public and proprietary web accessible database and data brokerage
US20080131887A1 (en) * 2006-11-30 2008-06-05 Stephan Dietrich A Genetic Analysis Systems and Methods
US7844609B2 (en) * 2007-03-16 2010-11-30 Expanse Networks, Inc. Attribute combination discovery
US7818396B2 (en) * 2007-06-21 2010-10-19 Microsoft Corporation Aggregating and searching profile data from multiple services
US8738871B1 (en) * 2007-06-29 2014-05-27 Symantec Corporation Method and apparatus for mapping virtual drives
US20090043752A1 (en) * 2007-08-08 2009-02-12 Expanse Networks, Inc. Predicting Side Effect Attributes
US8010896B2 (en) * 2007-09-13 2011-08-30 International Business Machines Corporation Using profiling when a shared document is changed in a content management system
EP2215253B1 (en) * 2007-09-26 2016-04-27 Navigenics, Inc. Method and computer system for correlating genotype to phenotype using population data
US8589437B1 (en) * 2007-10-15 2013-11-19 23Andme, Inc. De-identification and sharing of genetic data
WO2009051749A1 (en) * 2007-10-15 2009-04-23 23Andme, Inc. Genetic comparisons between grandparents and grandchildren
WO2010017520A1 (en) * 2008-08-08 2010-02-11 Navigenics, Inc. Methods and systems for personalized action plans
BRPI0918889A2 (pt) * 2008-09-12 2015-12-01 Navigenics Inc método para gerar uma pontuação de um índice composto genético ambiental (egci) para uma doença ou condição de um indivíduo
EP3276526A1 (en) * 2008-12-31 2018-01-31 23Andme, Inc. Finding relatives in a database
US8595430B2 (en) * 2010-09-30 2013-11-26 International Business Machines Corporation Managing a virtual tape library domain and providing ownership of scratch erased volumes to VTL nodes
US10152492B1 (en) 2012-03-30 2018-12-11 EMC IP Holding Company LLC Extended recycle bin for versioning
US10013166B2 (en) * 2012-12-20 2018-07-03 Amazon Technologies, Inc. Virtual tape library system
CN104956309B (zh) * 2013-01-25 2017-12-12 株式会社日立制作所 存储系统及数据管理方法
CN103336728A (zh) 2013-05-08 2013-10-02 上海爱数软件有限公司 一种磁盘数据恢复方法
CN104216796B (zh) 2013-06-04 2018-02-09 北京联想核芯科技有限公司 一种数据备份、恢复方法及电子设备
US9552370B1 (en) * 2013-06-27 2017-01-24 EMC IP Holding Company LLC Signaling impending out of storage condition from a virtual tape drive
US9606930B2 (en) * 2014-08-05 2017-03-28 International Business Machines Corporation Tape-managed partition support for effective workload allocation and space management
US9514010B2 (en) * 2014-09-19 2016-12-06 Netapp, Inc Cluster-wide service agents
US10776210B2 (en) * 2016-09-30 2020-09-15 Hewlett Packard Enterprise Development Lp Restoration of content of a volume
US10621047B2 (en) 2017-04-06 2020-04-14 International Business Machines Corporation Volume group structure recovery in a virtualized server recovery environment
CN108038026B (zh) 2017-11-17 2021-11-30 中国科学院信息工程研究所 一种基于闪存的数据快速恢复方法与系统
US10852981B2 (en) * 2018-05-04 2020-12-01 EMC IP Holding Company LLC System for migrating virtual tape volumes between filesystems
US10521132B1 (en) * 2018-06-17 2019-12-31 International Business Machines Corporation Dynamic scratch pool management on a virtual tape system
US11221989B2 (en) 2018-07-31 2022-01-11 International Business Machines Corporation Tape image reclaim in hierarchical storage systems
US11468014B2 (en) * 2018-08-09 2022-10-11 Netapp Inc. Resynchronization to a filesystem synchronous replication relationship endpoint
US11086558B2 (en) * 2018-11-01 2021-08-10 EMC IP Holding Company LLC Storage system with storage volume undelete functionality
US11366682B1 (en) * 2019-10-22 2022-06-21 Amazon Technologies, Inc. Automatic snapshotting for recovery of instances with local storage
US11886392B2 (en) 2020-09-21 2024-01-30 International Business Machines Corporation Managing versions of objects resulting from appending data for space efficiency
US11461193B2 (en) 2020-09-24 2022-10-04 International Business Machines Corporation Data storage volume recovery management

Also Published As

Publication number Publication date
WO2022063020A1 (en) 2022-03-31
AU2021348394A1 (en) 2023-03-23
GB2614675A (en) 2023-07-12
DE112021004991T5 (de) 2023-07-06
US12026069B2 (en) 2024-07-02
US20220413973A1 (en) 2022-12-29
GB202305748D0 (en) 2023-05-31
CN116324732A (zh) 2023-06-23
US20220091944A1 (en) 2022-03-24
AU2021348394B2 (en) 2023-08-17
KR20230056707A (ko) 2023-04-27
US11461193B2 (en) 2022-10-04

Similar Documents

Publication Publication Date Title
US10698773B2 (en) Replicating a source data set to a target data store
US9009443B2 (en) System and method for optimized reclamation processing in a virtual tape library system
US7660834B2 (en) Maintaining an aggregate including active files in a storage pool
US8924664B2 (en) Logical object deletion
US10872017B2 (en) Restoring a file system object
US11327924B2 (en) Archiving data sets in a volume in a primary storage in a volume image copy of the volume in a secondary storage
CN110799960A (zh) 数据库租户迁移的系统和方法
US12026069B2 (en) Data storage volume recovery management
US11314639B2 (en) Protecting against data loss during garbage collection
JP2006505069A (ja) ハードウェアベースのファイルシステムのための装置および方法
US11321007B2 (en) Deletion of volumes in data storage systems
US20120311227A1 (en) Information storage system, snapshot acquisition method, and data storage medium
US9122689B1 (en) Recovering performance of a file system post-migration
US9665436B2 (en) Creation and management of logical volume snapshots under hierarchical storage system
US11886392B2 (en) Managing versions of objects resulting from appending data for space efficiency
US10606506B2 (en) Releasing space allocated to a space efficient target storage in a copy relationship with a source storage
US11675668B2 (en) Leveraging a cloud-based object storage to efficiently manage data from a failed backup operation
US20240078179A1 (en) Efficient write-back for journal truncation

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230327

Free format text: JAPANESE INTERMEDIATE CODE: A821

Effective date: 20230316

RD16 Notification of change of power of sub attorney

Free format text: JAPANESE INTERMEDIATE CODE: A7436

Effective date: 20230315

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20240215