JP2008251010A - 除去 - Google Patents

Abstract

【課題】シングルインスタンスデータアーカイブ環境および/またはバックアップ環境からのデータの除去を可能にする。
【解決手段】すべての参照が除去されたデータオブジェクトのみが実際にストアから除去されることを保証するようなやり方で、シングルインスタンスデータオブジェクトストアからデータオブジェクトを除去することを可能にするシステム、方法、および装置を提供することができる。したがって、ストレージの整合性と信頼性を維持できると同時に、本当に削除する必要のあるデータオブジェクトをストアから除去することができる。
【選択図】図6

Description

本発明は、除去(removal)に関する。より詳細には、これに限定されないが、シングルインスタンス(single instancing)データアーカイブ環境および/またはバックアップ環境からのデータの除去に関する。

データアーカイブおよび/またはバックアップ環境では、しばしばアーカイブ/バックアップシステム内に多くのデータオブジェクトを格納する必要がある。こうしたデータオブジェクトは、特定の期間の間、またはある種の事柄が完了するまで保存する必要がある。場合によっては、規制条項により、特定の最小期間にわたってすべてのドキュメントの保存が必要なこともある。こうした規制要件(regulatory requirement)の例には、2002年の米国サーベンスオクスリー法(US Sarbanes-Oxley Act)に示されたデータ保持要件(data retention requirement)がある。

いくつかのデータアーカイブおよび/またはバックアップシステムでは、ファイルに対してシングルインスタンス処理(single instance processing)を行うことにより、システムが同じドキュメントの複数のコピーを無駄に記憶するのを防止することができる。したがって、アーカイブシステム/バックアップシステムに格納された単一のドキュメントは、異なる時にいくつかの異なるソースから発生している可能性がある。

いくつかのデータアーカイブおよび/またはバックアップシステムでは、大きなファイルはサイズの等しい多くの単位(一般にセグメントとして知られる)に分割される。したがって、すでにアーカイブ/バックアップされているファイルにデータが添付されるとき、その後のアーカイブ/バックアップ操作では、その新しいデータに対応するセグメントのみを作成する必要がある。

本発明は、少なくとも一部には、従来のシステムの欠点および制限を考慮してなされた。

したがって、すべての参照が除去されたデータオブジェクトのみが実際にストアから除去されることを保証するようなやり方で、シングルインスタンスデータオブジェクトストアからデータオブジェクトを除去することを可能にするシステム、方法、および装置を提供することができる。したがって、ストレージの整合性および信頼性を維持できると同時に、本当に削除する必要のあるデータオブジェクトをストアから除去することができる。

第1の態様の観点から見ると、本発明はシングルインスタンスストレージスキーマを使用してファイルまたはファイルセグメントを格納するように動作可能なバックアップシステムを提供する。バックアップシステムは、ファイルに関連するメタデータを格納するように動作可能なメタデータストアを備えることができ、ストア内の各メタデータストアエントリには、そのエントリが関連するファイルから計算された、そのファイルのコンテンツ(contents)に固有のフィンガープリント(fingerprint)が含まれる。バックアップシステムは、さらにメタデータストアエントリ内で識別されるファイルに属する、セグメントから計算された、そのセグメントのコンテンツに固有のフィンガープリントを使用して識別できるファイルセグメントを格納するように動作可能であり、また、メタデータストアエントリ内で識別されるファイルを説明し、説明するファイルに固有のフィンガープリントを使用して識別できるデータオブジェクトを格納するように動作可能なコンテンツストアをさらに備えている。データオブジェクトは、ファイルの各セグメントのセグメントフィンガープリントを含むリストを備えることができる。コンテンツストアは、ストア内に格納されたセグメントおよびデータオブジェクトに対するアクションを、コンテンツストアアクションキューによってこうしたアクションの実行命令を受信した系列順に実行するように動作可能なものとすることができる。バックアップシステムは、削除するファイルを識別し、削除するファイルのメタデータストアエントリにマーク付けし、このファイルのメタデータストアエントリへの参照をデータオブジェクトから除去し、マーク付けされたメタデータストアエントリをメタデータストアから削除するように動作可能なものとすることができる。したがって、シングルインスタンスストアは信頼性の高い安全なデータ保持ポリシーを運用し、格納されたデータを保護すると同時に、保持する必要がなくなったデータを削除することができる。

いくつかの実施例では、各データオブジェクトは複数のファイルを説明でき、説明する各ファイルのフィンガープリントを使用して識別できる。このように、唯一のエンティティを使用して、シングルインスタンスファイルシステム内にあるファイルセグメントの複数のソースファイルに対する連続的な関連性を追跡できる。

いくつかの実施例では、データオブジェクトからメタデータストアエントリへの参照を除去した結果として、データオブジェクトが説明するファイルがなくなった場合に、システムはデータオブジェクトも削除できる。このようにして、不要になったファイルの識別子をストレージから完全に除去することができる。いくつかの実施例では、システムはコンテンツストアアクションキューの最後にデータオブジェクトの削除命令を追加し、データオブジェクトを隠し、削除命令がコンテンツストアアクションキューの先頭に到達したとき、削除命令が命令キューに追加された後でデータオブジェクトが書き込みアクションの対象となったかどうかを判定するために検査し、そうした書き込みアクションが実行されなかった場合にデータオブジェクトを削除することによってデータオブジェクトの削除を実行するように動作可能なものとすることができる。したがって、データオブジェクトの削除は、完全なデータ保全性を維持するために、データオブジェクトが削除の対象として識別された後で、しかし削除のキューに入る前に、データオブジェクトに関する命令によってデータオブジェクトの削除が確実に防止されるような方法で実行できる。

いくつかの実施例では、システムは、データオブジェクトからファイルのメタデータストアエントリへの参照を除去した後に、データオブジェクトで説明されるいずれのファイルにも関連しなくなったセグメントへのリンクをデータオブジェクトから除去できる。このようにして、データオブジェクト内で識別されたいずれのファイルでも不要になったセグメントは、データオブジェクトからのリンクを解除することによってこうしたセグメントとデータオブジェクトとの関連がないことを示すことができる。

いくつかの実施例では、システムは、データオブジェクトからセグメントリンクを除去した後に、セグメントに現在リンクしているデータオブジェクトがない場合はそのセグメントを除去するように動作可能なものとすることができる。こうして、いずれのデータオブジェクトにもリンクしなくなったセグメント、したがって、ストレージ内のいずれのファイルにも連続的な関連がなくなったセグメントを完全に除去することができる。いくつかの実施例では、セグメントの除去は、コンテンツストアアクションキューの最後にセグメントの削除命令を追加し、セグメントを隠し、削除命令がコンテンツストアアクションキューの先頭に到達したとき、削除命令が命令キューに追加された後でセグメントが書き込みアクションの対象となったかどうかを判定するために検査し、そうした書き込みアクションが実行されなかった場合にセグメントを削除することによって実行できる。したがって、セグメントの削除は、完全なデータ保全性を維持するために、セグメントが削除の対象として識別された後で、しかし削除のキューに入る前に、セグメントに関する命令によってセグメントの削除が確実に防止されるような方法で実行できる。

第2の態様の観点から見ると、本発明は唯一のインスタンスストレージスキーマを使用してストレージシステムからファイルまたはファイルセグメントを削除する方法を提供できる。本方法は、ファイルに関連するメタデータをメタデータストアに格納するステップであって、各メタデータストアエントリにはエントリが関連するファイルから計算された、そのファイルに固有のフィンガープリントが含まれるステップと、メタデータストアエントリ内で識別されるファイルに属するファイルセグメントをコンテンツストア内に格納するステップであって、こうしたセグメントはセグメントから計算された、そのセグメントに固有のフィンガープリントを使用して識別できるステップと、メタデータストアエントリ内で識別されるファイルを説明するデータオブジェクトをコンテンツストア内に格納するステップであって、データオブジェクトは、説明するファイルに固有のフィンガープリントを使用して識別でき、ファイルのセグメントごとのセグメントフィンガープリントを含むリストを備えるステップとを備えることができる。本方法は、コンテンツストア内に格納されたセグメントおよびデータオブジェクトに対するアクションの命令を、時系列順で、またはこうしたアクションを実行する命令を受け取った際に実行させるステップと、削除するファイルを識別するステップと、削除するファイルのメタデータストアエントリにマーク付けをするステップと、このファイルのメタデータストアエントリへの参照をデータオブジェクトから除去するステップと、マーク付けされたメタデータストアエントリをメタデータストアから削除するステップとをさらに備えることができる。

本発明のその他の態様および実施形態は、以下に示す様々な特定の実施例に関する説明から明らかになるであろう。

ここで、単に例として添付の図面に関連付けながら本発明の特定の実施形態について説明する。こうした図面では、類似の要素は類似の参照番号で識別されている。

本発明に対して様々な変更や代替形態が可能であるが、例として特定の実施形態を図示し、本明細書で詳細に説明する。ただし、図面とそれらの詳細な説明は、本発明を開示された特定の形態に限定するものではなく、逆に本発明は添付の特許請求の範囲で定義する本発明の精神および範囲を逸脱しないすべての変更、均等物、および代替を含むものとすることを理解されたい。

図1に示すように、分散コンピューティング環境10には中央オフィス12が含まれていてもよい。さらに、1つもしくは複数のリモートオフィス14および/または1人もしくは複数のリモートユーザ16も含まれていてもよい。中央オフィス12には、データのバックアップ先となるストレージプール20が含まれていてもよい。バックアッププロセスの管理は、1台または複数台のローカルワークステーション24の代わりにバックアップクライアント22で実行してもよい。LAN(local area network:ローカルエリアネットワーク)25を経由してバックアップデータをストレージプール20に渡すことができる。

リモートオフィス14には、1つまたは複数のバックアップクライアント26が含まれていてもよい。これは、専用のバックアップコーディネータでもよい。または、バックアップクライアントがワークステーション上に提供されてもよい。このバックアップクライアント26により、リモートオフィスのバックアップアプライアンス28にデータをバックアップできる。バックアップアプライアンス28は、次いで、WAN(wide area network:ワイドエリアネットワーク)リンク29を経由してバックアップデータを中央オフィスのストレージプール20に転送できる。

モバイルユーザ16には、リモート端末上で動作するバックアップクライアント30を提供してもよい。バックアップクライアント30は、WANリンク29を経由してバックアップデータを中央オフィス12のストレージプール20に送信できる。

本実施例では、LAN 25およびWAN 29を経由して送信されるバックアップデータの量は、確実に一意のデータのみがバックアップストレージプール20に送信されるようにすることによって制限される。これを実現する技術については、以下でより詳細に説明する。

図2は、分散コンピューティング環境の別の実装例を示している。この実施例では、一部のワークステーションとモバイルユーザはそれぞれのローカルバックアップサーバに関連付けられており、各サーバはバックアップストレージ(backup storage)が実行されるデータセンターと通信するように動作できる。

図2に示すように、本実施例では、バックアップシステムに含まれるべき各コンピュータシステム40は、エージェントとも呼ばれるバックアップクライアントを実行する。各ローカルエージェントは、新しい、変更されたファイルまたはファイルセグメントを、それらが作成されたとき識別し、各ファイルまたはファイルセグメントのフィンガープリントを計算する。エージェントは、バックアップが不要なファイル、例えば、印刷スプールファイル、オペレーティングシステムファイル、または一時ファイルなどを無視するように構成できる。

本実施例では、所定のしきい値より大きなファイルはセグメントに分割される。これで、大きなファイルをより効率的にバックアップできる。例えば、MSOutlook(商標).pstファイルのようなファイルは、不変の大量のデータを含み、例えば、ユーザが電子メールを送信または受信し、またはカレンダーエントリを作成したときこれに追加された新しいデータを有する。このように、セグメントに分割する形でバックアップ操作が実行される場合に、ファイルの先頭の変更されていないセグメントをすべてバックアップし直す必要はない。このプロセスは、図3に示されている。

図3に示すように、ファイル70が最後にバックアップされたときは多くのバックアップセグメント72としてバックアップされている。次のバックアップ操作が実行されるときには、ファイルはサイズが増大し、新しいファイル74になっている。このバックアップ操作を実行する間に、バックアップエージェントは再びファイルを多くのセグメントと見なす。各セグメントは、それぞれについてフィンガープリントが計算されている。こうしたフィンガープリントを前のバックアップに含まれるフィンガープリントと比較することによって、セグメント76のすべてはすでにバックアップされており、バックアップシステムに格納し直す必要はないことを決定できる。一方、新しいセグメント78はまだバックアップされていないので、これをバックアップストレージに送信することができる。こうした技術を使用することにより、バックアップ操作でバックアップストレージに送信されるデータの量は、変更されたファイルのすべてが毎回バックアップのために送信されるシステムに比較すると大幅に削減できる。

以下の説明では、バックアップデータ単位を参照するために、用語、「ファイル」および「セグメント」を区別なく使用する場合がある。ファイルが所定のセグメントサイズより小さい場合は、ファイルが単一のセグメントに分割されたと見なしてもよいことは理解されるであろう。本実施例では、様々なセグメントサイズを使用できる。理解されるように、セグメントサイズが小さいほどバックアッププロセスの効率は向上するが、バックアップエージェントによる処理の負荷は増大する。いくつかの実施例では、セグメントのサイズとして、32キロバイト、64キロバイト、または128キロバイトを使用できる。

エージェントによって決定されるフィンガープリントは、ファイルまたはファイルセグメントをそのコンテンツによって一意に識別する。フィンガープリントは、ファイルまたはファイルセグメントのコンテンツごとに一意である。つまり、こうしたファイルまたはファイルセグメントに含まれるデータごとに一意である。名前の異なる2つのファイルは、通常はユーザにより2つの異なるファイルと見なされるが、こうした2つのファイルはコンテンツ(またはファイルセグメントの場合は一部のコンテンツ)がまったく同じ可能性がある。この場合、これらのファイルは、同じフィンガープリントを有することになる。したがって、2つの同一でないファイルまたはセグメントが同じフィンガープリントを有することはできず、同一のファイルまたはファイルセグメントは、常に同じフィンガープリントを有する。本実施例では、フィンガープリントはハッシュ関数を使用して計算される。ハッシュ関数は数学関数であり、ハッシュ関数を使用すると固定長メッセージのダイジェストまたはほとんど任意のサイズのデータアイテムからフィンガープリントを決定できる。ハッシュ関数は1方向関数である。すなわち、このプロセスを逆転することによってフィンガープリントから元のデータを再作成することはできない。ハッシュ関数は、CRC(Cyclic Redundancy Check:巡回冗長検査)による方法のような他のチェックサム技術に比較すると、必要な処理能力の点で相対的に時間と費用がかかる。しかし、ハッシュ関数には一意のデータセットごとに一意のフィンガープリントを生成するという利点がある。一方、CRCによる方法では複数の異なるデータセットから同じ結果が得られる可能性がある。本実施例でフィンガープリントの計算に使用できるハッシュ関数の例には、MD5、SHA1、およびSHA256がある。

次いで、各ワークステーション40のエージェントは、そのワークステーションで一意の新しいファイルまたはセグメントを識別する。このように、実際にそのワークステーションで新しく作成されたファイルまたはセグメントが以前にバックアップされたファイルまたはセグメントの正確なコピーである場合に、エージェントはこのセグメントを再バックアップのために送信しないことを理解している。

ワークステーション40でエージェントが一意のセグメントを識別すると、そのセグメントのフィンガープリントは、バックアップサーバ42に送信することができ、バックアップサーバでその一意性を再テストすることができる。この再テストが実行され、特定のワークステーション40で一意のファイルがバックアップサーバ42のサービスの対象となるすべてのワークステーションでも一意であるかどうかを判定する。バックアップサーバは、中央ネットワーク48内に配置されたワークステーション40に関しては、リモートオフィス46内または中央ネットワーク48内に図示されているローカルバックアップサーバでもよい。代替として、バックアップサーバは、リモートオフィス44に配置されたワークステーション40に関しては、中央ネットワーク48内に図示されているリモートバックアップサーバでもよい。ワークステーション40がノートブックコンピュータのようなモバイルワークステーションの場合は、モバイルワークステーション上のバックアップエージェントは常に同じバックアップサーバに接続するように構成することもできる。または、所与の時間に物理的にモバイルワークステーションに最も近いいずれかのバックアップサーバに接続することもできる。

バックアップ構造内のより高レベルの権限にフィンガープリントを送信するこのプロセスは、最高レベルの権限に到達するまで継続される。大規模なシステムでは、これは多くのローカルバックアップサーバが接続されている中央バックアップサーバでもよい。小規模なシステムでは、唯一のバックアップサーバが存在し、すべてのワークステーションに対してサービスを提供してもよい。バックアップシステム内でセグメントが一意であると決定された場合は、作成元のワークステーションエージェントに対して実際のデータセグメントをバックアップのために送信するように指示できる。

セグメントが一意でない場合は、バックアップエージェントによってそのフィンガープリントをバックアップサーバに送信することができる。場合によっては、システム内でデータ保持ポリシーが定義されており、ファイルまたはセグメントがバックアップ環境内の任意のワークステーションに最後に存在したときから最小の期間にわたってバックアップストレージ内に維持されることが保証される。いくつかの実施例では、さらに、所与のファイルのすべてのセグメントはそのファイルのデータ保持要件の期限までバックアップシステム内に存在していることを保証する必要もあろう。このようにして、ファイルの最後に変更されたセグメントだけでなく、そのすべてのセグメントはデータ保持ポリシーに指定する期間が満了するまで保存される必要があろう。

本実施例のワークステーション40には、バックアップを必要とするデータが格納されているファイルサーバまたはアプリケーションサーバが含まれていてもよいことが理解されよう。例えば、それは、ファイルサーバが多数のデータファイルを格納するために使用され、その結果これらのコンテンツをバックアップすることが必要とされる可能性がある場合とすることができる。MSExchange(商標)サーバのようなアプリケーションサーバの例では、アプリケーションサーバにはアプリケーションに関連するデータが格納されているので、バックアップが必要であると考えられる。アプリケーションファイルは、ワークステーション上にあるかサーバ上にあるかにかかわらず、例えば、システム障害の後にカスタム設定を回復したりワークステーションまたはサーバを再構築したりするための直接的な方法を提供するために、バックアップの対象とする必要があると考えられる。

前述のように、データ保持ポリシーはコンピュータシステム内のデータに適用できる。こうしたポリシーは、企業で指定したポリシーでも、規制機関によって課されたものでもよい。規制機関が課したポリシーは、例えば金融情報および法的情報に関して適用されてもよい。このために、ワークステーションのバックアップエージェントは、削除されたファイルをバックアップ操作に含めることによって、ワークステーション上での存在期間が1バックアップ間隔に満たないファイルもバックアッププロセスに含まれることを保証するのが望ましい。

理解されるように、一般的にはサイズが数十ビット程度のフィンガープリントを使用して、実際にいずれのセグメントのバックアップが必要かを決定するという観点でバックアッププロセスを実行することにより、ワークステーションとバックアップサーバとのネットワーク接続を経由して転送されるデータの量は、バックアップの対象として識別されたデータの格納が本当に必要かどうかを判定する前にそうしたデータが格納のために送信されるシステムに比較して大幅に削減される。

図2に戻り、バックアップサーバ42はバックアップするデータがストレージサーバ50のようなストレージ構成(storage arrangement)に格納されるようにしてもよい。ストレージサーバ50は、スタンドアロンのストレージサーバでも、SAN (storage area network)52のようなストレージインフラストラクチャの一部でもよい。代替の実施例では、バックアップサーバ42にバックアップデータ用のストレージが含まれていてもよい。

冗長性、およびバックアップデータに対する高セキュリティ、高可用性を提供するために、ストレージサーバ42の1台はアクティブであり、もう1台はアクティブなバックアップサーバに障害が発生したときに引き継ぐことができるホットスタンバイとして動作するストレージサーバのミラーリングペア(mirrored pair)で構成されてもよい。例えば、リモートサイト56にリモートミラー54を配置することにより、アクティブなバックアップサーバがある場所に影響を及ぼす障害が発生した場合に備えた弾力性を提供することもできる。こうしたリモートサイトを使用して、例えば、バックアップ磁気構成内に、またはテープボールト(tape vault)58のような従来のバックアップ技術を使用して、バックアップするデータのバックアップコピーを作成および/または保存することもできる。

このように、データのフィンガープリントを使用してバックアップするファイルおよび/またはセグメントを識別し、一意のファイルおよびセグメントのみをバックアップすることによって、バックアップストレージボリュームの利用効率を最大化するバックアップ環境の多くの実施例について説明してきた。

バックアップシステム内でファイルおよびセグメントにアクセスする手段を提供するために、ファイルまたはセグメントがそのフィンガープリントを検索することによって識別でき、取得できるインデックス付きのファイルシステムまたはデータベース構造にファイルおよびセグメントを格納することができる。フィンガープリントは、ファイルまたはセグメントの「署名」と見なすこともできる。このことにより、ファイルおよびセグメントにはシンプルなファイルシステムまたはデータベース構造を使用できるので、迅速な検索および取得プロセスを実現できる。

前述のタイプのバックアップストアのコンテンツ検索を円滑化し、ストアのコンテンツの評価とストアからのデータの取得との両方を実行するために、メタデータのデータベースを提供してもよい。メタデータのデータベースすなわち「メタベース(metabase)」には、バックアップシステム内に格納された各ファイルを説明するデータを格納できる。こうしたデータには、ファイル名、最終編集日、作成日、作成者、ファイルサイズ、およびファイルのコンテンツを表すキーワードなどの情報を含めることができる。メタベースには、ファイル(またはファイルの各セグメント)のフィンガープリント(1つ以上)を格納することもできる。このことにより、メタベース内で特定の期日に編集されたファイルを検索するユーザは、メタベース上でクエリを実行し、返された結果によって、ファイルの、一意に識別するフィンガープリントを使用してバックアップシステム内のファイルを取り出すことが可能になる。このように構築されたシステムでは、実際のバックアップファイルのサイズに比較してデータベースサイズが小さいため、メタベースは高速で検索する性能を有し、ファイル/セグメントデータベースでシンプルな検索手順を使用することができる。

別の実施例では、ファイル/セグメントおよびメタデータのデータベースは単一のデータベースに統合されている。こうしたシステムは、単一のデータベースが必要とされるにすぎないという意味でシンプルな構造を提供する。

メタベースとファイル/セグメントストアとが別々の実施例に戻ると、このシステムはメタベース内の複数のエントリが同じフィンガープリントを含むのを許可することによって、シングルインスタンスストアとして動作できる。これは、図4に示されている。

3台のコンピュータデバイスである端末(terminal)90、ファイルサーバ92、およびモバイル端末94のそれぞれに同一のスプレッドシートファイル「Budget2005.xls」が格納されている。端末90では、ファイル96が「C:＼My Documents＼SalesDocs＼」フォルダに2005年3月19日に格納されており、そのサイズは293kBである。ファイルサーバ92では、ファイル98が「X:＼Public＼Finance＼」フォルダに2005年3月22日に格納されており、そのサイズは293kBである。モバイル端末94では、ファイル100が「C:＼My Dcouments＼」フォルダに2005年4月14日に格納されており、そのサイズは293kBである。ファイル96、98、100は同等なので、すべて同じサイズであり、コンテンツも同じである(それぞれ102A、102B、102C)。したがって、バックアップ操作の間に同じフィンガープリントFP(104A、104B、104C)が生成される。

端末90、ファイルサーバ92、およびモバイル端末94のそれぞれでのバックアップ操作は別々のタイミングで実行でき、結果としてそれぞれのバックアップがそれぞれ別々のタイミングでバックアップシステムに追加される。例えば、モバイル端末94が一定の期間にわたってバックアップシステムに接続されていない状態にあり、その間に端末90およびファイルサーバ92についてスケジュールされたバックアップ操作が実行された場合は、モバイル端末94のバックアップ操作は、端末90のバックアップ操作ともファイルサーバ92のバックアップ操作とも異なるタイミングで実行されるであろう。

端末90のバックアップ操作を実行するために、ファイル96に関するフィンガープリント104Aが計算され、フィンガープリント104Aはバックアップシステムのコンテンツストア部116と比較される。フィンガープリントがバックアップシステム内で一意である場合は、ファイル96のコンテンツ102Aをフィンガープリント104に関連付けられたコンテンツ102として示されるコンテンツストア116に格納する必要がある。フィンガープリントがコンテンツストア内で一意でない場合は(すなわち、このファイルがすでにバックアップされている場合は)、コンテンツを再び格納する必要はない。コンテンツ102Aを格納する必要があるかどうかを判定するステップと平行して、ファイル96がまだバックアップされていない場合は、ファイル96のメタデータ106がメタベース114に格納される。メタデータ106は、コンテンツストア116に格納されたコンテンツ102を識別するフィンガープリント104と一緒に格納される。

ファイルサーバ92上のファイル98およびモバイル端末94上のファイル100がバックアップするように選択された場合は、同様のプロセスが実行される。このようにして、ファイル96、98、100がそれぞれバックアッププロセスに含まれると、それぞれのメタデータは異なるため、メタベースには各ファイルのエントリが含まれるが、コンテンツストアにはファイルの単一のコピーのみが含まれる。代替の実装では、メタベースにはフィンガープリントごとに単一のレコードを格納でき、このレコードにはこのフィンガープリントの生成元となったファイルのすべてのインスタンスのメタデータが格納される。

このことにより、生成元となったファイルのすべてのインスタンスのメタデータを含むメタベースを提供でき、コンテンツストア内に格納されたファイル/セグメントを取得する検索可能な環境が提供される。その一方で、コンテンツストアには各ファイル/セグメントの1つのインスタンスのみが含まれるので、コンテンツストアで必要とするストレージ領域は制限される。メタベースレコードは、それぞれの各コンテンツレコードのフィンガープリントによってそれぞれコンテンツストア内のコンテンツレコードにリンクする。

コンテンツストア内のファイルおよびセグメントの管理を支援するために、データオブジェクトエンティティ(data object entity)を導入することができる。データオブジェクトによってメタベースエントリごとに非常に多くのセグメントリンクが不要になり、ファイル内のセグメントの管理を円滑化できる。また、データオブジェクトを使用すると、バックアップシステム内のファイルをグループ化することもできる。

図5を参照すると、データオブジェクト110が示されている。データオブジェクトは、元になるファイルを構成するすべてのセグメントのリスト112を提供することによって、元のファイルをそのセグメントのすべてにリンクする。データオブジェクト110は、コンテンツストア内にセグメントと一緒に格納できる。ストア内でデータオブジェクトの識別とアクセスを可能にするために、元のファイルを全体としてとらえたフィンガープリントにデータオブジェクトを関連付けることができる。セグメントが単一のファイルの場合は、本実施例のシステムはセグメントのセグメントオブジェクトを作成する(他のマルチセグメントファイルは、このセグメントをそれらのセグメントの1つとして含む可能性があるため)。このシステムは、データオブジェクトも作成するが、この場合はファイルオブジェクト内のセグメントリストに含まれるセグメントは1つのみである。ファイルとセグメントオブジェクトは共に、同じフィンガープリントを有する(したがって、同じフィンガープリントの下で格納される)。データオブジェクト110を使用すると、データオブジェクト110内で参照されているセグメント112を取り出し、データオブジェクト内に現れる順序でセグメントを次々に添付することによって元のファイルを再構築できる。

セグメントごとに、セグメントが関連付けられるデータオブジェクトのリストは、コンテンツストア内にセグメントと一緒に格納できる。データオブジェクトのリストはセグメントの追記またはメタデータとして格納されるため、セグメントの要素とは見なされない。したがって、セグメントのフィンガープリントはデータオブジェクトのリストによって変更されることはない。セグメントのデータオブジェクトのリストは、セグメントに関する情報を効果的に記録(bookkeeping)し、しかもセグメントデータの要素とは見なされない。セグメントのフィンガープリントはセグメントデータのみに関して計算されるので、セグメントのフィンガープリントはデータオブジェクトのリストのようにセグメントに関して記録されるいずれの情報にも無関係である。

これは、セグメントのファイルへのリンクを提供する。前述のように、一意のセグメントはコンテンツストアに1度のみ格納され、ファイルストア内でセグメントの不要な重複を回避する。前述のように、実際に2つのファイルは異なっていても1つまたは複数のセグメントは共通する可能性があるので、こうしたシングルインスタンスの処理を積極的に実行する必要がある。こうした共通のセグメントの格納は1度であるが、2つのファイルのデータオブジェクトは異なっており、いずれもコンテンツストアに格納される。したがって、両方のデータオブジェクトは共通のセグメント(1つ以上)を参照する。あるセグメントを参照するすべてのデータオブジェクトに(したがって、そのセグメントを含むすべてのファイルに)そのセグメントをリンクする方法を提供するために、セグメントごとにこうしたデータオブジェクトのリストが記録される。したがって、こうしたリストにはセグメントのデータオブジェクト参照が含まれる。

このように、バックアップ操作実行中にバックアップクライアントがセグメントのバックアップを(ファイルバックアップの一部として)要求する場合は、コンテンツストアのクエリを実行することによって、このセグメントがコンテンツストア内にすでに存在しているかどうかを検証する。コンテンツストアがこのクエリに対して肯定応答を返す場合は、クライアントは実際のセグメントをコンテンツストアに送信せず、コンテンツストアに対して、このセグメントからクライアントがバックアップするファイルに対応するデータオブジェクトへのリンクを追加するように要求する。

あるファイルに関する様々な部分とディスクリプタ(discriptor)との関係の循環を完結するために、メタベース内のファイルのメタデータレコードとコンテンツストア内のデータオブジェクトとのリンクが提供される。その最もシンプルな形態では、ファイルのフィンガープリントをメタデータレコードに含め、逆もまた同様に、メタデータレコードへのリンクをデータオブジェクトに含めることによって実現できる。いくつかの実施例では、特定の基準に従ってファイルをグループ化するのが望ましいであろう。グループ化の基準の例には、バックアップの日付(例えば、同じ日にバックアップされたすべてのファイルをグループ化する)やバックアップのソース(例えば、同じコンピュータアプライアンスからバックアップされたすべてのファイル、または特定のユーザまたはユーザグループに属するすべてのファイルをグループ化する)がある。この説明の残りの部分では、この一般的な例が仮定されており、特定のユーザが定義したファイルのグループをファイルグループと呼ぶものとする。こうした仮定の下で、メタデータレコードから対応するデータオブジェクトへのリンクは、ここでもファイルのフィンガープリントを使用して提供される。しかし、さらにデータオブジェクトは、そのデータオブジェクトを参照する1つまたは複数のメタデータレコードを保持するファイルグループまたはグループをデータオブジェクトと一緒に記録することにより、前記メタデータレコードにリンクできる。例えば、3つのファイルグループが存在し、ファイルグループ1にはデータオブジェクトXを参照する2つのメタデータレコードが保持され、ファイルグループ2にはデータオブジェクトXを参照する1つのメタデータレコードが保持され、ファイルグループ3にはデータオブジェクトXを参照するメタデータレコードは保持されないものと仮定する。この場合、データオブジェクトXに関してコンテンツストアに記録されたファイルグループのリンクのリストには、グループID(identifications)1および2が含まれる。個々のメタデータレコードへのリンクではなくファイルグループへのリンクを使用することにより、データオブジェクトに関して記録されたリンクの数を制限することができる。バックアップ操作の間、クライアントがファイルグループ1のファイルをバックアップしているときに、データオブジェクトがすでにコンテンツストアに格納されているか、それとも実際にこのクライアントによって格納されたかにかかわらず、クライアントはコンテンツストアに対してバックアップされた各データオブジェクトをファイルグループ1にリンクするように要求する。

このように、データネットワークのためのコンテンツが最適化されたバックアップおよび/またはアーカイブソリューションを提供するシステムについて説明してきた。本システムでは、一意のデータはすべて格納される一方で、一意でないデータの不要な格納を回避することが保証される。大規模なデータオブジェクトを複数のセグメントとして分析することにより、最適化はさらに促進される。

図4から明らかなように、所与のコンテンツアイテムはメタデータストア(または「メタベース」)内に複数のエントリへのリンクを有することができる。いくつかの実施例では、所与の任意のコンテンツアイテムは1つの、またはいくつかの、または多くのメタベースアイテムへのリンクを有することができることは明らかである。例えば、ドキュメントは作成されるエンティティの外部の受信者に提供される前に、1人の作成者によって作成されてもよい。このような場合は、恐らくコンテンツストアエントリごとのメタベースエントリは単一のみであろう。別の実施例では、ドキュメントは小規模なチームで共同作成されるか、または1人が作成してチーム内の他のメンバーに電子メールで送信してもよい。こうした状況では、コンテンツアイテムはコンテンツストアエントリごとにいくつかのメタベースエントリが存在すると考えられる。他の実施例では、ドキュメントは1個人によって作成されてから、次いで組織内または部門内の多くまたはすべての人物に複製が送信されてもよい。この実施例では、各コンテンツアイテムは、コンテンツストアエントリごとに数百さらには数千のメタベースエントリを有することができる。

これにセグメント化のスキームが適用される場合は、状況はさらに極端になりうる。ドキュメントが組織または部門全体に配布される例で考えると、ドキュメントは、大規模なドキュメントである場合、多数のセグメントを含む可能性がある。次に、ドキュメントは受信者の一部から組織の外部の個人に送信されるものとする。また、元のドキュメントにはいくつかのスペルミスが含まれる。何人かの受信者はスペルミスを訂正せずに転送し、何人かの受信者はスペルミスの特定のサブセットを訂正し、何人かの受信者はすべてのスペルミスを訂正し、それ以外はスペルミスのその他のサブセットを訂正するものとする。これにより、一部のユーザによって維持されるコピーは元のドキュメントと同一であり、他のユーザによって維持されるコピーは元のドキュメントから何らかの形で修正されることになる。このように、変更されたドキュメントをセグメント化すると、格納も必要となる新しいセグメントが作成される可能性がある。様々なユーザによって加えられる修正の性質により、複数のユーザが、同一のファイルを個別に作成することも、同一のセグメントを生み出すファイルを有することもある。したがって、1つの元のドキュメントから多くの類似した関連のセグメントが作成される可能性があり、各セグメントは多くの異なるメタベースエントリを介して異なるユーザグループにリンクする。数ヶ月または数年という時間にわたって様々なユーザによって様々な変更が行われる場合は、セグメントとメタデータエントリの入り組んだ関係(web)はさらに複雑になる可能性がある。

したがって、コンテンツストアからデータを除去するのが望ましい場合、例えばデータ保持ポリシーで定義されたデータ保持期間が満了した後に、後のバージョンのドキュメントを完全かつ取得可能な状態で残しながら、いずれのコンテンツストアエントリおよびメタベースエントリを安全に削除できるかを判定するのは難しいものとなり得る。

また、所与の任意の時間においてデータベースの状態を明確に決定するのも難しいものとなり得る。例えば、所与のコンテンツストアアイテムは、アーカイブ/バックアップシステムがサービスを提供するソースコンピュータ上にそのアイテムが存在するものとして最後に識別されて以来、所定のしきい値時間が経過したときに、削除されることになっている。このようにしてアイテムが削除される。しかし、アイテムが削除される直前に、削除されるアイテムのフィンガープリントに一致するフィンガープリントを有するセグメントがストア内にあるかどうかを問い合わせるクエリがバックアップエージェントから受信される。アイテムはその時点ではまだ存在するので、バックアップエージェントは肯定応答を受け取る。したがって、セグメントを格納するために送信しない。しかし、クエリに応答した直後に、このアイテムはデータ保持スキーマに基づいて削除される。このようにして、データが意図されずに失われる可能性がある。

この状況には、そうした状況が発生する可能性を回避するように設計されたデータ除去ポリシーを実装することによって対処できる。こうしたシステムについては、ここでさらに詳しく説明する。

以下の説明では、図5に関連して上で説明したデータオブジェクトエンティティがバックアップシステム内に実装されていることが仮定される。コンテンツストアは、受け取られたアクション命令の直列化されたアクションキューを使用することも仮定されている。バックアップシステムのこうした2つの機能を使用すると、データが意図されずに失われることなしにデータを除去することができる。

本実施例では、キューのメカニズムが実装され、コンテンツストアに関して実行されるアクションを直列化している。コンテンツストアに関するすべてのアクションは、このキューに追加されて先着順に実行され、アクションはキューを迂回することができない。予想されるアクションの例には、新しいセグメントの格納、新しいデータオブジェクトの格納、既存のセグメントから新しいデータオブジェクトへのリンクの追加、既存のデータオブジェクトからファイルグループへのリンクの追加、データオブジェクトからファイルグループへのリンクの除去、セグメントからデータオブジェクトへのリンクの除去、データオブジェクトの除去、セグメントの除去がある。バックアップクライアントからの特定のクエリおよび後続のアクションは、アトミックな操作でなければならないことに留意されたい。例えば、バックアップクライアントがコンテンツストアに対して特定のセグメントがストア上にすでに存在しているかどうかを問い合わせ、続いて(肯定応答を受信した後に)そのセグメントのリンクアクションを要求する場合は、このクエリとアクション要求との間に他のアクションがキューに入ることを確実にできないようにする必要がある。それ以外の場合は、前述のようにデータが意図されずに失われる可能性がある。

前述のように、データオブジェクトの提供、および直列化されたアクションキューの使用により、データの除去プロセスは、以下で説明するように進むことができる。このプロセスは、2つの主なフェーズからなる。第1のフェーズはメタベースで処理され、第2のフェーズはコンテンツストアで実行される。

このプロセスはメタベース上で開始され、除去するファイルのリストで開始される。このリストには、単一のファイルからストア内のすべてのファイルに至るまで、任意の数のファイルを含めることができる。このリストは、データ保持および失効(expiration)ポリシーに従って決定することができる。例えば、特定の期間(例えば、データ保持に関する法律または規制で規定された期間)を経過したすべてのデータを除去の対象として識別してもよい。

本方法は、図6に示されている。第1に、ステップS6-1で、除去されるファイルのメタデータレコードがメタベース内で識別され、メタベース内で失効(expired)とマーク付けされる。レコードが失効とマーク付けされると同時に、バックアップクライアントはこのレコードをエントリポイントとして使用し、レコードの参照先のファイルを取得することができなくなる。次に、ステップS6-3で、メタベースはコンテンツストアに対して失効とマーク付けされたメタベースレコードからデータオブジェクトへのリンクを解除するように要求する。1つの例では、各データオブジェクトが単一のファイルを参照する場合に、実行するのはこうしたレコード間の1対1リンクの解除である。前述のより一般的な例では、データオブジェクトは直接メタデータレコードにリンクせず、ファイルグループにリンクするので、このステップはさらに複雑であり、メタデータレコードとデータオブジェクトとの間に1対1の関係はない可能性がある。したがって、ファイルグループ1に属するファイルA(のメタデータレコード)が失効した場合に、これは直ちに対応するデータオブジェクトからファイルグループ1へのリンクを除去できることを示してはいない。実際に、ファイルグループ1の内部に、ファイルAの少なくとも1つのフィンガープリントと同じフィンガープリントを有する、したがってコンテンツストア上にファイルAと同じデータオブジェクトを参照するファイルBという第2のファイルが存在することが考えられる。このような場合は、前記データオブジェクトからファイルグループ1へのリンクは除去されてはならない。一般的な規則として、メタベースはファイルグループ内で同じデータオブジェクトを参照するすべてのメタデータレコードが失効とマーク付けされた場合、またそうした場合に限り、ファイルグループからこの特定のデータオブジェクトへのリンクを解除できる。いったんこの条件が満たされると、ファイルグループは想定されるデータオブジェクトを参照しなくなり、実質的にリンクを除去できる。

必要に応じてデータオブジェクトが更新されると、失効したメタデータレコードをメタベースから安全に除去できる(ステップS6-5)。1つの実施例では、こうした除去を直ちに完了できる。別の実施例では、失効したレコードは、さらなる期間にわたってメタベース内で保存されてもよい。この方法は、履歴を保存したり追跡したりするために有効と考えられる。この実施例では、所定の期間が経過した後に除去を実行できる。

ステップS6-3で、コンテンツストアはメタベースから要求されたリンク解除アクションを処理する。データオブジェクトのリンク解除アクションは、すべてがコンテンツストアキューに入り、キューに入った順に処理される。各リンク解除アクションにより、データオブジェクトに関連付けられたファイルグループのリストから1つのファイルグループが除去される。結果として、データオブジェクトはファイルグループの要素ではなくなる。

特定の事例では、リンク解除アクションにより、データオブジェクトから最後のファイルグループのリンクを除去できる。これは、データオブジェクトがいずれのファイルグループからも必要とされていないこと、したがって、この特定のデータオブジェクトに関するクライアントからのリンク要求がまだアクションキューに含まれている場合を除き、このデータオブジェクトを削除できることを示している。このようなアクションが存在すると、データオブジェクトが直ちに除去された場合にデータの喪失が発生する可能性がある。こうしたデータの喪失を回避するプロセスは、図7にさらに詳しく示されている。このために、本実施例では、データオブジェクトはすぐには除去されず、データオブジェクトを除去するアクションがコンテンツストアキューに追加される(ステップS7-1)。同時に、コンテンツストアはデータオブジェクトをアクセス不可能にするか、またはデータオブジェクトの存在を隠す(ステップS7-3)。したがって、コンテンツストアキューによる先着順の操作により、想定されるデータオブジェクトへのリンクを追加するアクションは、除去アクションを処理できるようになるまでに処理されていることが保証される。さらに、データオブジェクトはキューに除去アクションが追加された後は使用不可能になっているため、データオブジェクトの新しいリンク要求がキューに追加されることはない。実際に、バックアップクライアントがストアに対してこのデータオブジェクトへのリンクの追加を要求する場合に、コンテンツストアはこのデータオブジェクトをまだ保存していないため、クライアントはコンテンツストアに対して新しいデータオブジェクトの作成を要求する必要があるという応答を返す。

したがって、コンテンツストアが除去アクションを処理できる状態になったときには、データオブジェクトへのリンクを追加するすべてのアクションはすでに処理されており、同様の新しいアクションはキュー内で保留になっている。結果として、除去アクションを処理する前に、コンテンツストアはデータオブジェクトへのリンクが追加されたかどうかを検証する(ステップS7-5)。追加された場合は、ステップS7-7で除去アクションがキャンセルされる(データオブジェクトがまだ使用されているため)。追加されていない場合は、除去アクションが処理される(ステップS7-9)。

データオブジェクトの除去アクションを処理すると(ステップS7-9に示すように)、コンテンツストアはデータオブジェクトを除去する。データオブジェクトが除去されると、このデータオブジェクトのセグメントからデータオブジェクトへのリンクは不要になり、除去できる(ステップS7-11)。したがって、こうしたセグメントのそれぞれについて、コンテンツストアはコンテンツストアキューにリンク解除アクションを追加する。こうしたアクションが(直ちに実行されずに)キューに追加されると、関連のセグメントのいずれかに関してすでにスケジュールされているアクションがある場合は、まずこのアクションを処理できる。こうしたリンク解除アクションが処理されると、セグメントはデータオブジェクトにリンクしなくなる。

データオブジェクトのリンク解除アクションと同様に、セグメントのリンク解除アクションによってセグメントから最後のデータオブジェクトリンクを除去できる場合がある。これは、セグメントがいずれのデータオブジェクトからも必要とされていないこと、したがって、この特定のセグメントに対するクライアントからのリンク要求が依然としてアクションキューに含まれている場合を除き、このセグメントを削除できることを示している。こうしたアクションが存在すると、セグメントを直ちに除去した場合にデータの喪失が発生する可能性がある。リンクアクションが存在する場合は、実際には、クライアントがセグメントをバックアップしようとしたが、コンテンツストアからこのセグメントはすでに存在していると通知され、代わりにリンクアクションがキューに配置されたことになる。このアクションがキューに入ると、クライアントは実際にセグメントが格納され、保存されることを確信する。したがって、前の説明に戻り、セグメントの最後のリンクを除去した後直ちにセグメントを除去すると、データの喪失が発生する可能性がある。こうしたデータの喪失を回避するプロセスは、図8に詳しく示されている。このために、セグメントを直ちに除去せず、代わりにセグメント除去アクションをコンテンツストアキューに追加し(ステップS8-1)、コンテンツストアはこのセグメントを外部の領域(実際にはバックアップクライアント)に隠す(ステップS8-3)。このセグメント除去アクションがキューの最後に到達して処理できる状態になるときには、このセグメントに関連する他のアクションがキュー内に存在していた場合はすでに処理されており、このセグメントに関する新しいアクションがキューに追加されることはありえない。このようにして、コンテンツストアが除去アクションを処理できる状態になると、コンテンツストアはセグメントへのリンクが追加されているかどうかを検証する(ステップS8-5)。追加された場合は、セグメントはまだ必要とされているため、除去アクションはキャンセルされる(ステップS8-7)。追加されていない場合は、除去アクションが処理される(ステップS8-9)。

以上の除去プロセスに関する説明からわかるように、ファイルグループから除去されるデータオブジェクトは、いずれのファイルグループからも参照されなくなった場合を除き、実際にコンテンツストアからは削除されない。同様に、格納されたセグメントは、いずれのデータオブジェクトにもリンクしなくなった場合を除き、実際にコンテンツストアからは削除されない。これは、コンテンツストアがシングルインスタンスを使用して効率的なストアサイズを維持しているという事実によるものである。

このようにして、ファイルセグメントのシングルインスタンスストレージを実装することによってストレージ領域の効率的な利用を実現するバックアップシステムを構成でき、時間的に重複する削除命令および書き込み命令によってデータが喪失する危険性のないデータ保持スキームに従ってファイルおよびセグメントを削除することができる。

前述の実施例に対する多くの変形、変更、および追加、および均等物は、本明細書の技術のある読者には明らかであり、本発明の精神と範囲を逸脱することなく実装できる。

データバックアッププロセスを利用できる分散コンピューティング環境を示す概略図である。 データバックアッププロセスを利用できる別の分散コンピューティング環境を示す概略図である。 2つの時点間でデータファイルがどう変更されうるかを示す概略図である。 シングルインスタンスバックアップシステムを示す概略図である。 データオブジェクトを示す概略図である。 ファイルを削除する流れ図である。 データオブジェクトを削除する流れ図である。 ファイルセグメントを削除する流れ図である。

符号の説明

10 分散コンピューティング環境
12 中央オフィス
14 リモートオフィス
16 リモートユーザ
20 ストレージプール
22 バックアップクライアント
24 ローカルワークステーション
25 LAN
26 バックアップクライアント
28 バックアップアプライアンス
29 WAN
30 バックアップクライアント
40 コンピュータシステム
42 バックアップサーバ
46 リモートオフィス
48 中央ネットワーク
50 ストレージサーバ
52 SAN
54 リモートミラー
56 リモートサイト
58 テープボールト
70 ファイル
72 バックアップセグメント
74 新しいファイル
76 セグメント
78 新しいセグメント
90 端末
92 ファイルサーバ
94 モバイル端末
96,98,100 ファイル
102,102A,102B,102C コンテンツ
104,104A,104B,104C フィンガープリント
106 メタデータ
110 データオブジェクト
112 セグメントのリスト
114 メタベース
116 コンテンツストア

Claims (14)

1. シングルインスタンスストレージスキーマを使用してファイルまたはファイルセグメントを格納するように動作可能なバックアップシステムにおいて、
   ファイルに関連するメタデータを格納するように動作可能なメタデータストアであって、各メタデータストアエントリには前記エントリが関連する前記ファイルから計算された、前記ファイルに固有のフィンガープリントが含まれるメタデータストアと、
   メタデータストアエントリ内で識別されるファイルに属し、前記セグメントから計算された、前記セグメントに固有のフィンガープリントを使用して識別できるファイルセグメントを格納し、
   前記メタデータストアエントリ内で識別されるファイルを説明し、参照する前記ファイルに固有のフィンガープリントを使用して識別でき、前記ファイルの各セグメントのセグメントフィンガープリントを含むリストを備えるデータオブジェクトを、コンテンツストア内に格納し、
   ストア内に格納されたセグメントおよびデータオブジェクトに対するアクションを、時系列順で、またはコンテンツストアアクションキューによって前記アクションを実行する命令が受け取られた際に実行する
   ように動作可能なコンテンツストアとを備え、
   削除するファイルを識別し、前記削除するファイルのメタデータストアエントリにマーク付けし、前記ファイルの前記メタデータストアエントリへの参照を前記データオブジェクトから除去し、前記マーク付けされたメタデータストアエントリを前記メタデータストアから削除するように動作可能なバックアップシステム。
2. 各データオブジェクトが、複数のファイルを説明でき、説明する各ファイルのフィンガープリントを使用して識別できる請求項1に記載のシステム。
3. データオブジェクトからメタデータストアエントリへの参照を除去した結果として前記データオブジェクトが説明するファイルがなくなった場合、前記データオブジェクトを削除するように動作可能な請求項2に記載のシステム。
4. コンテンツストアアクションキューの最後にデータオブジェクトの削除命令を追加し、前記データオブジェクトを隠し、前記削除命令が前記コンテンツストアアクションキューの先頭に到達したとき、前記削除命令が前記命令キューに追加された後で前記データオブジェクトが書き込みアクションの対象となったかどうかを判定するために検査し、そうした書き込みアクションが実行されなかった場合に前記データオブジェクトを削除するように動作可能な請求項3に記載のシステム。
5. 前記データオブジェクトから前記メタデータストアエントリへの参照を除去した後に、前記データオブジェクトから、前記データオブジェクト内で説明されるいずれのファイルにも関連しなくなったセグメントへのリンクを除去するように動作可能な請求項1から4のいずれか一項に記載のシステム。
6. 前記データオブジェクトから前記セグメントリンクを除去した後に、前記セグメントに現在リンクしているデータオブジェクトがない場合、前記セグメントを除去するように動作可能な請求項5に記載のシステム。
7. コンテンツストアアクションキューの最後に前記セグメントの削除命令を追加し、前記セグメントを隠し、前記削除命令が前記コンテンツストアアクションキューの先頭に到達したとき、前記削除命令が前記命令キューに追加された後で前記セグメントが書き込みアクションの対象となったかどうかを判定するために検査し、そうした書き込みアクションが実行されなかった場合に前記セグメントを削除するように動作可能な請求項6に記載のシステム。
8. シングルインスタンスストレージスキーマを有するストレージシステムからファイルまたはファイルセグメントを削除する方法において、
   ファイルに関連するメタデータをメタデータストアに格納するステップであって、各メタデータストアエントリには前記エントリが関連するファイルから計算された、前記ファイルに固有のフィンガープリントが含まれるステップと、
   メタデータストアエントリ内で識別されるファイルに属するファイルセグメントをコンテンツストア内に格納するステップであって、前記セグメントが、前記セグメントから計算された、前記セグメントに固有のフィンガープリントを使用して識別できるステップと、
   前記メタデータストアエントリ内で識別されるファイルを説明するデータオブジェクトを前記コンテンツストア内に格納するステップであって、前記データオブジェクトが、説明する前記ファイルに固有のフィンガープリントを使用して識別でき、前記ファイルの各セグメントのセグメントフィンガープリントを含むリストを備えるステップと、
   前記コンテンツストア内に格納されたセグメントおよびデータオブジェクトに対するアクションの命令を、時系列順で、または前記アクションを実行する命令が受け取られた際に実行させるステップと、
   削除するファイルを識別するステップと、
   前記削除するファイルのメタデータストアエントリにマーク付けするステップと、
   前記ファイルの前記メタデータストアエントリへの参照を前記データオブジェクトから除去するステップと、
   前記マーク付けされたメタデータストアエントリを前記メタデータストアから削除するステップとを備える方法。
9. 各データオブジェクトが、複数のファイルを説明でき、説明する各ファイルのフィンガープリントを使用して識別できる請求項8に記載の方法。
10. データオブジェクトからメタデータストアエントリへの参照を除去した結果として前記データオブジェクトが説明するファイルがなくなった場合に、前記データオブジェクトを削除するステップをさらに備える請求項9に記載の方法。
11. 前記データオブジェクトを削除する前記ステップが、
    前記コンテンツストアアクションキューの最後に前記データオブジェクトの削除命令を追加するステップと、
    前記データオブジェクトを隠すステップと、
    前記削除命令が前記コンテンツストアアクションキューの先頭に到達したとき、前記削除命令が前記命令キューに追加された後で前記データオブジェクトが書き込みアクションの対象となったかどうかを判定するために検査するステップと、
    そうした書き込みアクションが実行されなかった場合に前記データオブジェクトを削除するステップとを備える請求項10に記載の方法。
12. 前記データオブジェクトから前記ファイルの前記メタデータストアエントリへの参照を除去した後に、前記データオブジェクト内で参照されるいずれのファイルにも関連しなくなったセグメントへのリンクを前記データオブジェクトから除去するステップをさらに備える請求項8から11のいずれか一項に記載の方法。
13. 前記データオブジェクトから前記セグメントリンクを除去した後に、前記セグメントに現在リンクしているデータオブジェクトがない場合、前記セグメントを除去するステップをさらに備える請求項12に記載の方法。
14. 前記セグメントを除去する前記ステップが、
    前記コンテンツストアアクションキューの最後に前記セグメントの削除命令を追加するステップと、
    前記セグメントを隠すステップと、
    前記削除命令が前記コンテンツストアアクションキューの先頭に到達したとき、前記削除命令が前記命令キューに追加された後で前記セグメントが書き込みアクションの対象となったかどうかを判定するために検査するステップと、
    そうした書き込みアクションが実行されなかった場合に前記セグメントを削除するステップとを備える請求項13に記載の方法。

Images