JP2023536896A - データの論理的破損保護 - Google Patents

Abstract

データの論理的破損保護コンピュータ実装方法は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を受け取る段階と、要求に応えて、バックアップ格納スペースに追加エクステントを追加する段階と、バックアップ格納スペース内の現在のエクステント位置を識別する段階と、現在のエクステント位置とバックアップ格納スペースに追加された追加エクステントとの間に充満エクステント位置が存在するかどうかを判定する段階と、判定に基づいて、バックアップ格納スペースに追加された追加エクステントを条件付きで利用する段階とを含んでいる。

Description

本発明はデータの論理的破損保護（ＬＣＰ）の実装に関するものであり、より詳細には、本発明はＬＣＰを実装するための格納容量の拡大に関する。

格納ボリューム内のデータに論理的破損保護（ＬＣＰ）を実装するには、バックアップ格納スペースを作成して使用し、格納ボリュームからのデータのバックアップを格納する。例えば、格納ボリューム内の所定のデータのポイント・イン・タイム・スナップショットを作成し、バックアップ格納スペース内に格納してもよい。これらのデータバックアップを使用して、消失した、又は破損した格納ボリューム内のデータを復元してもよい。

ただし、現在のところ、バックアップ格納スペースのサイズの増加を望む場合は、最初にバックアップ格納スペースを、バックアップ格納スペースに格納されているすべてのデータバックアップとともに消去しなければならず、それから、当初のサイズよりも大きい交換用バックアップ格納スペースを作成することができる。このことにより、ＬＣＰ実装によってかなりの処理量が必要になるだけでなく、当初のバックアップ格納スペースを消去してから、新しいデータバックアップを交換用バックアップ格納スペースに格納するまでの間、格納ボリュームはデータの消失／破損に対して脆弱なままで放置されてしまう。

一態様によるコンピュータ実装方法は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を受け取る段階と、前記要求に応えて、前記バックアップ格納スペースに追加エクステントを追加する段階と、前記バックアップ格納スペース内の現在のエクステント位置を識別する段階と、前記現在のエクステント位置と前記バックアップ格納スペースに追加された前記追加エクステントとの間に充満エクステント位置が存在するかどうかを判定する段階と、前記判定に基づいて、前記バックアップ格納スペースに追加された前記追加エクステントを条件付きで利用する段階とを含んでいる。

このように、格納ボリュームのためのバックアップ格納スペースのサイズを増加させてもよく、最初にバックアップ格納スペース全体（及び格納されているすべてのデータバックアップ）を消去して新しいサイズで新しいバックアップ格納スペースを構築する必要はない。これにより、バックアップ格納スペースを拡大するために必要な処理量を削減でき、このような拡大を実装する１つ又は複数の有形コンピューティングデバイスの性能を改善することができる。

一態様では、バックアップ格納スペース及び格納ボリュームのパラメータの監視に基づいて自動的に要求を生成し、そのパラメータは容量使用量の閾値、乗数の増分量、及び乗数の制限を含んでいる。

別の態様によれば、論理的破損保護を実装するために格納容量を拡大するためのコンピュータプログラム製品は、具現化されたプログラム命令を有するコンピュータ可読格納媒体を備えており、前記コンピュータ可読格納媒体は、一過性の信号それ自体ではなく、前記プログラム命令はプロセッサによって、前記プロセッサに方法を遂行させるように実行可能であり、前記方法は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を、前記プロセッサによって受け取る段階と、前記要求に応えて前記バックアップ格納スペースに追加エクステントを、前記プロセッサによって追加する段階と、前記バックアップ格納スペース内の現在のエクステント位置を、前記プロセッサによって識別する段階と、前記現在のエクステント位置と前記バックアップ格納スペースに追加された前記追加エクステントとの間に充満エクステント位置が存在するかどうかを、前記プロセッサによって判定する段階と、前記判定に基づいて、前記バックアップ格納スペースに追加された前記追加エクステントを、前記プロセッサによって条件付きで利用する段階とを含んでいる。

一態様では、現在のエクステント位置は、ローリングバッファ方式に従って判定される。

別の態様によれば、システムは、プロセッサと、前記プロセッサと統合されているか、前記プロセッサによって実行可能であるか、又は前記プロセッサと統合されていてかつ前記プロセッサによって実行可能である論理とを備えており、前記論理は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を受け取り、前記要求に応えて、前記バックアップ格納スペースに追加エクステントを追加し、前記バックアップ格納スペース内の現在のエクステント位置を識別し、前記現在のエクステント位置と前記バックアップ格納スペースに追加された前記追加エクステントとの間に充満エクステント位置が存在するかどうかを判定し、前記判定に基づいて、前記バックアップ格納スペースに追加された前記追加エクステントを条件付きで利用するように構成されている。

別の態様によれば、コンピュータ実装方法は、格納ボリュームのためのバックアップ格納スペースの現在の使用量を監視する段階と、前記現在の使用量を容量閾値と比較する段階と、前記比較する段階及び所定のサイズ制限に基づいて、前記バックアップ格納スペースのサイズを条件付きで増加させる段階とを含んでいる。

別の態様によれば、バックアップ格納スペースの管理を自動化するためのコンピュータプログラム製品は、具現化されたプログラム命令を有するコンピュータ可読格納媒体を備えており、前記コンピュータ可読格納媒体は、一過性の信号それ自体ではなく、前記プログラム命令はプロセッサによって、前記プロセッサに方法を遂行させるように実行可能であり、前記方法は、格納ボリュームのためのバックアップ格納スペースの現在の使用量を、前記プロセッサによって監視する段階と、前記現在の使用量を容量閾値と、前記プロセッサによって比較する段階と、前記比較する段階及び所定のサイズ制限に基づいて、前記バックアップ格納スペースのサイズを、前記プロセッサによって条件付きで増加させる段階とを含んでいる。

このように、バックアップ格納スペースのサイズを、格納ボリュームに合わせて動的に調整してもよい。これにより、バックアップ格納スペースは確実に、ＬＣＰ実装の部分として格納ボリュームのための十分な数のデータバックアップをサポートするのに十分な大きさになる。その結果、データの破損／消失からの格納ボリュームのデータ保護を確実にすることができ、格納ボリュームを利用する１つ又は複数の有形コンピューティングデバイスの性能をさらに改善することができる。

本発明の他の態様及び実施形態は、図面と併せて解釈すると、例として本発明の原理を示している以下の詳細な説明から明らかになるであろう。

本発明の一態様によるクラウドコンピューティング環境を表す。

本発明の一態様による抽象化モデルレイヤを表す。

本発明の一態様によるクラウドコンピューティングノードを表す。

本発明の一態様による階層化データ格納システムを例示する。

本発明の一態様による例示的なセーフガードバックアップ構成を例示する。

本発明の一態様による例示的なＣＳＭセーフガードコピーセッションを例示する。

本発明の一態様による例示的なセーフガードコピー構成を例示する。

本発明の一態様による、論理的破損保護を実装するために格納容量を拡大する方法のフローチャートを例示する。

本発明の一態様による、バックアップ格納スペースの管理を自動化する方法のフローチャートを例示する。

本発明の一態様による、例示的な拡大格納環境を例示する。

以下の説明は、本発明の一般的な原理を例示する目的でなされたものであり、本明細書で請求される発明の概念を限定することを意味するものではない。
さらに、本明細書に記載の特定の特徴は、様々な可能な組み合わせ及び置換のそれぞれにおいて、他の説明された特徴と組み合わせて使用することができる。

別段本明細書に具体的に定義されない限り、すべての用語は、本明細書から示唆される意味、及び、当業者によって理解される意味若しくは辞書、論文などで定義される意味又はその組み合わせを含んで、それらの最も広い可能な解釈が与えられるものとする。

本明細書及び添付の特許請求項で使用されるとき、単数形「ａ」、「ａｎ」、及び「ｔｈｅ」は、別段指定されない限り、複数の指示物を含むことも留意されなければならない。「含む（ｃｏｍｐｒｉｓｅｓ）」若しくは「含む（ｃｏｍｐｒｉｓｉｎｇ）」又はその両方の用語は、本明細書で使用されるとき、記載されている特徴、整数、段階、動作、要素若しくは構成要素又はその組み合わせの存在を指定するが、１つ又は複数の他の特徴、整数、段階、動作、要素、構成要素若しくはそれらの群又はその組み合わせの存在又は追加を除外しないことがさらに理解されるであろう。

以下の説明は、論理的破損保護を実装するための格納容量の拡大のいくつかの態様を開示する。

一般的な一態様では、コンピュータ実装方法は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を受け取る段階と、要求に応えて、バックアップ格納スペースに追加エクステントを追加する段階と、バックアップ格納スペース内の現在のエクステント位置を識別する段階と、現在のエクステント位置とバックアップ格納スペースに追加された追加エクステントとの間に充満エクステント位置が存在するかどうかを判定する段階と、判定に基づいて、バックアップ格納スペースに追加された追加エクステントを条件付きで利用する段階とを含んでいる。

このように、格納ボリュームのためのバックアップ格納スペースのサイズを増加させてもよく、最初にバックアップ格納スペース全体（及び格納されているすべてのデータバックアップ）を消去して新しいサイズで新しいバックアップ格納スペースを構築する必要はない。これにより、バックアップ格納スペースを拡大するために必要な処理量を削減でき、このような拡大を実装する１つ又は複数の有形コンピューティングデバイスの性能を改善することができる。

一般的な一態様では、バックアップ格納スペース及び格納ボリュームのパラメータの監視に基づいて自動的に要求を生成し、そのパラメータは容量使用量の閾値、乗数の増分量、及び乗数の制限を含んでいる。

別の一般的な態様によれば、論理的破損保護を実装するために格納容量を拡大するためのコンピュータプログラム製品は、具現化されたプログラム命令を有するコンピュータ可読格納媒体を備えており、コンピュータ可読格納媒体は、一過性の信号それ自体ではなく、プログラム命令はプロセッサによって、プロセッサに方法を遂行させるように実行可能であり、その方法は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を、プロセッサによって受け取る段階と、要求に応えてバックアップ格納スペースに追加エクステントを、プロセッサによって追加する段階と、バックアップ格納スペース内の現在のエクステント位置を、プロセッサによって識別する段階と、現在のエクステント位置とバックアップ格納スペースに追加された追加エクステントとの間に充満エクステント位置が存在するかどうかを、プロセッサによって判定する段階と、判定に基づいて、バックアップ格納スペースに追加された追加エクステントを、プロセッサによって条件付きで利用する段階とを含んでいる。

一般的な一態様では、現在のエクステント位置は、ローリングバッファ方式に従って判定される。

別の一般的な態様によれば、システムは、プロセッサと、プロセッサと統合されているか、プロセッサによって実行可能であるか、又はプロセッサと統合されていてかつプロセッサによって実行可能である論理とを備えており、論理は、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を受け取り、要求に応えて、バックアップ格納スペースに追加エクステントを追加し、バックアップ格納スペース内の現在のエクステント位置を識別し、現在のエクステント位置とバックアップ格納スペースに追加された追加エクステントとの間に充満エクステント位置が存在するかどうかを判定し、判定に基づいて、バックアップ格納スペースに追加された追加エクステントを条件付きで利用するように構成されている。

別の一般的な態様によれば、コンピュータ実装方法は、格納ボリュームのためのバックアップ格納スペースの現在の使用量を監視する段階と、現在の使用量を容量閾値と比較する段階と、比較する段階及び所定のサイズ制限に基づいて、バックアップ格納スペースのサイズを条件付きで増加させる段階とを含んでいる。

別の一般的な態様によれば、バックアップ格納スペースの管理を自動化するためのコンピュータプログラム製品は、具現化されたプログラム命令を有するコンピュータ可読格納媒体を備えており、コンピュータ可読格納媒体は、一過性の信号それ自体ではなく、プログラム命令はプロセッサによって、プロセッサに方法を遂行させるように実行可能であり、その方法は、格納ボリュームのためのバックアップ格納スペースの現在の使用量を、プロセッサによって監視する段階と、現在の使用量を容量閾値と、プロセッサによって比較する段階と、比較する段階及び所定のサイズ制限に基づいて、バックアップ格納スペースのサイズを、プロセッサによって条件付きで増加させる段階とを含んでいる。

このように、バックアップ格納スペースのサイズを、格納ボリュームに合わせて動的に調整してもよい。これにより、バックアップ格納スペースは確実に、ＬＣＰ実装の部分として格納ボリュームのための十分な数のデータバックアップをサポートするのに十分な大きさになる。その結果、データの破損／消失からの格納ボリュームのデータ保護を確実にすることができ、格納ボリュームを利用する１つ又は複数の有形コンピューティングデバイスの性能をさらに改善することができる。

この開示はクラウドコンピューティングに関する詳細な説明を含んでいるが、本明細書に記載の教示の実装は、クラウドコンピューティング環境に限定されないことを理解するべきである。むしろ、本発明の態様は、現在知られている、又は後に開発される他の任意の種類のコンピューティング環境と共に実装され得る。

クラウドコンピューティングは、最小限の管理労力又はサービスのプロバイダとの対話で、迅速にプロビジョニング及びリリースができる構成可能コンピューティングリソース（例えば、ネットワーク、ネットワーク帯域幅、サーバ、処理、メモリ、格納、アプリケーション、仮想マシン、及びサービス）の共有プールへの便利なオンデマンド型ネットワークアクセスを可能にするサービスデリバリモデルである。このクラウドモデルは、少なくとも５つの特性、少なくとも３つのサービスモデル、及び少なくとも４つの展開モデルを含んでもよい。

以下が特性である。

オンデマンドのセルフサービス：クラウド利用者は、サービスのプロバイダとの人間による対話を必要とせずに、必要に応じて自動的に、サーバ時間及びネットワーク格納などのコンピューティング能力を一方的にプロビジョニングできる。

広いネットワークアクセス：ネットワークを介して能力を利用可能であり、異種混交のシンクライアントプラットフォーム又はシッククライアントプラットフォーム（例えば、携帯電話、ラップトップ、及び、ＰＤＡ）による使用を促進する標準的なメカニズムを通して能力にアクセスする。

リソースプーリング：プロバイダのコンピューティングリソースをプールし、マルチテナントモデルを使用して複数の利用者にサービスを提供しており、異なる物理及び仮想リソースが需要に応じて動的に割り当てられ、再割り当てされる。利用者は、概して、提供されるリソースの厳密な位置を制御も、又はそれを知ることもできないが、より高い抽象レベル（例えば、国、州、又はデータセンタ）では位置を指定可能である点で、位置的独立感がある。

迅速な伸縮性：場合によっては自動的に、能力を迅速かつ伸縮自在にプロビジョニングして素早くスケールアウトすることも、迅速にリリースして素早くスケールインすることも可能である。利用者にとって、多くの場合、プロビジョニングに使用できる能力は無制限に表示され、いつでも任意の数量で購入できる。

計測サービス：サービスの種類（例えば、格納、処理、帯域幅、及びアクティブなユーザアカウント）に適したある抽象レベルで計量能力を活用することにより、クラウドシステムはリソースの使用を自動的に制御及び最適化する。リソースの使用量を監視、制御、報告できるため、利用したサービスのプロバイダと利用者の両方に透明性を提供できる。

以下がサービスモデルである。

サービスとしてのソフトウェア（ＳａａＳ）：利用者に提供される能力は、クラウドインフラストラクチャで実行されているプロバイダのアプリケーションの使用である。アプリケーションには、ウェブブラウザ（例えば、ウェブベースのメール）等のシンクライアントインターフェースを介して様々なクライアントデバイスからアクセスできる。利用者は、ネットワーク、サーバ、オペレーティングシステム、格納、又は個々のアプリケーション能力をも含む、基盤となるクラウドインフラストラクチャを管理も、又は制御もしないが、限定されたユーザ固有のアプリケーション構成設定が例外になることはあり得る。

サービスとしてのプラットフォーム（ＰａａＳ）：利用者に提供される能力は、プロバイダがサポートするプログラミング言語及びツールを使用して作成された、利用者作成又は取得のアプリケーションのクラウドインフラストラクチャ上への展開である。利用者は、ネットワーク、サーバ、オペレーティングシステム、又は格納を含む、基盤となるクラウドインフラストラクチャを管理も、又は制御もしないが、展開されたアプリケーションと、場合によってはアプリケーションのホスティング環境構成とを制御できる。

サービスとしてのインフラストラクチャ（ＩａａＳ）：利用者に提供される能力は、処理、格納、ネットワーク、その他の基本的なコンピューティングリソースのプロビジョニングであり、ここで、利用者は任意のソフトウェア（オペレーティングシステムとアプリケーションを含み得る）を展開及び実行できる。利用者は基盤となるクラウドインフラストラクチャを管理も、又は制御もしないが、オペレーティングシステム、格納、展開されたアプリケーションを制御でき、場合によっては選ばれたネットワーク構成要素（例えば、ホストファイアウォール）を限定的に制御できる。

以下が展開モデルである。

プライベートクラウド：クラウドインフラストラクチャは組織専用に動作する。これは組織又はサードパーティによって管理され、オンプレミス又はオフプレミスに存在する場合がある。

コミュニティクラウド：クラウドインフラストラクチャは複数の組織で共有され、懸念事項（例えば、ミッション、セキュリティ要件、方針、及びコンプライアンスの考慮事項）を共有してきた特定のコミュニティをサポートしている。これは組織又はサードパーティによって管理され、オンプレミス又はオフプレミスに存在する場合がある。

パブリッククラウド：クラウドインフラストラクチャは、一般市民又は大規模業界団体が利用でき、クラウドサービスを販売する組織が所有している。

ハイブリッドクラウド：クラウドインフラストラクチャは、２つ又はそれより多くのクラウド（プライベート、コミュニティ、又はパブリック）の合成体であり、それらは独自のエンティティでありながら、データとアプリケーションの移植性（例えば、クラウド間の負荷均衡化のためのクラウドバースト）を可能にする標準化された又は独自開発の技術によって結びつけられている。

クラウドコンピューティング環境は、ステートレス性、低結合性、モジュール性、及びセマンティック相互運用性を重視したサービス指向型である。クラウドコンピューティングの中心は、相互接続されたノードのネットワークを含むインフラストラクチャである。

ここで図１を参照すると、例示的なクラウドコンピューティング環境５０が示されている。図示のように、クラウドコンピューティング環境５０は、１つ又は複数のクラウドコンピューティングノード１０を備えており、これらを相手に、クラウド利用者が使用するローカルコンピューティングデバイス（例えば、携帯情報端末（ＰＤＡ）又は携帯電話５４Ａ、デスクトップコンピュータ５４Ｂ、ラップトップコンピュータ５４Ｃ、若しくは自動車コンピュータシステム５４Ｎ、又はそれらの組み合わせ等）は通信することができる。ノード１０は互いに通信してもよい。それらを、１つ又は複数のネットワーク（上記で説明したようなプライベートクラウド、コミュニティクラウド、パブリッククラウド、若しくはハイブリッドクラウド、又はそれらの組み合わせなど）において、物理的又は仮想的にグループ化してもよい（図示せず）。これにより、クラウドコンピューティング環境５０は、インフラストラクチャ、プラットフォーム、若しくはソフトウェア、又はそれらの組み合わせをサービスとして提供できるようになり、そのために、クラウド利用者がローカルコンピューティングデバイス上にリソースを維持する必要はない。図１に示すコンピューティングデバイス５４Ａ～Ｎの型式は例示のみを意図しており、コンピューティングノード１０及びクラウドコンピューティング環境５０は任意の種類のネットワーク、若しくはネットワークアドレス可能な接続、又はそれらの組み合わせを通して（例えば、ウェブブラウザを使用して）任意の種類のコンピュータ化デバイスと通信できることが理解される。

ここで図２を参照すると、クラウドコンピューティング環境５０（図１）によって提供されるひと揃いの機能的抽象レイヤが示されている。図２に示される構成要素、レイヤ、及び機能は、例示のみを意図しており、本発明の態様はそれらに限定されないことを事前に理解するべきである。図示のように、以下のレイヤ及び対応する機能が提供される。

ハードウェア及びソフトウェアレイヤ６０は、ハードウェア及びソフトウェア構成要素を備える。ハードウェア構成要素の例には、メインフレーム６１と、ＲＩＳＣ（縮小命令セットコンピュータ）アーキテクチャベースのサーバ６２と、サーバ６３と、ブレードサーバ６４と、格納デバイス６５と、ネットワーク及びネットワーク構成要素６６が含まれる。いくつかの態様では、ソフトウェア構成要素には、ネットワーク・アプリケーション・サーバ・ソフトウェア６７及びデータベース・ソフトウェア６８が含まれる。

仮想レイヤ７０は抽象レイヤを提供し、そこから提供され得る仮想エンティティの例には、仮想サーバ７１、仮想格納７２、仮想ネットワーク７３（仮想プライベートネットワークを含む）、仮想アプリケーション及びオペレーティングシステム７４、仮想クライアント７５がある。

一実施例では、管理レイヤ８０は、以下で説明する機能を提供してもよい。リソースプロビジョニング８１は、コンピューティングリソースと、クラウドコンピューティング環境内でタスクを遂行するために利用される他のリソースの動的獲得を提供する。計量及び価格設定８２は、リソースがクラウドコンピューティング環境内で利用される際のコスト追跡と、これらのリソースの消費に対する勘定又は請求を提供する。一例では、これらのリソースは、アプリケーション・ソフトウェア・ライセンスを含んでもよい。セキュリティが、クラウドの利用者とタスクの身元証明、及びデータとその他のリソースの保護を提供する。ユーザポータル８３は、利用者及びシステム管理者にクラウドコンピューティング環境へのアクセスを提供する。サービスレベル管理８４は、必要なサービスレベルに適合するように、クラウドコンピューティングリソースの割り当て及び管理を提供する。サービスレベルアグリーメント（ＳＬＡ）の計画及び履行８５は、ＳＬＡに従って将来の必要性が予想されるクラウドコンピューティングリソースの事前編成と獲得を提供する。

作業負荷レイヤ９０は、クラウドコンピューティング環境を利用し得る機能の例を提供する。このレイヤから提供され得る作業負荷と機能の例には、マッピング及びナビゲーション９１、ソフトウェア開発及びライフサイクル管理９２、仮想教室教育デリバリ９３、データ分析処理９４、トランザクション処理９５、論理的破損保護（ＬＣＰ）９６が含まれる。

ここで図３を参照すると、クラウドコンピューティングノードの例の概略図が示されている。クラウドコンピューティングノード１０は、好適なクラウドコンピューティングノードの一例にすぎず、本明細書に記載の本発明の態様の使用又は機能の範囲に関していかなる限定の示唆を意図するものではない。いずれにしても、クラウドコンピューティングノード１０は、上述の機能のいずれも実装若しくは遂行又はその両方をすることができる。

クラウドコンピューティングノード１０には、コンピュータシステム／サーバ１２があり、これは、他の多くの汎用又は専用のコンピューティングシステム環境又は構成で動作する。コンピュータシステム／サーバ１２との使用に好適である可能性がある周知のコンピューティングシステム、環境、若しくは構成又はそれらの組み合わせの例には、これらに限定されないが、パーソナルコンピュータシステム、サーバコンピュータシステム、シンクライアント、シッククライアント、手持ち型又はラップトップ型デバイス、マルチプロセッサシステム、マイクロプロセッサベースのシステム、セットトップボックス、プログラム可能な家電、ネットワークＰＣ、ミニコンピュータシステム、メインフレームコンピュータシステム、及び任意の上記のシステム又はデバイス等を含む分散型クラウドコンピューティング環境が含まれる。

コンピュータシステム／サーバ１２を、コンピュータシステムによって実行されているプログラムモジュールなどのコンピュータシステム実行可能命令の一般的な文脈で説明してもよい。概して、プログラムモジュールは、特定のタスクを遂行する、又は特定の抽象データ形式を実装するルーチン、プログラム、オブジェクト、構成要素、論理、データ構造などを含んでもよい。コンピュータシステム／サーバ１２を分散型クラウドコンピューティング環境で実施してもよく、ここでは、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが遂行される。分散型クラウドコンピューティング環境では、プログラムモジュールを、メモリ格納デバイスを含むローカル及びリモートの両方のコンピュータシステム格納媒体に置いてもよい。

図３に示すように、クラウドコンピューティングノード１０内のコンピュータシステム／サーバ１２が、汎用コンピューティングデバイスの形態で示されている。コンピュータシステム／サーバ１２の構成要素には、これらに限定されないが、１つ又は複数のプロセッサ又は処理ユニット１６、システムメモリ２８、及びシステムメモリ２８を含む様々なシステム構成要素をプロセッサ１６に結合しているバス１８が含まれ得る。

バス１８は、いくつかの種類のバス構造のうちのいずれか１つ又は複数を表し、メモリバス又はメモリコントローラ、周辺バス、アクセラレーテッド・グラフィックス・ポート、様々なバスアーキテクチャのいずれかを使用するプロセッサ又はローカルのバスを含む。限定ではなく例として、そのようなアーキテクチャには、インダストリ・スタンダード・アーキテクチャ（ＩＳＡ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ）バス、エンハンスドＩＳＡ（ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ）ローカルバス、及び周辺機器相互接続（ＰＣＩ）バスが含まれる。

コンピュータシステム／サーバ１２は、通常、様々なコンピュータシステム可読媒体を含む。そのような媒体は、コンピュータシステム／サーバ１２によってアクセス可能な任意の利用可能な媒体であってもよく、揮発性媒体と不揮発性媒体、リムーバブル媒体と非リムーバブル媒体の両方を含む。

システムメモリ２８は、ランダムアクセスメモリ（ＲＡＭ）３０若しくはキャッシュメモリ３２又はそれらの組み合わせなど、揮発性メモリの形態のコンピュータシステム可読媒体を含むことができる。コンピュータシステム／サーバ１２は、他のリムーバブル／非リムーバブル、揮発性／不揮発性のコンピュータシステム格納媒体をさらに含んでもよい。単に、例として、格納システム３４は、非リムーバブルな不揮発性磁気媒体から読み取り、そこへ書き込むために提供され得る（図示されていないが、通常は「ハードドライブ」と呼ばれる）。図示されていないが、リムーバブルな不揮発性磁気ディスク（例えば、「フロッピディスク」）から読み取り、そこへ書き込むための磁気ディスクドライブと、ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ又は他の光学媒体などのリムーバブルな不揮発性光ディスクから読み取り、又はそこへ書き込むための光ディスクドライブを提供することができる。そのような場合、それぞれは、１つ又は複数のデータ媒体インターフェースによってバス１８に接続され得る。以下でさらに図示及び説明するように、メモリ２８は、本発明の態様の機能を実施するように構成されたひと揃い（例えば、少なくとも１つ）のプログラムモジュールを有する少なくとも１つのプログラム製品を備えてもよい。

ひと揃い（少なくとも１つ）のプログラムモジュール４２を有するプログラム／ユーティリティ４０を、限定ではなく例として、メモリ２８に格納してもよく、また、オペレーティングシステム、１つ又は複数のアプリケーションプログラム、他のプログラムモジュール、及びプログラムデータも同様である。各オペレーティングシステム、１つ又は複数のアプリケーションプログラム、他のプログラムモジュール、及びプログラムデータ又はそれらの何らかの組み合わせは、ネットワーク環境の実装を含んでもよい。プログラムモジュール４２は、概して、本明細書に記載の本発明の態様の機能若しくは方式又はその組み合わせを実施する。

コンピュータシステム／サーバ１２はまた、キーボード、ポインティングデバイス、ディスプレイ２４などの１つ又は複数の外部デバイス１４、ユーザがコンピュータシステム／サーバ１２と相互に作用することを可能にする１つ又は複数のデバイス、若しくはコンピュータシステム／サーバ１２が１つ又は複数の他のコンピューティングデバイスと通信することを可能にする任意のデバイス（例えば、ネットワークカード、モデムなど）、又はそれらの組み合わせと通信してもよい。そのような通信は、入力／出力（Ｉ／Ｏ）インターフェース２２を介して生じ得る。さらに、また、コンピュータシステム／サーバ１２は１つ又は複数のネットワークと通信することができ、その例には、ローカルエリアネットワーク（ＬＡＮ）、一般的な広域ネットワーク（ＷＡＮ）、若しくはネットワークアダプタ２０を介したパブリックネットワーク（例えば、インターネット）、又はそれらの組み合わせがある。図示のように、ネットワークアダプタ２０は、バス１８を介してコンピュータシステム／サーバ１２の他の構成要素と通信する。図示されていないが、他のハードウェア構成要素若しくはソフトウェア構成要素又はそれらの組み合わせをコンピュータシステム／サーバ１２と共に使用できることを、理解するべきである。例としては、これらに限定されないが、マイクロコード、デバイスドライバ、冗長処理ユニット、外部ディスクドライブアレイ、ＲＡＩＤシステム、テープドライブ、及びデータアーカイブ格納システムなどが含まれる。

ここで図４を参照すると、一態様による格納システム４００が示されている。図４に示す要素のいくつかを、様々な態様によれば、ハードウェア若しくはソフトウェア又はそれらの組み合わせとして実装してもよいことに留意されたい。格納システム４００は、少なくとも１つの上位格納階層４０２及び少なくとも１つの下位格納階層４０６上の複数の媒体と通信するための格納システムマネージャ４１２を含んでもよい。上位格納階層４０２は、好ましくは、１つ又は複数のランダムアクセス若しくは直接アクセス又はそれらの組み合わせの媒体４０４を含んでもよく、その例には、ハードディスクドライブ（ＨＤＤ）内のハードディスク、不揮発性メモリ（ＮＶＭ）、ソリッドステートドライブ（ＳＳＤ）のソリッドステートメモリ、フラッシュメモリ、ＳＳＤアレイ、フラッシュメモリアレイなど、若しくは、本明細書に記載されている若しくは当技術分野で知られている他のもの、又はそれらの組み合わせがある。下位格納階層４０６は、好ましくは、１つ又は複数の下位性能格納媒体４０８を含んでもよく、そこには、テープドライブの磁気テープ若しくは光媒体若しくはそれらの組み合わせ等のシーケンシャルアクセス媒体、低速アクセスＨＤＤ、低速アクセスＳＳＤなど、若しくは、本明細書に記載されている若しくは当技術分野で知られている他のもの、又はそれらの組み合わせが含まれる。１つ又は複数の追加の格納階層４１６は、システム４００の設計者が望むように、格納メモリ媒体の任意の組み合わせを含んでもよい。また、上位格納階層４０２若しくは下位格納階層４０６又はそれらの組み合わせのいずれかは、格納デバイス若しくは格納媒体又はその両方の何らかの組み合わせを含んでもよい。

格納システムマネージャ４１２は上位格納階層４０２及び下位格納階層４０６上の格納媒体４０４、４０８と、図４に示すような格納エリアネットワーク（ＳＡＮ）などのネットワーク４１０、又は何らかの他の好適なネットワーク形式を介して通信してもよい。格納システムマネージャ４１２はまた、１つ又は複数のホストシステム（図示せず）と、ホストインターフェース４１４を介して通信してもよく、これは格納システムマネージャ４１２の部分であってもよいが、そうでなくてもよい。格納システムマネージャ４１２、若しくは格納システム４００の他の構成要素、又はそれらの組み合わせは、ハードウェア若しくはソフトウェア又はそれらの組み合わせで実装されてもよく、当技術分野で知られている種類のコマンドを実行するために、中央処理装置（ＣＰＵ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）、特定用途向け集積回路（ＡＳＩＣ）などのプロセッサ（図示せず）を使用してもよい。もちろん、本明細書を読めば当業者には明らかとなるように、任意の編成の格納システムを使用してもよい。

より多くの態様では、格納システム４００は、任意の数のデータ格納階層を含んでもよく、各格納階層内に同じ又は異なる格納メモリ媒体を含んでもよい。例えば、各データ格納階層は、同じ種類の格納メモリ媒体を含んでもよく、その例には、ＨＤＤ、ＳＳＤ、シーケンシャルアクセス媒体（テープドライブ内のテープ、光ディスクドライブ内の光ディスクなど）、直接アクセス媒体（ＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭなど）、又は媒体格納形式の任意の組み合わせがある。そのような構成の１つでは、上位格納階層４０２は、上位性能格納環境にデータを格納するためのＳＳＤ格納媒体の大部分を含んでもよく、下位格納階層４０６及び追加の格納階層４１６を含む残りの格納階層は、下位性能格納環境にデータを格納するためのＳＳＤ、ＨＤＤ、テープドライブなどの任意の組み合わせを含んでもよい。このように、より頻繁にアクセスされるデータ、より高い優先度を有するデータ、より素早くにアクセスする必要があるデータなどを上位格納階層４０２に格納してもよく、他方で、これらの属性を１つも持たないデータを追加の格納階層４１６（下位格納階層４０６も含めて）に格納してもよい。もちろん、当業者は、本説明を読めば、多くの他の格納媒体形式の組み合わせを考案して、本明細書に提示された態様に従って異なる格納スキームに実装し得る。

いくつかの態様によると、格納システム（４００など）は、要求を受け取ってデータセットを開くように構成された論理と、要求されたデータセットが複数の関連する一部で階層化データ格納システム４００の下位格納階層４０６に格納されているかどうかを判定するように構成された論理と、要求されたデータセットの各関連する一部を階層化データ格納システム４００の上位格納階層４０２に移動させるように構成された論理と、要求されたデータセットを関連する一部から、階層化データ格納システム４００の上位格納階層４０２上でアセンブルするように構成された論理とを含んでもよい。

もちろん、この論理を、様々な態様により、任意のデバイス若しくはシステム若しくはそれらの組み合わせ上の方法として、又はコンピュータプログラム製品として実装してもよい。
［論理的なデータ破損］

一態様では、論理的なデータ破損は、データ格納ハードウェアは損傷なく正常に機能しているが、格納されているデータがコンテンツレベルで破壊されている、若しくは破損している、又はその両方の場合に発生する。これは、意図的又は意図的でないデータの消去、暗号化、及び操作の結果として発生する可能性がある。例えば、論理的なデータ破損を生じさせる可能性がある、アプリケーションの破損の原因には、ユーザエラー、データの不注意又は悪意による破壊、許可なしにデータが暗号化され得るランサムウェアの実装などがある。

論理的なデータ破損に対処するために、論理的破損保護（ＬＣＰ）では、コンテンツを意識したソリューションの実装が必要になる場合がある。例えば、セーフガードコピー（ＳＧＣ）は、分散型格納システムに格納されたデータにＬＣＰを実装し、論理的なデータ破損のイベントの識別と、そのようなイベントからの回復を実装してもよい。
［セーフガードコピーの例示的な目的］

一態様では、セーフガードコピーは、以下の例示的な目的を有する。
● 容量使用量を最適化し、性能影響を最小限に抑えて、複数のボリューム又は格納システムの全体で多くの回復コピーを作成できるようにする。
● 本番環境の実行を継続しながら、以前の回復ポイントをひと揃いの回復ボリュームで利用できるようにする。
● セーフガードコピーのデータを保護して、偶発又は故意の侵害を防止する。
● 分散型格納システムのデバイスの番号とホストデバイスのアドレスは使用しないようにする。

セーフガードコピーは、データのポイント・イン・タイム・フル・ボリューム・スナップショットとは異なる場合があり、これは、本番ボリュームの即座にアクセス可能なコピーを提供し、各コピーは、データの観点から他から独立している。
［例示的なセーフガードコピー動作］

図５は、例示的な一態様による、例示的なセーフガードバックアップ構成５００を例示する。図示のように、セーフガードコピーは、本番ボリューム５０４（例えば、ソース／セーフガードソースなどの格納ボリューム）用の複数の回復ポイント５０２を作成する機能を提供する。これらの回復ポイント５０２は、セーフガードバックアップ（例えば、バックアップ／ＳＧバックアップ）と呼ばれる。一態様では、回復データは、別個の通常のボリュームではなく、セーフガードバックアップ容量（ＳＧＢＣ）と呼ばれるバックアップ格納スペース５０６に格納される。ホストからバックアップに直接アクセスすることはできない。バックアップが、分離された回復ボリューム５０８に回復された後でのみ、データを使用できる。

回復ポイント５０２が回復ボリューム５０８に復元されると、回復システム５１０を使用してアクセスすることができる。このシステムは、セキュリティ要件に応じて、本番システム５１２と同じであっても、なくてもよい。非同期データのコピー／ミラーリングを使用して、データを回復システム５１０から本番ボリューム５０４に復元してもよい。本番ボリューム５０４を、回復ボリューム５０８と同じ、又は異なる分散型データ格納システムに置いてもよい。

本番環境は、１つ又は複数の格納システム全体で数百又は数千のボリューム５０４から構成され得る。論理的破損保護の重要な態様は、バックアップの部分であるすべてのボリュームにわたって整合する回復ポイントを提供することである。これらの回復ポイントは整合性グループ（ＣＧ）と呼ばれる。
［例示的なバックアップ管理］

セーフガードコピーのバックアップを、意図的でない、又は意図的な改ざんから保護してもよい。例えば、ユーザは、分散型格納システム管理インターフェースを使用して、手動で作成、消去、又は回復することはできない。コピーサービスマネージャ（ＣＳＭ）のインスタンスを使用して、これらのタスクを遂行してもよい。ＣＳＭはセッション概念を使用して、完全な整合性グループを管理してもよい。

図６は、例示的な一態様による、例示的なＣＳＭセーフガードコピーセッション６００を例示する。図示のように、セッション６００は、複数のコピーセット６０６Ａ～Ｎを含む。バックアップする本番ボリュームごとに１つのコピーセットがある。複数のコピーセット６０６Ａ～Ｎのそれぞれは、関連するセーフガードバックアップ容量６０８Ａ～Ｎ（例えば、バックアップ格納スペース）を有する本番／ソース／格納ボリューム６０４Ａ～Ｎ及び回復ボリューム６０２Ａ～Ｎを含む。ＣＳＭは、セッション６００全体でバックアップ及び回復などのアクションを遂行する。ＣＳＭは、組み込みスケジューラを使用してこれらの動作を自動的に実行してもよい。

ＣＳＭは、バックアップのライフサイクルも管理する。バックアップの保持期間を指定でき、ＣＳＭは、保持期間後に必要とされないバックアップを自動的に期限切れに（削除）してもよい。こうして管理を簡素化し、確実なものにすることができ、セッション全体で整合性を確実に維持できるようになる。
［例示的なセーフガードバックアップ容量］

セーフガードバックアップ容量６０８Ａ～Ｎをシンプロビジョニングしてもよい。効率を改善するために、小さなエクステントを使用してもよい。既存のセーフガードバックアップが存在しない場合、セーフガードバックアップ容量は、ソースボリュームに関連付けられた純粋な仮想容量である。物理的な格納スペースは、バックアップの作成時に割り当てられ、当初のボリュームに上書きされたデータはバックアップに保存される。バックアップデータはトラック単位で保存される。

バックアップするボリュームごとに、セーフガードバックアップ容量の最大量を指定してもよい。指定された容量に達すると、最も古いバックアップが自動的に削除され、スペースが解放される。所与のボリュームに対してセーフガードバックアップが存在する限り、関連するセーフガードバックアップ容量の消去を防止してもよい。物理スペースで格納プールが不足すると、データがバックアップ用か本番用かに関係なく、分散型格納システムは、プール設定に従って通知を送信してもよい。セーフガード関係で使用されている格納プールの物理スペースを使い果たしたと判定された場合、セーフガードバックアップをマイクロコードによって自動的に削除してもよい（例えば、利用可能な物理スペースの量が閾値量未満になった場合など）。
［例示的なセーフガードコピーのバックアップ］

セーフガードコピーのバックアップが開始されると、分散型格納システムは整合性グループを作成する。本番ボリュームへの更新を追跡するために、メタデータとビットマップをセットアップする。バックアップのセットアップの後、分散型格納システムは、ホストＩ／Ｏによって上書きされるデータを、本番ボリュームから、セーフガードバックアップ容量内の整合性グループのログに記録された位置にコピーする。

次のバックアップが開始されると、分散型格納システムは以前のバックアップを閉じて、新しい整合性グループを作成してもよい。したがって、システムは、各バックアップを個別に維持する必要がない場合がある。特定の回復ポイントに復元するには、分散型格納システムは、回復するバックアップよりも新しいすべてのバックアップを必要とする。

整合性グループの作成による影響を最小限に抑えるには、セーフガードコピーのバックアッププロセスは次の３つの段階から構成される。
１．予約：この段階では、分散型格納システムは、新しいセーフガードバックアップを作成する準備をする。システムは必要なビットマップをセットアップし、セーフガードコピー容量でメタデータを準備する。また、それは、前回のバックアップから変更されたすべてのデータが整合性グループのログに格納されることを確認する。すべての準備が完了したら、実際の整合性グループの形成を行うことができる。
２．チェックイン：整合性グループを作成するには、分散型格納システムは、ＣＧ内のすべてのボリュームのすべての更新を短時間停止する必要がある。これは、拡張長期ビジー（ＥＬＢ）状態を提示することによって行われる。キャッシュ内のデータに整合性がある場合、影響を受けるすべてのボリュームの以前の整合性グループのログは閉じられているため、整合性もとれている。これより、分散型格納システムは、新しいバックアップの整合性グループのログにさらにバックアップデータを書き込む。
３．完了：分散型格納システムはＥＬＢを解除し、書き込み動作を続行できる。コピーサービスマネージャは、これらの段階を自動的に調和させて遂行し、ホスト動作への影響を最小限に抑える。
［例示的なセーフガードコピーの回復］

ユーザは、任意の回復ポイントを、分離された回復ボリュームに回復してもよい。このボリュームは、少なくとも本番ボリュームと同じ容量でなければならず、シンプロビジョニングされ得る。ユーザは、バックグラウンドコピーを使用して、又は使用せずに回復を遂行できる。ユーザは、限られた期間だけに回復されたデータが必要な場合は非コピーコマンドを、長期間使用することを意図している場合はコピーコマンドを、指定してもよい。ユーザは、ＣＳＭによってセーフガードコピーの回復を開始できる。

図７は、例示的な一態様による、例示的なセーフガードコピー構成７００を例示する。図示のように、セーフガードコピー構成７００は、本番ボリューム７０２（例えば、格納ボリューム）と、回復ボリューム７０４と、バックアップ格納スペース内に格納されている４つの回復ポイントを表す４つのセーフガードバックアップ（例えば、整合性グループのログのｔ１の７０６Ａ～ｔ４の７０６Ｄ、ただし、ｔ４が最新である）とを含む。一態様では、非コピーオプションを使用して、時刻ｔ２のポイントまで回復することができる。回復には以下の段階が含まれる。
１．分散型格納システムは、本番ボリューム７０２から回復ボリューム７０４へのデータのポイント・イン・タイム・スナップショットを確立する。これにより、回復ボリューム７０４が本番ボリューム７０２と同じになる。
２．次に、分散型格納システムは回復ビットマップ７０８を作成するが、これは、時刻ｔ２以降に変更されたすべてのデータを表しており、本番ボリューム７０２からではなく、整合性グループのログのｔ４の７０６Ｄ、ｔ３の７０６Ｃ、及びｔ２の７０６Ｂから参照されなければならない。

このポイントから、回復ボリューム７０４を使用して読み取り及び書き込みアクセスを遂行し得る。回復システム７１０が回復ボリューム７０４からデータを読み取る場合、分散型格納システムは回復ビットマップ７０８を検査し、要求されたデータを本番ボリューム７０２から、又は整合性グループのログのｔ１の７０６Ａ～ｔ４の７０６Ｄのうちの１つからフェッチしなければならないかを決定する。同じトラックが複数のバックアップに表示される場合、システムは「最も古い」インスタンス（回復ポイントｔ２の７０６Ｂに最も近いインスタンス）を使用してもよい。

回復システム７１０が回復ボリューム７０４に書き込む場合、２つのケースのうちの１つが起こり得る。
● 全トラック書き込み：分散型格納システムは、既存のデータを考慮せずに、回復ボリューム７０４に直接書き込むことができる。
● 部分トラック書き込み：分散型格納システムは、上記のルールに従って最初に既存のデータをフェッチしてから、更新を適用する必要がある。

バックグラウンドコピーで回復を遂行する場合、分散型格納システムは、同じルールに従って、本番ボリューム７０２及び整合性グループのログのｔ１の７０６Ａ～ｔ４の７０６Ｄからすべてのデータを回復ボリューム７０４にバックグラウンドでコピーする。バックグラウンドコピーが依然として実行中でも、いつでも回復ボリューム７０４にアクセスできる。

データを当初の本番ボリューム７０２に復元する場合、いくつかの選択肢が有効である。
● フルボリュームの復元：グローバルコピーを使用して、回復ボリューム７０４から本番ボリューム７０２にデータを複製してもよい。本番ボリューム７０２は、回復ボリューム７０４と同じ又は異なる分散型格納システム上にあってもよい。
● 選択的復元：本番ボリューム７０２を回復システム７１０が利用できるか、又は回復ボリューム７０４を本番システム７１２が利用できるかのいずれかである。次に、標準のオペレーティングシステム又はアプリケーションの方法を使用して、必要なデータを回復ボリューム７０４から本番ボリューム７０２にコピーしてもよい。

ここで図８を参照すると、一態様による方法８００のフローチャートが示されている。方法８００を、様々な態様のなかでも、とりわけ、図１～７及び１０に示される環境のいずれかで本発明に従って遂行してもよい。もちろん、本明細書を読めば当業者には理解されるように、図８に具体的に説明されている動作よりも多い又は少ない動作を方法８００に含めることができる。

方法８００の各段階を、動作環境の任意の好適な構成要素によって遂行してもよい。例えば、様々な態様で、方法８００を、１つ又は複数のサーバ、コンピュータ、又は１つ又は複数のプロセッサを内部に有する他の何らかのデバイスによって部分的又は全体的に遂行してもよい。ハードウェア若しくはソフトウェア又はそれらの組み合わせに実装され、好ましくは少なくとも１つのハードウェア構成要素を有するプロセッサ（例えば、処理回路、チップ、若しくはモジュール、又はそれらの組み合わせ）を任意のデバイスで利用して、方法８００の１つ又は複数の段階を遂行してもよい。例示的なプロセッサには、これらに限定されないが、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、それらの組み合わせ、又は当技術分野で知られている任意の他の好適なコンピューティングデバイスが含まれる。

図８に示すように、方法８００は動作８０２と共に開始することになり、ここで、格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求が受け取られる。一態様では、格納ボリュームを、相互接続された格納システム（例えば、分散型データ格納システムなど）内に備えてもよい。別の態様では、格納ボリュームを単一のデバイス内に備えてもよい（例えば、単一ディスクオペレーティングシステム（ＤＯＳ）内など）。さらに別の態様では、格納ボリュームは、１つ又は複数の有形格納ドライブを備えてもよい。

追加として、一態様では、バックアップ格納スペースを、格納ボリューム内のデータの論理的破損保護（ＬＣＰ）実装の部分として作成してもよい。例えば、ＬＣＰ実装は、格納ボリュームのデータバックアップ（例えば、回復ポイント）を作成してもよい。例えば、各データバックアップは、格納ボリューム内の所定のデータのポイント・イン・タイム・スナップショットを含んでもよい。別の例では、各データバックアップを、スナップショットが取られた特定の日時と関連付けてもよい。さらに別の例では、データバックアップを、所定のスケジュールに従って定期的に作成してもよい。

さらに、一態様では、ＬＣＰ実装は、回復ポイントをバックアップ格納スペースに格納してもよく、ここでは、格納ボリュームを利用するホストからバックアップ格納スペースにアクセスできない。別の態様では、格納ボリューム内の１つ又は複数のエラーの発生に応えて、回復ポイントを、格納ボリュームから分離された回復ボリュームに復元してもよい。さらに別の態様では、格納ボリュームを実装するシステムから分離された回復システムによって、回復ボリュームにアクセスしてもよい。その後、回復システムから格納ボリュームにデータを復元してもよい。

なおもさらに、一態様では、バックアップ格納スペースは、物理的に、若しくは論理的に、又はその両方により格納ボリュームから分離されたデータ格納を含んでもよい。別の態様では、バックアップ格納スペースを、格納ボリュームと同じ物理デバイス内に置いてもよい。さらに別の態様では、バックアップ格納スペースを、格納ボリュームとは異なる物理デバイス内に置いてもよい。さらに別の態様では、バックアップ格納スペースと格納ボリュームの両方は物理データ格納（例えば、１つ又は複数の有形データ格納ドライブなど）を備えてもよい。

また、一態様では、バックアップ格納スペースは、バックアップ容量、セーフガードバックアップ容量などとしても知られている場合がある。別の態様では、格納ボリュームは、ホストボリューム、本番ボリュームなどとしても知られている場合がある。さらに別の態様では、バックアップ格納スペースの初期サイズを、バックアップ格納スペースをＬＣＰ実装の部分として作成するときに判定してもよい。例えば、バックアップ格納スペースの初期サイズを、格納ボリュームのサイズの所定の倍数としてもよい。

さらに、一態様では、要求を、手動のユーザ要求に応えて受け取ってもよい。別の態様では、要求を、データバックアップの数、若しくは頻度、又はそれらの組み合わせを増加させるべきという判定に応えて受け取ってもよい。さらに別の態様では、要求を、バックアップ格納スペース、若しくは格納ボリューム、又はそれらの組み合わせのパラメータの監視に基づいて自動的に生成してもよい。

例えば、管理アプリケーションは、バックアップ格納スペース及び格納ボリュームのパラメータを監視してもよい。別の例では、パラメータは、容量使用量の閾値（例えば、現在使用されているバックアップ格納スペースの閾値量）を含んでもよい。さらに別の例では、パラメータは乗数の増分量（例えば、乗数を増加させる単位となる量など）を含んでもよい。

別の例では、パラメータは乗数の制限（例えば、許容される最大乗数など）を含んでもよい。さらに別の例では、乗数は、保護されるべき格納ボリュームのサイズに対するバックアップ格納スペースのサイズを表してもよい。例えば、格納ボリュームの乗数２は、そのような格納ボリュームのためのバックアップ格納スペースのサイズは格納ボリュームのサイズの２倍になることを表してもよい。

さらに別の例では、管理アプリケーションは、乗数の増分量だけ格納ボリュームのためのバックアップ格納スペースのサイズを増加させる要求を、現在使用されているバックアップ格納スペースの量が容量使用量の閾値を超えているという判定に応えて、自動的に生成してもよい。さらに別の例では、サイズ増加要求を、乗数の制限に達するまで、乗数の増分量により徐々に増加させてもよい。

さらに、方法８００は動作８０４に進むことになり、要求に応えて、追加エクステントをバックアップ格納スペースに追加する。一態様では、エクステントは、バックアップ格納スペースによって使用される有形データ格納ハードウェア内の所定のデータ格納位置を含んでもよい。別の態様では、エクステントは均一な所定のサイズを有してもよく、又はエクステントのサイズは異なっていてもよい。

なおもさらに、一態様では、バックアップ格納スペースを、所定の順序の一連の隣接するエクステントとして表してもよい。別の態様では、追加エクステントを、所定の順序の一連の隣接するエクステントの最後に追加してもよい。さらに別の態様では、追加エクステントを、バックアップ格納スペースによって使用される有形データ格納ハードウェア内に追加のデータ格納位置を割り当てることによって追加してもよい。

また、方法８００は動作８０６に進むことになり、バックアップ格納スペース内で現在のエクステント位置を識別する。一態様では、現在のエクステント位置は、次のデータバックアップをバックアップ格納スペース内に格納する位置を含んでもよい。別の態様では、現在のエクステント位置をローリングバッファ方式に従って判定してもよい。

例えば、バックアップ格納スペースは、所定の順序で配置された複数の隣接するエクステント位置を含んでもよい。現在のエクステント位置がデータバックアップで充満した後（例えば、データバックアップスケジュールなどによる）、所定の順序で次に隣接するエクステント位置が選択される。別の例では、ローリングバッファ方式は、バックアップ格納スペース内で、所定の順序での最後のエクステント位置がデータバックアップで充満していると、所定の順序での最初のエクステント位置が、次に充満するエクステント位置として選択されることを規定してもよい。これにより、バックアップ格納スペース内に循環バッファを作成することができる。

追加として、一態様では、エクステント位置を新しいデータバックアップで充満させるときに、エクステント位置は以前のデータバックアップで充満しているとの判定に応えて、以前のデータバックアップを削除／期限切れにして、新しいデータバックアップをエクステント位置に格納する。

さらに、方法８００は動作８０８に進むことになり、現在のエクステント位置とバックアップ格納スペースに追加された追加エクステントとの間に充満エクステント位置が存在するかどうかを判定する。一態様では、何らかの充満中間エクステントが存在するかどうかを判定してもよく、ここで、充満中間エクステントは、現在データバックアップを格納しているエクステントであって、現在のエクステント位置とバックアップ格納スペースに追加された最初の追加エクステント位置との間に所定の順序で置かれているエクステントを含んでいる。別の態様では、これらの充満中間エクステントは、現在のエクステント位置が、バックアップ格納スペースに追加された追加エクステントに到達する前に期限切れになることが必要になる場合がある。

なおもさらに、方法８００は動作８１０に進むことになり、バックアップ格納スペースに追加された追加エクステントを、判定に基づいて条件付きで利用する。一態様では、現在のエクステント位置と最初の追加エクステント位置との間に所定の順序で１つ又は複数の充満中間エクステントが存在することの識別に応えて、バックアップ格納スペースに、拡大状態にあるというラベルを付けてもよい。

例えば、バックアップ格納スペースに、バックアップ格納スペースのメタデータを調整すること、バックアップ格納スペース内に１つ又は複数のフラグを設定することなどによって、拡大状態にあるというラベルを付けてもよい。

また、一態様では、バックアップ格納スペースに、拡大状態にあるというラベルが付けられているとの判定に応えて、バックアップ格納スペースに追加された追加エクステントの使用を防止してもよく、（例えば、１人又は複数のユーザ、１つ又は複数のアプリケーションなどに）バックアップ格納スペースに追加された追加エクステントは使用する準備ができておらず、１つ又は複数の充満中間エクステントが期限切れになった後にのみ使用できることの通知を送ってもよい。別の態様では、期限切れになることが必要になる充満中間エクステントをユーザに提示してもよく、充満中間エクステントを手動で期限切れにするオプションをユーザに与えてもよい。

追加として、一態様では、また、バックアップスケジュールとローリングバッファ方式に従って、充満中間エクステントを期限切れにするオプションをユーザに与えてもよい（例えば、新しいデータバックアップが、中間エクステント内に格納されたデータバックアップに取って代わるときなど）。別の態様では、すべての充満中間エクステントが期限切れになったと判定されると、拡大状態ラベルをバックアップ容量から削除してもよい。

さらに、一態様では、バックアップ容量に、拡大状態にあるというラベルが付けられていない（例えば、フラグが設定されていない／現在のエクステント位置と最初の追加エクステント位置との間に１つ又は複数の充満中間エクステントが存在しない）との判定に応えて、バックアップ格納スペースに追加された追加エクステントの使用を可能にしてもよく、追加エクステントを使用する準備ができていることの通知を１人又は複数のユーザに送ってもよい。別の態様では、その後、追加エクステントを使用して、バックアップ格納スペースの当初のエクステントと共に、ローリングバッファ方式に従ってデータバックアップを格納してもよい。

なおもさらに、一態様では、単一のセーフガード容量セッション内の複数の異なる格納ボリュームに対して、複数の異なるバックアップ格納スペースが存在してもよい。例えば、充満中間エクステントは、複数のバックアップ格納スペースのそれぞれについて識別されてもよく、上記で示したように、バックアップ格納スペースに追加された追加エクステントの使用に影響を与える可能性もある。

また、一態様では、上記の動作のすべてを、格納ボリュームを含む有形システムの１つ又は複数によって、格納ボリューム自体によって、又は格納ボリュームから分離されたシステムによって遂行してもよい。

このように、格納ボリュームのためのバックアップ格納スペースのサイズを増加させてもよく、最初にバックアップ格納スペース全体（及び格納されているすべてのデータバックアップ）を消去して新しいサイズで新しいバックアップ格納スペースを構築する必要はない。これにより、バックアップ格納スペースを拡大するために必要な処理量を削減でき、このような拡大を実装する１つ又は複数の有形コンピューティングデバイスの性能を改善することができる。

追加として、バックアップ格納スペースに追加エクステントを追加している間、バックアップ格納スペースの当初のエクステントへのアクセスは引き続き許可され得る。これにより、定期的なデータボリュームのバックアップの格納が可能になることがあり、バックアップ格納スペースの拡大中に、ＬＣＰ実装が格納ボリューム内のデータに引き続き適用されていることが確実になり得る。その結果、格納ボリューム内のデータを、バックアップ格納スペースの拡大中にデータの破損／消失から保護できるようになり、これにより、データの消失を防止し、格納ボリュームを利用する１つ又は複数の有形コンピューティングデバイスの性能をさらに改善することができる。

ここで図９を参照すると、一態様による、バックアップ格納スペースの管理を自動化するための方法９００のフローチャートが示されている。方法９００を、様々な態様のなかでも、とりわけ、図１から図７及び図１０に示される環境のいずれかで本発明に従って遂行してもよい。もちろん、本明細書を読めば当業者には理解されるように、図９に具体的に説明されている動作よりも多い又は少ない動作を方法９００に含めることができる。

方法９００の各段階を、動作環境の任意の好適な構成要素によって遂行してもよい。例えば、様々な態様で、方法９００を、１つ又は複数のサーバ、コンピュータ、又は１つ又は複数のプロセッサを内部に有する他の何らかのデバイスによって部分的又は全体的に遂行してもよい。ハードウェア若しくはソフトウェア又はそれらの組み合わせに実装され、好ましくは少なくとも１つのハードウェア構成要素を有するプロセッサ（例えば、処理回路、チップ、若しくはモジュール、又はそれらの組み合わせ）を任意のデバイスで利用して、方法９００の１つ又は複数の段階を遂行してもよい。例示的なプロセッサには、これらに限定されないが、中央処理装置（ＣＰＵ）、特定用途向け集積回路（ＡＳＩＣ）、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）など、それらの組み合わせ、又は当技術分野で知られている任意の他の好適なコンピューティングデバイスが含まれる。

図９に示すように、方法９００は動作９０２と共に開始することになり、ここでは、格納ボリュームのためのバックアップ格納スペースの現在の使用量が監視される。一態様では、バックアップ格納スペースの現在の使用量を監視する段階は、現在データバックアップで充満しているバックアップ格納スペース内のエクステント位置の合計数を判定する段階を含んでもよい。別の態様では、現在の使用量は、現在データバックアップで充満しているエクステント位置の合計割合を含んでもよい。

追加として、方法９００は動作９０４に進むことになり、現在の使用量を容量閾値と比較する。一態様では、容量閾値を、バックアップ格納スペース用の複数のパラメータのうちの１つとしてメタデータに格納してもよい。別の態様では、パラメータは、容量使用量の閾値（例えば、現在使用されているバックアップ格納スペースの閾値量）を含んでもよい。

さらに、方法９００は動作９０６に進むことになり、比較及び所定のサイズ制限に基づいて、バックアップ格納スペースのサイズを条件付きで増加させる。一態様では、バックアップ格納スペースのパラメータはまた、乗数の増分量（例えば、乗数を増加させる単位となる量など）を含んでもよい。別の態様では、パラメータは、乗数の制限などの所定のサイズ制限（例えば、バックアップ格納スペース内で許容される最大乗数など）を含んでもよい。

なおもさらに、一態様では、乗数は、保護されるべき格納ボリュームのサイズに対する、作成されるべきバックアップ格納スペースのサイズを表してもよい。例えば、格納ボリュームの乗数２は、そのような格納ボリュームのためのバックアップ格納スペースのサイズは格納ボリュームのサイズの２倍になることを表してもよい。別の態様では、格納ボリュームのためのバックアップ格納スペースのサイズを乗数の増分量だけ増加させる要求を、現在の使用量が容量閾値を超えているとの判定に応えて、自動的に生成してもよい。時間の経過とともに、サイズ増加要求を、乗数の制限に達するまで乗数の増分量によって徐々に増加させてもよい。

このように、バックアップ格納スペースのサイズを、格納ボリュームに合わせて動的に調整してもよい。これにより、バックアップ格納スペースは確実に、ＬＣＰ実装の部分として格納ボリュームのための十分な数のデータバックアップをサポートするのに十分な大きさになる。その結果、データの破損／消失からの格納ボリュームのデータ保護を確実にすることができ、格納ボリュームを利用する１つ又は複数の有形コンピューティングデバイスの性能をさらに改善することができる。

図１０は、例示的な一態様による、例示的な拡大格納環境１０００を例示する。図示のように、バックアップ格納スペース１００２は、格納ボリューム１００４にバックアップ格納を提供する。例えば、バックアップ格納スペース１００２は、格納ボリューム１００４内のデータのための論理的破損保護（ＬＣＰ）実装の部分として作成されてもよい。

追加として、定期的に、データバックアップを格納ボリューム１００４に対して作成してもよく、バックアップ格納スペース１００２の当初のエクステント１００６Ａ～Ｅの１つに格納してもよい。当初のエクステント１００６Ａ～Ｅは、最初の当初のエクステント１００６Ａから最後の当初のエクステント１００６Ｅまでの所定の順序で並んでいてもよく、ローリングバッファ方式に従って充満させられてもよい。例えば、追加エクステント１００８Ａ～Ｄを追加する前、最初の当初のエクステント１００６Ａがデータバックアップで充満した後（例えば、バックアップスケジュール等に従って）、次の隣接する当初のエクステント１００６Ｂを、所定の順序に従って充満させるように選択する。

さらに、ローリングバッファ方式は、バックアップ格納スペース１００２内で、所定の順序での最後の当初のエクステント１００６Ｅがデータバックアップで充満した後、所定の順序での最初の当初のエクステント１００６Ａが、次に充満するエクステント位置として選択されることを規定してもよい。

また、バックアップ格納スペース１００２のサイズを増加させる要求に応えて、追加エクステント１００８Ａ～Ｄをバックアップ格納スペース１００２に追加してもよい。一態様では、追加エクステント１００８Ａ～Ｄがバックアップ格納スペースに追加されたことに応えて、現在のエクステント１００６Ｃを、バックアップ格納スペース１００２内で判定してもよい。

なおもさらに、次に、中間エクステント１００６Ｄ及び１００６Ｅは、現在のエクステント１００６Ｃと、バックアップ拡大部１０１０の最初の追加エクステント１００８Ａとの間に存在することを判定してもよい。また、これらの中間エクステント１００６Ｄ及び１００６Ｅは充満しており、追加エクステント１００８Ａ～Ｄをバックアップ格納スペース１００２内で使用する前に期限切れになることが必要になることを判定してもよい。充満中間エクステント１００６Ｄ及び１００６Ｅの識別に応えて、バックアップ格納スペース１００２に、拡大状態にあるというラベルを付けてもよい。

バックアップ格納スペース１００２に、拡大状態にあるというラベルが付けられているとの判定に応えて、追加エクステント１００８Ａ～Ｄの使用を防止してもよく、追加エクステント１００８Ａ～Ｄは使用する準備ができておらず、充満中間エクステント１００６Ｄ及び１００６Ｅが期限切れになった後にのみ使用できることの通知を送ってもよい。

ユーザに、充満中間エクステント１００６Ｄ及び１００６Ｅを手動で期限切れにするオプションを与えてもよい。また、ユーザに、先在のデータバックアップスケジュール及びローリングバッファ方式に従って、充満中間エクステント１００６Ｄ及び１００６Ｅを期限切れにするオプションを与えてもよい。

充満中間エクステント１００６Ｄ及び１００６Ｅが期限切れになったと判定されると、拡大状態ラベルを、バックアップ格納スペース１００２から削除してもよい。バックアップ格納スペース１００２に、拡大状態にあるというラベルが付けられていないとの判定に応えて、追加エクステント１００８Ａ～１００８Ｄの使用を可能にしてもよく、追加エクステント１００８Ａ～１００８Ｄを使用する準備ができていることの通知を１人又は複数のユーザに送ってもよい。

その後、追加エクステント１００８Ａ～１００８Ｄを使用して、バックアップ格納スペース１００２の部分として当初のエクステント１００６Ａ～１００６Ｅと共に、ローリングバッファ方式に従ってデータバックアップを格納してもよい。
［セーフガード容量拡大］

セーフガードコピー（ＳＧＣ）の実行中、ユーザがバックアップの数を増加させることを必要とする場合があり、その場合はセーフガード容量を増加させる必要がある。

ただし、セーフガード容量を増加させるプロセスでは、セーフガードバックアップを削除し、セーフガードバックアップボリュームを消去する必要がある。その後、ユーザは、セーフガードバックアップボリュームを新しい所望のサイズに作成し、セーフガードバックアップを再開する必要がある。追加として、バックアップ上のユーザデータのレイアウトは複雑であるため、セーフガードバックアップボリュームを増加させるだけでは、新しいスペースをすぐに使用することはできない。

それに応えて、更新された設計により、ユーザは１つのコマンドを発行してセーフガード容量を増加させることができ、新しいスペースが使用可能になるとユーザに通知される。ユーザは、新しいスペースが使用可能になるときの通知を待っている間も、セーフガードセッションを実行し続けることができる。

ＳＧＣはローリングバッファメカニズムを使用して、トラック（顧客とメタデータ）をバックアップボリュームにコピーする。これにより、バックアップボリューム上で各セーフガードバックアップが連続的に維持される。ボリュームの最後に新しいスペースを追加した後、新しいスペースを使用すると、セーフガードバックアップがラップアラウンドケース内にある場合、トラックとバックアップが散在的になる可能性がある。

新しい設計では、拡大コマンドを実行し、バックアップボリュームのサイズを増加させることができる。ＳＧＣは、セーフガードバックアップボリュームがラップアラウンドケース内に入らなくなるまで、新しい拡大領域を使用しない。拡大コマンドの間は下記のようになる。
● セーフガードバックアップボリュームがラップアラウンドケース内にある場合、拡大状態にあることを示すフラグがセーフガードボリュームに設定される。拡大された容量は使用されない。
● セーフガードバックアップボリュームがラップアラウンドケース内にない場合、フラグは設定されず、セーフガードボリュームを将来のバックアップに使用する準備ができているという通知が、ＮＩ（例えば、情報／イベントをユーザに報告するシステム構成要素）に送られる。

拡大中の状態の間、バックアップ関係クエリは、新しい拡大領域を使用するために期限切れにする必要があるバックアップを示し、ボリューム格納ステータスクエリは、セーフガードボリュームが拡大中の状態にあるかどうかを示す。ひとたび、すべてのバックアップが期限切れになり、拡大中の状態から抜けると、通知がＮＩに送られ、セーフガード拡大領域を使用する準備ができたことをユーザに知らせる。バックアップ関係クエリとボリューム格納ステータスクエリは「拡大中の状態」を表示しない。
［セーフガードコピー仮想容量の管理の自動化］

作業負荷とホストは様々であるため、セーフガード（ＳＦＧ）セッション内のいくつかのボリュームでは、ＳＦＧボリュームに２から３の倍数の仮想容量しか必要としない場合がある。ＳＦＧセッション内のいくつかのボリュームでは、ＳＦＧボリュームに９から１０の倍数の仮想容量が必要になる場合がある。ＳＦＧソースボリュームへのデータ量も時間とともに変化する可能性がある。

乗数の値を手動で管理することは、多くのＳＦＧボリュームを監視するために、不可能ではないにしても難しい場合がある。その結果、プロセスを自動化する方法は、大規模なセーフガード環境を有するユーザにとって役立つ場合がある。

一態様では、ボリュームの仮想容量のパラメータを監視してもよく、そのようなパラメータの値によっては、必要なときにセーフガードボリュームを自動的に拡大してもよい。

すべてのボリュームに大幅に高い値を設定する必要性を避けるために、異常値ボリュームのための増加を自動的に／動的に調整して、仮想容量の不足によりバックアップが期限切れになり始める前に事前に値を増加させてもよい。これにより、増加が有効になる前に期限切れになるいくらかのバックアップを削減又は排除さえもできる場合がある。

一態様では、監視されるパラメータは（格納ボリューム／対応するバックアップ格納スペース毎に）以下のものを含んでもよい。
● 容量使用量の閾値－これ以上になると乗数を増加させるときの容量の割合
● 乗数の増分－乗数を増加させるときの増分－％又は整数が想定される
● 乗数の制限－許容される最大乗数

所定の間隔又はイベントに従って、現在の環境を（格納ボリューム／対応するバックアップ格納スペース毎に）、次のように監視してもよい。
１．容量使用量の閾値を超えるボリュームがあるかどうかを判定する
２．閾値を超えるボリュームがある場合、乗数が乗数の制限を下回っているかどうかを点検する
３．乗数が乗数の制限を下回っている場合、バックアップ容量の乗数（バックアップ格納スペースのサイズを、対応する格納ボリュームの倍数として規定する乗数）を徐々に増加させるが、場合によっては増分が複数になる

１つの例示的な実装は以下の通りである。

例示的な格納ボリューム及び対応するバックアップ格納スペースの現在のパラメータは以下を含む。
● 容量使用量の閾値は５０％である
● 乗数の増分は１である
● 乗数の制限は６である
● 各バックアップは約１ＧＢのデータである。

そのような格納ボリューム／対応するバックアップ格納スペースの例示的な管理は、以下を含む（本番ボリュームのサイズに関する知識が既にあることを仮定している）。
１．現在のバックアップ容量の乗数は３である。
２．セーフガードバックアップ１と２が作成される。
３．パラメータを監視して、仮想容量使用量が５０％に達していることを認識する。
Ａ．拡大コマンドを発行して、バックアップ容量を４に増加させる。進行中の拡大状態はない。
Ｂ．現在のバックアップ容量の乗数は４である。
４．セーフガードバックアップ３～８が作成される。現在、バックアップ１～５は内部的に期限切れになっている。
５．パラメータを監視して、仮想容量使用量が５０％に達していることを認識する。
Ａ．拡大コマンドが発行されて、バックアップ容量を５に増加させる。拡大状態を進行中に設定。
Ｂ．現在のバックアップ容量の乗数は５である。
６．セーフガードバックアップ９～１０が作成される。現在、バックアップ６～７は内部的に期限切れになっている。
Ａ．バックアップ７の期限切れの後、進行中の拡大状態はない。
７．セーフガードバックアップ１１～１３が作成される。現在、バックアップ７～９は内部的に期限切れになっている。
８．パラメータを監視して、仮想容量使用量が５０％に達していることを認識する。
Ａ．拡大コマンドを発行して、バックアップ容量を６に増加させる。進行中の拡大状態はない。
Ｂ．現在のバックアップ容量の乗数は６である。９．バックアップの作成を続行する。このポイントの後、乗数の制限に達したため、バックアップ容量を増加させることができなくなる。

新しいパラメータは、セーフガード管理ソフトウェア（例えば、ＣＳＭ、ＧＤＰＳなど）で設定されたポリシである場合がある。ポリシはセーフガードセッションをカバーできる。ボリュームの作業負荷が安定している既存の環境用の新しいセーフガードコピーの実装では、ログのバッファが仮想容量を循環（ラップアラウンド）する前に、バックアップ乗数の増加が生じる可能性がある。

ボリュームの作業負荷が徐々に増加する場合は、十分に低い容量使用量の閾値であれば、乗数は増加し、仮想容量が使い果たされる前に有効になる。非アクティブなボリュームで作業負荷が大幅に増加したことを急に認識する場合、乗数の増加が限られた期間有効になる前に、１つ又は複数のバックアップが期限切れになる場合がある。

一態様では、自動化されたバックアップコピーボリュームの拡大を遂行する方法が提供され、この方法は、容量使用量の閾値、乗数の増分、及び乗数の制限をバックアップコピーシステムの格納管理ソフトウェア内に構成する段階を含む。追加として、この方法は、バックアップコピーボリュームが容量使用量の閾値を超えていると判定する段階を含む。

さらに、この方法は、バックアップコピーボリュームの乗数が乗数の制限を下回っていることを判定する段階を含む。なおもさらに、この方法は、拡大コマンドを発行して、乗数の増分だけバックアップ容量を増加させる段階を含む。また、この方法は、古いバックアップコピーボリュームを内部的に期限切れにする段階を含む。

本発明は、任意の可能な技術的詳細レベルで統合化されたシステム、方法、若しくはコンピュータプログラム製品又はそれらの組み合わせであってもよい。コンピュータプログラム製品は、プロセッサに本発明の態様を実施させるためのコンピュータ可読プログラム命令を有するコンピュータ可読格納媒体を含んでもよい。

コンピュータ可読格納媒体は、命令実行デバイスによる使用のために命令を保持及び格納することができる有形デバイスとすることができる。コンピュータ可読格納媒体は、例えば、電子格納デバイス、磁気格納デバイス、光学格納デバイス、電磁格納デバイス、半導体格納デバイス、又は上述のものの任意の好適な組み合わせであってもよいが、これらに限定されない。コンピュータ可読格納媒体のより具体的な例の非包括的なリストは、ポータブルコンピュータディスケット、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、リードオンリメモリ（ＲＯＭ）、消去可能プログラマブルリードオンリメモリ（ＥＰＲＯＭ又はフラッシュメモリ）、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ポータブルコンパクトディスクリードオンリメモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ）、メモリスティック、フロッピディスク、パンチカード又は命令が記録されている溝内の隆起構造などの機械的にエンコードされたデバイス、及び、上述のものの任意の好適な組み合わせを含む。コンピュータ可読格納媒体は、本明細書において使用される場合、電波若しくは他の自由に伝搬する電磁波、導波路若しくは他の伝送媒体を通じて伝搬する電磁波（例えば、光ファイバケーブルを通過する光パルス）、又はワイヤを通じて伝送される電気信号等の一過性の信号それ自体とは解釈されるべきではない。

本明細書に記載されるコンピュータ可読プログラム命令は、コンピュータ可読格納媒体からそれぞれのコンピューティング／処理デバイスにダウンロードされてもよく、あるいは、ネットワーク、例えば、インターネット、ローカルエリアネットワーク、ワイドエリアネットワーク、若しくは無線ネットワーク、又はその組み合わせを介して、外部コンピュータ又は外部格納デバイスにダウンロードされてもよい。ネットワークは、銅伝送ケーブル、光伝送ファイバ、無線伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイコンピュータ、若しくはエッジサーバ、又はその組み合わせを備え得る。各コンピューティング／処理デバイスにおけるネットワークアダプタカード又はネットワークインタフェースが、ネットワークからコンピュータ可読プログラム命令を受け取り、それらのコンピュータ可読プログラム命令を、それぞれのコンピューティング／処理デバイス内のコンピュータ可読格納媒体への格納のために転送する。

本発明の動作を実行するコンピュータ可読プログラム命令は、アセンブラ命令、命令セットアーキテクチャ（ＩＳＡ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、集積回路の構成データであってもよく、Ｓｍａｌｌｔａｌｋ（登録商標）又はＣ＋＋等のようなオブジェクト指向プログラミング言語、及び「Ｃ」プログラミング言語又は同様のプログラミング言語のような手続き型プログラミング言語を含む１つ又は複数のプログラミング言語の任意の組み合わせで記述したソースコード又はオブジェクトコードであってもよい。コンピュータ可読プログラム命令を、スタンドアロンのソフトウェアパッケージとして、全体的にユーザのコンピュータ上で、部分的にユーザのコンピュータ上で、部分的にユーザのコンピュータ上かつ部分的に遠隔のコンピュータ上で、又は、全体的に遠隔のコンピュータ若しくはサーバ上で実行することができる。後者のシナリオでは、遠隔のコンピュータは、ローカルエリアネットワーク（ＬＡＮ）若しくはワイドエリアネットワーク（ＷＡＮ）を含む任意の種類のネットワークを介してユーザのコンピュータに接続されてもよく、又はその接続は、外部コンピュータに対して（例えば、インターネットサービスプロバイダを使用してインターネットを介して）行われてもよい。いくつかの態様では、例えば、プログラム可能論理回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ）又はプログラマブル論理アレイ（ＰＬＡ）を含む電子回路機器は、本発明の態様を実行するために、コンピュータ可読プログラム命令の状態情報を利用して電子回路をパーソナライズすることによって、コンピュータ可読プログラム命令を遂行することができる。

本発明の態様は、本明細書において、本発明の態様よる方法、装置（システム）、及びコンピュータプログラム製品のフローチャート図若しくはブロック図又はその両方を参照して説明される。フローチャート図若しくはブロック図又はその両方の各ブロックと、フローチャート図若しくはブロック図又はその両方のブロックの組み合わせとは、コンピュータ可読プログラム命令により実装され得ることを理解されるだろう。

これらのコンピュータ可読プログラム命令を、コンピュータのプロセッサ、又はマシンを生成するための他のプログラマブルデータ処理装置に提供し、こうすることで、コンピュータのプロセッサ又は他のプログラマブルデータ処理装置を介して実行される命令が、フローチャート若しくはブロック図又はその組み合わせにおける１つ又は複数のブロックにおいて指定された機能／動作を実装する手段を作成するようにしてもよい。これらのコンピュータ可読プログラム命令を、コンピュータ、プログラム可能なデータ処理装置若しくは他のデバイス又はその組み合わせを特定の様式で機能するよう方向付けることができる、コンピュータ可読格納媒体に格納することで、命令を格納したコンピュータ可読格納媒体が、フローチャート若しくはブロック図又はその両方の１つ又は複数のブロックで指定された機能／行為の態様を実装する命令を含む製造品を備えるようにしてもよい。

また、コンピュータ可読プログラム命令は、コンピュータ、他のプログラマブルデータ処理装置、又は、他のデバイスにロードして、コンピュータ、他のプログラマブル装置、又は、他のデバイス上で一連の動作段階を遂行させることでコンピュータ実装プロセスを作ることもでき、これにより、コンピュータ、他のプログラマブル装置、又は、他のデバイス上で実行される命令が、フローチャート若しくはブロック図の、又はこれらの両方の１つ又は複数のブロックで指定される機能／動作を実装するようになる。

図中のフローチャート及びブロック図は、本発明の様々な態様によるシステム、方法、及びコンピュータプログラム製品の可能な実装のアーキテクチャ、機能、及び動作を例示している。この点で、フローチャート又はブロック図の各ブロックは、モジュール、セグメント、又は命令の一部を表すことができ、これらは、指定された論理機能を実装するための１つ又は複数の実行可能命令を含んでいる。いくつかの代替的実装では、ブロックに記載されている機能は、図に記載されている順序とは異なる順序で行われる場合がある。例えば、連続して示されている２つのブロックが、実際には、１つの段階として実現されてもよく、同時に、実質的に同時に、部分的に若しくは全体的に時間重複する様式で実行されてもよく、又は、ブロックは、場合によっては、関与する機能に依存して逆の順序で実行されてもよい。ブロック図若しくはフローチャート図又はその組み合わせの各ブロック、及び、ブロック図若しくはフローチャート図又はその組み合わせにおけるブロックの組み合わせが、指定された機能若しくは動作を遂行する、又は特定用途向けハードウェア及びコンピュータ命令の組み合わせを実施する、特定用途向けハードウェアベースのシステムによって実装され得ることにも留意されたい。

また、様々な態様によるシステムは、プロセッサと、プロセッサと統合された、若しくはプロセッサによって実行可能な、又はその両方の論理とを含むことができ、その論理は本明細書に記載のプロセス段階のうちの１つ又は複数を遂行するように構成されている。「～と統合された」は、プロセッサには、特定用途向け集積回路（ＡＳＩＣ）、ＦＰＧＡなどのハードウェア論理として論理が埋め込まれていることを意味する。「プロセッサによって実行可能」は、論理が、ハードウェア論理であること、ファームウェア、オペレーティングシステムの部分、アプリケーションプログラムの部分などのソフトウェア論理であること、その他、又はプロセッサによってアクセス可能であり、プロセッサによる実行時にプロセッサにいくつかの機能を遂行させるように構成されたハードウェア及びソフトウェア論理の何らかの組み合わせであることを意味している。当技術分野で知られているように、ソフトウェア論理は、任意のメモリ形式のローカル若しくはリモートメモリ又はそれらの組み合わせに格納され得る。ＡＳＩＣ、ＦＰＧＡ、中央処理ユニット（ＣＰＵ）、集積回路（ＩＣ）、グラフィックス処理装置（ＧＰＵ）などのソフトウェアプロセッサモジュール若しくはハードウェアプロセッサ又はその組み合わせなど、当技術分野で知られている任意のプロセッサを使用してもよい。

前述のシステム若しくは方式又はその組み合わせのさまざまな特徴を、上記に提示された説明による複数の組み合わせを作成しながら、いかなる様式にでも組み合わせてよいことは明確であろう。

さらに、本発明の態様は、オンデマンドでサービスを提供するために、顧客のために展開されるサービスの形態で提供されてもよいことが理解されるだろう。

本発明の様々な態様の説明は例示の目的で提示されており、網羅的であることも、開示された態様に限定されることも意図していない。説明された態様の範囲から逸脱することなく、多くの修正及び変形が当業者には明らかであろう。本明細書において使用される用語は、態様の原理、実用的な適用、若しくは市場で見られる技術に対する技術的改善を最もよく説明するために、又は当業者が本明細書に開示された態様を理解できるようにするために、選ばれた。

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. バックアップ格納スペースの管理を自動化するためのコンピュータプログラムであって、具現化されたプログラム命令を備えており、前記プログラム命令はプロセッサによって、前記プロセッサに方法を遂行させるように実行可能であり、前記方法は、
    格納ボリュームのためのバックアップ格納スペースの現在の使用量を、前記プロセッサによって監視する段階と、
    前記現在の使用量を容量閾値と、前記プロセッサによって比較する段階と、
    前記比較する段階及び所定のサイズ制限に基づいて、前記バックアップ格納スペースのサイズを、前記プロセッサによって条件付きで増加させる段階とを含んでいる、コンピュータプログラム。

Images