(57)【要約】  粗いレベルでリソース再利用参照リストを管理するためのシステム及び方法である。ストレージデバイスは、複数のストレージオブジェクトを複数のストレージコンテナに保存するように構成され、前記ストレージコンテナの各々は、複数の前記ストレージオブジェクトを保存するように構成されている。ストレージコンテナ参照リストが維持され、ストレージコンテナの各々に関して、ストレージコンテナ参照リストは、複数のファイルの内のどのファイルが、所与のストレージコンテナ内のストレージオブジェクトを参照するかを識別する。ストレージコンテナの内のある特定のストレージコンテナ内のオブジェクトを参照する所与のファイルの削除の検出に応答して、サーバは、この所与のファイルの識別をストレージコンテナ参照リストから除去することによって、ストレージコンテナ参照リストを更新するように構成されている。セグメントオブジェクトを、それらのセグメントオブジェクトを参照するファイルと関連付ける参照リストは、削除に応答して更新されなくてもよい。
2013541083.tif 000002
【特許請求の範囲】
【請求項１】
データストレージを管理するためのシステムであって、
複数のストレージオブジェクトを複数のストレージコンテナに保存するように構成されたストレージデバイスであって、前記ストレージコンテナの各々は、複数の前記ストレージオブジェクトを保存するように構成された、ストレージデバイスと、
ストレージコンテナ参照リストであって、前記ストレージコンテナの各々に関して、前記ストレージコンテナ参照リストは、複数のファイルの内のどのファイルが、所与のストレージコンテナ内のストレージオブジェクトを参照するかを識別する、ストレージコンテナ参照リストと、
サーバであって、前記ストレージコンテナの内のある特定のストレージコンテナ内のオブジェクトを参照する所与のファイルの削除の検出に応答して、前記所与のファイルの識別を前記ストレージコンテナ参照リストから除去することによって、前記ストレージコンテナ参照リストを更新するように構成されているサーバと、
を含む、システム。
【請求項２】
前記サーバは、セグメントオブジェクト参照リストを維持するようにさらに構成され、前記ストレージデバイスに保存された所与のセグメントオブジェクトに関して、前記セグメントオブジェクト参照リストは、前記複数のファイルの内のどのファイルが前記所与のセグメントオブジェクトを参照するかを識別する、請求項１に記載のシステム。
【請求項３】
所与のコンテナを参照するファイルの数が閾値レベルを下回ったことの決定に応答して、前記サーバは、ファイル削除の検出に応答して、前記コンテナ参照リストの代わりに、前記セグメントオブジェクト参照リストを更新するように構成されている、請求項２に記載のシステム。
【請求項４】
前記セグメントオブジェクト参照リストを更新する際に、前記サーバは、前記セグメントオブジェクト参照リストから、前記所与のファイルによって参照されるセグメントオブジェクトのエントリを削除するように構成されている、請求項３に記載のシステム。
【請求項５】
前記削除の検出に応答して、前記サーバは、前記セグメントオブジェクト参照リストを更新しない、請求項２に記載のシステム。
【請求項６】
前記サーバは、少なくとも部分的に、前記ストレージデバイスのストレージ利用及び前記ストレージコンテナ参照リストのサイズに基づいて、前記閾値の値を決定するようにさらに構成されている、請求項３に記載のシステム。
【請求項７】
ストレージデバイスに、複数のストレージオブジェクトを複数のストレージコンテナに保存するステップであって、前記ストレージコンテナの各々は、複数の前記ストレージオブジェクトを保存するように構成されている、ステップと、
ストレージコンテナ参照リストを維持するステップであって、前記ストレージコンテナの各々に関して、前記ストレージコンテナ参照リストは、複数のファイルの内のどのファイルが、所与のストレージコンテナ内のストレージオブジェクトを参照するかを識別する、ステップと、
前記ストレージコンテナの内のある特定のストレージコンテナ内のオブジェクトを参照する所与のファイルの削除の検出に応答して、前記ストレージコンテナ参照リストから、前記所与のファイルの識別を除去するステップと、
を含む、コンピュータ実施方法。
【請求項８】
セグメントオブジェクト参照リストを維持するステップをさらに含み、前記ストレージデバイスに保存された所与のセグメントオブジェクトに関して、前記セグメントオブジェクト参照リストは、前記複数のファイルの内のどのファイルが前記所与のセグメントオブジェクトを参照するかを識別する、請求項７に記載の方法。
【請求項９】
所与のコンテナを参照するファイルの数が閾値レベルを下回ったことの決定に応答して、前記方法は、ファイル削除の検出に応答して、前記コンテナ参照リストの代わりに、前記セグメントオブジェクト参照リストを更新するステップを含む、請求項８に記載の方法。
【請求項１０】
前記セグメントオブジェクト参照リストを更新する際に、前記方法は、前記セグメントオブジェクト参照リストから、前記所与のファイルによって参照されるセグメントオブジェクトのエントリを削除するステップを含む、請求項９に記載の方法。
【請求項１１】
前記ストレージコンテナ参照リストは、粗いレベルでコンテナのグループに関連するエントリを含み、前記コンテナのグループ内に保存された少なくとも１つのセグメントオブジェクトを参照するファイルごとに別個の粗いレベルのエントリを有する、請求項１に記載のシステム又は請求項９に記載の方法。
【請求項１２】
プログラム命令を含むコンピュータ可読ストレージ媒体であって、実行されると、前記プログラム命令は、
ストレージデバイスに、複数のストレージオブジェクトを複数のストレージコンテナに保存するように動作可能であり、前記ストレージコンテナの各々は、複数の前記ストレージオブジェクトを保存するように構成されており、
ストレージコンテナ参照リストを維持するように動作可能であり、前記ストレージコンテナの各々に関して、前記ストレージコンテナ参照リストは、複数のファイルの内のどのファイルが、所与のストレージコンテナ内のストレージオブジェクトを参照するかを識別し、
前記ストレージコンテナの内のある特定のストレージコンテナ内のオブジェクトを参照する所与のファイルの削除の検出に応答して、前記ストレージコンテナ参照リストから、前記所与のファイルの識別を除去するように動作可能である、
コンピュータ可読ストレージ媒体。
【請求項１３】
実行されると、前記プログラム命令は、セグメントオブジェクト参照リストを維持するようにさらに動作可能であり、前記ストレージデバイスに保存された所与のセグメントオブジェクトに関して、前記セグメントオブジェクト参照リストは、前記複数のファイルの内のどのファイルが前記所与のセグメントオブジェクトを参照するかを識別する、請求項１２に記載のコンピュータ可読ストレージ媒体。
【請求項１４】
前記複数のファイルのサブセットをバックアップにグループ化し、前記ストレージコンテナの各々に関して、前記ストレージコンテナリストは、前記バックアップの内のどのバックアップが前記所与のストレージコンテナ内のセグメントオブジェクトを参照するファイルを含むかを識別する、請求項１に記載のシステム、請求項９に記載の方法、又は請求項１６に記載のコンピュータ可読ストレージ媒体。
【請求項１５】
前記削除の検出及び前記所与のコンテナを参照するファイルの数が所与の閾値を下回ったことの決定に応答して、前記セグメントオブジェクト参照リストは更新されない、請求項１２に記載のコンピュータ可読ストレージ媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般的に、バックアップストレージシステムに関し、特に、重複排除に基づくストレージシステムにおけるリソース再利用の促進に使用される参照リストに関する。
【背景技術】
【０００２】
組織は、膨大な量の電子データの蓄積及び保存を行っている。その結果、バックアップストレージシステムは、サイズが増大し、大量のリソースを消費している。増加の一途をたどる量のデータ保存に対処するために、重複排除は、バックアップストレージシステムにおいてストレージの利用を最大限に高めるための重要な特性となっている。一般的な重複排除システムにおいては、ファイルは、データセグメントに分割され、冗長データセグメントは、システムから削除される。その後、一つしか存在しないデータセグメントが、セグメントオブジェクトとしてバックアップストレージ媒体に保存される。保存されたセグメントオブジェクトの数が増加するにつれ、セグメントオブジェクトの管理は、システムリソースの占有率の増加を必要とし、これは、重複排除システムの全体的な効率及び性能に影響を与え得る。
【０００３】
重複排除に基づくシステムは、大量のデータを保存するために必要とされるストレージ容量の量を減少させることを目的としている。重複排除技術は、保存データ量の大幅な減少を達成できるところまで成熟化している。しかしながら、このような技術が必要とされる記憶空間を縮小し得る一方で、システムに保存されるセグメントオブジェクトの数は、それでもやはり増加し続ける場合がある。より高いデータ負荷に対処するために重複排除システムが拡大するので、セグメントオブジェクトの管理及びインデックス作成は、システムの性能に影響を与える重要な要因となり得る。
【０００４】
一般的に、セグメントオブジェクトは、サイズが小さく、一部のシステムでは、４キロバイト（ＫＢ）ほどの大きさしかない。４００テラバイト（ＴＢ）のデータを保存するシステムの場合、全てのセグメントオブジェクトが４ＫＢのサイズであるとすると、１０００億のセグメントオブジェクトが維持される。ストレージ要求が増大するにつれ、セグメントオブジェクト数の増加は、受け入れられない管理オーバーヘッドを生じさせる場合がある。従って、大量のセグメントオブジェクトを効率的に保存及び管理するためには、高度にスケーラブルな管理システムが必要とされる。
【０００５】
特に困難な問題は、ファイルがシステムから削除された後のリソースの再利用に関する。ファイルが削除される際、このファイルを構成するセグメントオブジェクトは、システムが保存する他のファイルが、これらと同じセグメントオブジェクトの内の１つ又は複数を参照する可能性があるので、単純に削除することはできない。これらのセグメントオブジェクトを使用するファイルが他に存在しない場合にだけ、それらを削除することができる。セグメントオブジェクト及びセグメントオブジェクトを使用する全てのファイルの記録をとるために、何らかの管理形式が必要となる。セグメントオブジェクト及びそれらを指し示すファイルを管理するために使用される様々な技術が存在し、それらの大部分は、小規模で行われる場合には、ある程度上手く機能し得る。しかしながら、これらの手法の多くは、多数のセグメントオブジェクトを扱う場合には、効率的ではない場合がある。
【０００６】
リソースの再利用を促進するために使用される技術の１つは、セグメントオブジェクトのリファレンスカウントである。リファレンスカウントは、何個のファイルがそのセグメントを指し示す、又は使用するかを示す値を保存する。所与のセグメントオブジェクトのリファレンスカウントは、ファイルによってそれが使用される度にインクリメントし、そのセグメントを用いるファイルが削除されるとデクリメントする、すなわち、最終的に、カウントがゼロまで低下すると、そのセグメントは再利用され得る。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
リファレンスカウントは、重複排除には不向きとなる幾つかの制限を有する。制限の１つは、更新が失われる、又は繰り返されると、カウントが不正確に変更されることである。カウントが誤って減少すると、セグメントは、少なくとも１つのファイルによってまだ使用中である間に削除される場合がある。カウントが誤って増加すると、そのセグメントは、それを使用するファイルの全てがシステムから削除された後であっても、決して削除されない場合がある。
【０００８】
リファレンスカウントのさらなる欠点は、どのファイルが特定のセグメントオブジェクトを使用するかの識別が可能ではない点である。所与のセグメントオブジェクトが破損した場合、バックアップシステムは、破損したデータを復元するためにファイルを要求できるように、どのファイルがそれを使用しているかを知る必要がある。しかしながら、リファレンスカウントは、どのファイルが各特定のセグメントオブジェクトを使用しているかのリストを維持しないので、破損データの復元がより困難となる。
【０００９】
リソースの再利用を促進するために使用可能な別のツールは、参照リストである。参照リストの維持は、リファレンスカウント固有の欠点に悩まされることはない。参照リストは、追加又は除去操作が既に行われたかどうかを確かめるためにリストが検索され得るので、間違った更新に対してより大きな免疫を有し得る。また、参照リストは、どのファイルが各セグメントオブジェクトを使用しているかを識別する機能を有する。しかしながら、参照リストは、多数のセグメントオブジェクトを扱うために、容易にスケーラブルとなるものではない。従来、参照リストは、保存される各セグメントオブジェクトに応じて、細かいレベルで管理される。セグメントオブジェクトの数が増加するにつれて、参照リストの更新は、より長い時間がかかり、それによって、システムの性能が鈍くなる場合がある。必要なのは、多数のセグメントオブジェクトを効率的に管理できる参照リストを維持するための新しい方法である。
【００１０】
上記を鑑みて、重複排除システムにおいて参照リストを管理するための改良された方法及び機構が望まれる。
【課題を解決するための手段】
【００１１】
重複排除に基づくストレージシステムにおいて参照リストを効率的に管理するための方法及び機構の様々な実施形態が検討される。ある実施形態では、参照リストは、バックアップストレージ媒体に保存されたコンテナごとに、粗いレベルのエントリで構成されてもよい。ある特定のコンテナ内に保存された少なくとも１つのセグメントオブジェクトで構成されている各ファイルは、参照リスト中に、その特定のコンテナに関するエントリを有し得る。ファイルが重複排除に基づくストレージシステムに追加される、又は重複排除に基づくストレージシステムから削除される際に、エントリが参照リストに追加される、又は参照リストから削除されてもよい。別の実施形態では、参照リストは、コンテナに関する粗いレベルのエントリ、及びコンテナ内に保存されたセグメントオブジェクトに関する細かいレベルのエントリから構成されてもよい。参照リストは、ストレージシステムからのファイルの削除の結果、セグメントオブジェクトエントリの更新を行うことなくコンテナエントリが更新され得るような粗いレベルで管理されてもよい。ある特定のコンテナに関する粗いレベルのエントリの数が減少するにつれ、最終的には、その数が閾値を下回り、この時点で、サーバは、この特定のコンテナに関するリストの管理を細かいレベルに切り替えてもよい。細かいレベルでの参照リストの管理は、ファイルがシステムから削除される度に、セグメントオブジェクトエントリの更新を伴い得る。
【００１２】
さらなる実施形態では、参照リストは、各エントリをファイルに関連付ける代わりに、各エントリをバックアップトランザクションと関連付けてもよい。バックアップトランザクションは、１つのバックアップ操作に関して重複排除に基づくストレージシステムへと単一のクライアントによって送信された全てのファイルを含み得る。参照リストは、バックアップストレージ媒体に保存された各コンテナに関する粗いレベルのエントリから構成され得る。ある特定のコンテナ内に保存された少なくとも１つのセグメントオブジェクトから構成されている各バックアップトランザクションは、その特定のコンテナに関するエントリを参照リスト中に有し得る。またさらなる実施形態では、参照リストは、バックアップトランザクションが参照する各コンテナに関する粗いレベルのエントリと、バックアップトランザクションが参照する各セグメントオブジェクトに関する細かいレベルのエントリとを有していてもよい。参照リストは、ある特定のコンテナに関する粗いレベルのエントリの数が閾値を下回るまでは、粗いレベルでのみ更新され、閾値を下回った時点で、サーバは、その特定のコンテナに関する細かいレベルでのリスト管理へと切り替えてもよい。バックアップトランザクションに応じて参照リストを編成することにより、リスト内のエントリの量がさらに減少し、バックアップトランザクションのシステムへの追加又はシステムからの削除に応答してリストを処理するために必要な処理時間が減少し得る。
【００１３】
これら及び他の特徴や利点は、本明細書に提示される手法の以下の詳細な説明を考慮すれば、当業者には明らかとなるであろう。
【００１４】
これらの方法及び機構の上記及びさらなる利点は、添付の図面と併せて以下の記載を参照することによって、より深く理解することができる。
【図面の簡単な説明】
【００１５】
【図１】重複排除に基づくストレージシステムの一実施形態を示す。
【図２】バックアップストレージのコンテナ内にセグメントオブジェクトとして保存されているバックアップトランザクションの一実施形態を示す。
【図３】ファイル及び関連のセグメントオブジェクトの参照の一実施形態を示す。
【図４】セグメントオブジェクトを保存するコンテナと、コンテナ参照リストの２つの実施形態を示す。
【図５】粗い及び細かいレベルのエントリを有するファイル指向の参照リストの一実施形態を示す。
【図６】ストレージコンテナ参照リストを維持する方法の一実施形態を示す。
【図７】第１の削除操作後の参照リストの一実施形態を示す。
【図８】第２の削除操作後の参照リストの一実施形態を示す。
【図９】バックアップトランザクションのエントリを有するバックアップ指向の参照リストの一実施形態を示す。
【図１０】ファイルの追加又は削除操作に続いて参照リストを更新する方法の一実施形態を示す一般化フロー図である。
【図１１】参照リストを更新する方法の一実施形態を示す一般化フロー図である。
【発明を実施するための形態】
【００１６】
以下の説明では、本明細書に提示する方法及び機構の十分な理解を提供するために、多数の具体的詳細を記載する。しかしながら、これらの具体的詳細を用いることなく様々な実施形態を実施してもよいことを当業者は理解するべきである。場合によっては、周知の構造、構成要素、信号、コンピュータプログラム命令、及び技術は、本明細書に記載される手法を分かりにくくすることを避けるために、詳細に示されていない。
【００１７】
図示を単純化及び明瞭にするために、図面に示される要素は、必ずしも一定の縮尺で描かれていないことは明らかである。例えば、一部の要素の寸法は、他の要素と比較して誇張されている場合がある。さらに、適切であると考えられる場合には、対応する要素を示すために、図面間で参照符号を繰り返している。
【００１８】
図１は、重複排除に基づくストレージシステム１００の一実施形態を示す。重複排除に基づくストレージシステム１００は、任意の数の移動又は固定クライアントを表すクライアント１１０、１２０、及び１３０を含む。この図は、クライアントとして、２つのデスクトップコンピュータと、１つのラップトップコンピュータとの例を示すが、携帯情報端末、携帯電話、スマートフォン、デジタルカメラ、ビデオカメラ、ワイヤレス書籍端末、及びデータの送受信が可能な他の種類の電子デバイスを含む他のクライアントデバイスが可能であり、検討される。図１に示されるように、クライアントは、それを介して重複排除サーバ１５０にも接続されるネットワーク１４０に接続される。重複排除サーバ１５０は、クライアント１１０、１２０、及び１３０に共有データへのアクセスを提供すること、及び必要不可欠なデータをバックアップすること等の様々な異なる目的のために使用され得る。
【００１９】
一般的に、重複排除サーバ１５０は、どのような種類の物理的コンピュータ又は計算装置でもよい。重複排除サーバ１５０は、１つ又は複数の中央処理装置（ＣＰＵ）、システムメモリ（ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、フラッシュＲＡＭ等）、入出力（Ｉ／Ｏ）装置、ハードディスク等の永続的なストレージデバイス、及びコンピュータに一般的に含まれる他の周辺機器等の、サーバ１５０の主要サブシステム又は構成要素を相互接続することができるバスを包含していてもよい。重複排除サーバ１５０は、分散型アーキテクチャを有していてもよく、あるいは、その構成要素の全てが単一の装置に統合されていてもよい。重複排除サーバ１５０は、ソフトウェアの処理及びアプリケーションを実行するオペレーティングシステムをホストしてもよく、ソフトウェアは、サーバの１つ又は複数のＣＰＵで実行され、サーバのメモリに保存されてもよい。また、重複排除に基づくストレージシステム１００は、１つ又は複数の重複排除サーバ１５０を含んでいてもよい。
【００２０】
重複排除サーバ１５０は、クライアント１１０、１２０、及び１３０からのデータが保存され得るバックアップストレージ１６０にも接続され得る。バックアップストレージ１６０は、ハードディスクドライブ、光学式ドライブ、磁気テープドライブ、リムーバブルディスクドライブ等の様々な種類の１つ又は複数のデータストレージデバイスを含み得る。バックアップストレージ１６０は、参照リスト１７０を保存してもよく、参照リスト１７０は、重複排除サーバ１５０によって管理されてもよい。別の実施形態では、参照リスト１７０は、重複排除サーバ１５０のメモリに保存されてもよい。さらなる実施形態では、参照リスト１７０は、重複排除サーバ１５０以外のエンティティによって管理及び保存されてもよい。参照リスト１７０は、バックアップストレージ１６０に保存されたセグメントオブジェクトの各々を、クライアント１１０、１２０、及び１３０からの何個のファイル又はバックアップトランザクションが使用しているかを重複排除サーバ１５０が記録するための方法を提供することができる。
【００２１】
ある実施形態では、参照リスト１７０は、バックアップストレージ１６０に保存されたコンテナに関する粗いレベルのエントリを包含し得る。コンテナは、データストレージの多数の割り当てられたユニットを含むファイルシステムの可変サイズ部分に関連する論理エンティティであり得る。また、コンテナは、バックアップストレージ媒体における物理的位置にマッピングされ得る。バックアップストレージ媒体内の各々のコンテナごとに、参照リスト１７０は、その特定のコンテナ内に保存された複数のセグメントオブジェクトの内の１つ又は複数を参照する各別個のファイルに関する異なる粗いレベルのエントリを含み得る。従って、あるコンテナは、そのコンテナ内の少なくとも１つのセグメントオブジェクトを参照する別個のファイルの数に等しい、多数の粗いレベルのエントリを有し得る。別の実施形態では、参照リストは、コンテナ内に保存されたセグメントオブジェクトに関する細かいレベルのエントリも包含し得る。コンテナ内に保存された各々のセグメントオブジェクトごとに、参照リストは、その特定のセグメントオブジェクトを参照する各ファイルに関する細かいレベルのエントリを包含し得る。従って、セグメントオブジェクトは、そのセグメントオブジェクトを参照する別個のファイルの数に等しい、多数の細かいレベルのエントリを参照リスト内に有し得る。
【００２２】
ネットワーク１４０に接続されたクライアントの１つ又は複数は、他のクライアントのサーバとしても機能し得る。本明細書に記載する手法は、Ｅｔｈｅｒｎｅｔネットワーク、Ｆｉｂｅｒ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｄａｔａ  Ｉｎｔｅｒｆａｃｅ（ＦＤＤＩ）ネットワーク、トークンリングネットワーク、及び電気電子技術者協会（Ｉｎｓｔｉｔｕｔｅ  ｏｆ  Ｅｌｅｃｔｒｉｃａｌ  ａｎｄ  Ｅｌｅｃｔｒｏｎｉｃｓ  Ｅｎｇｉｎｅｅｒｓ）（ＩＥＥＥ）の８０２．１１基準（Ｗｉ−Ｆｉ）に基づくワイヤレス・ローカル・エリア・ネットワーク（ＷＬＡＮ）等のローカル・エリア・ネットワーク（ＬＡＮ）、及びインターネット、セルラーデータネットワーク、及び他のデータ通信ネットワーク等の広域ネットワーク（ＷＡＮ）の組み合わせを含む様々なネットワークにおいて利用することができる。本明細書に記載の手法に使用されるネットワークは、特定のネットワーク各々の固有のストレージ及びバックアップ要求次第で、複数のバックアップストレージ媒体１６０を含んでいてもよい。バックアップストレージ１６０に関連するストレージ媒体は、限定されることはないが、ネットワーク接続ストレージ環境、ストレージ・エリア・ネットワーク（ＳＡＮ）、及び重複排除サーバ１５０に直接接続されるディスクアセンブリを含む様々なストレージアーキテクチャに応じて実現され得る。
【００２３】
クライアント１１０、１２０、及び１３０は、ネットワーク１４０上でデータを重複排除サーバ１５０へと送信することができる。データは、クライアント１１０、１２０、及び１３０に保存されたデータを１つ又は複数の所定サイズの断片へと分割することによって作成されたデータセグメントの形式で送信されてもよい。様々な実施形態において、クライアントは、バックアップ操作において支援を行うソフトウェアを含み得る（例えば、バックアップエージェント）。一部の実施形態では、重複排除サーバ１５０は、受信データの重複排除を行ってもよい。一般的に、重複排除は、受信したデータセグメントが既にバックアップストレージ１６０に保存されているかの決定を伴う。データセグメントがバックアップストレージ１６０に既に保存されている場合には、受信したデータセグメントを破棄し、その場所に、保存済みデータセグメント（セグメントオブジェクトとも呼ばれる）に対するポインタを使用してもよい。このように、重複排除サーバ１５０は、バックアップストレージ１６０内に、どのようなセグメントオブジェクトも単一のコピーのみを維持しようとしてもよい。他の実施形態では、新しいデータセグメントのみが重複排除サーバ１５０に送信され、全ての冗長データセグメントがクライアント１１０、１２０、及び１３０において削除され得るように、重複排除プロセスは、データセグメントが重複排除サーバ１５０に送信される前に行ってもよい。重複排除に基づくストレージシステム１００は、クライアント及びサーバを含むものとして示されているが、代替の実施形態では、クライアント及びサーバによって行われる機能は、ピアツーピア構成におけるピア、あるいは、クライアント、サーバ、及びピアの組み合わせによって行われてもよい。
【００２４】
他の実施形態では、データは、完全なデータファイルとして、イメージファイル又はボリュームからコピーした複数のデータファイルとして、バーチャル・マシン・ディスク・ファイル（ＶＭＤＫ）として、バーチャル・ハード・ディスク（ＶＨＤ）として、ＳＹＭＡＮＴＥＣ（登録商標）のＢａｃｋｕｐＥｘｅｃソフトウェア製品によって作成されたディスクイメージファイル（．Ｖ２Ｉ）として、データファイルをローディスクパーティションとして保存するためのＶＭＤＫファイルをさらに含む．ＴＡＲアーカイブファイルとして、又は、それ以外にクライアント１１０、１２０、及び１３０によってフォーマットされ得るように、クライアント１１０、１２０、及び１３０から重複排除サーバ１５０へと送信されてもよい。
【００２５】
これより図２を参照すると、重複排除に基づくストレージシステムが示されている。クライアント１１０は、ネットワーク１４０を介して、重複排除サーバ１５０に接続される。重複排除サーバ１５０は、参照リスト１７０およびクライアント１１０からのデータをセグメントオブジェクト２３１〜２３９として論理データストレージコンテナ２１０内に保存するバックアップストレージ１６０に接続される。１つのコンテナ内には、どのような数のセグメントオブジェクトも保存することができる。さらに、セグメントオブジェクト２３１〜２３９は、様々なサイズを有していてもよい。別の実施形態では、セグメントオブジェクト２３１〜２３９は、同じサイズのものでもよい。
【００２６】
クライアント１１０は、クライアント１１０がバックアップストレージ１６０に保存されるように重複排除サーバ１５０に送信し得る、単一のバックアップトランザクション２５０を構成するファイル２４１〜２４４のグループを有する。ファイル２４１〜２４４は、クライアント１１０から重複排除サーバ１５０への送信前、又は後に、様々なサイズのデータセグメントへと分割されてもよい。また、データセグメントは、クライアント１１０によって、又は重複排除サーバ１５０によって重複排除されてもよい。ある実施形態では、バックアップトランザクション２５０は、単一のバックアップ操作において単一のクライアントによってバックアップされた全てのファイルを含み得る。別の実施形態では、バックアップトランザクション２５０は、単一のクライアントから、又は複数のクライアントからの複数のファイルを含み得る。さらなる実施形態では、バックアップトランザクション２５０は、少なくとも部分的に複数のファイルによって参照されるセグメントオブジェクトの近接性に基づいて一緒にグループ化された複数のファイルをバックアップストレージ媒体１６０内に含み得る。バックアップトランザクションへのファイルの他のグループ化が可能であり、検討される。
【００２７】
重複排除サーバ１５０は、バックアップトランザクション２５０から作成された重複排除済みデータセグメントをバックアップストレージ１６０内にセグメントオブジェクト２３１〜２３９として保存することができる。重複排除サーバ１５０は、セグメントオブジェクト２３１〜２３９を保存するためのコンテナ２１０を作成することができる。重複排除サーバ１５０は、バックアップストレージ１６０内に追加のコンテナを作成することもできる。ある実施形態では、コンテナは全て同じサイズでもよい。別の実施形態では、コンテナは、可変サイズのものでもよい。
【００２８】
これより図３を参照すると、ファイルグループ２６０及び関連のセグメントオブジェクトの参照２７０が示されている。ファイル２４１〜２４４は、ボックス２６０内のセグメントオブジェクト２３１〜２３９から再構築したように示されている。（図２の）クライアント１１０からのファイル２４１〜２４４は、データセグメントに分割され、その後、データセグメントは、（図２の）バックアップストレージ１６０内にセグメントオブジェクト２３１〜２３９として保存され得る。セグメントオブジェクト２３１〜２３９の各々は、２つ以上のファイルによって参照される場合がある。
【００２９】
図示された例では、ファイル２４１は、５つのセグメントオブジェクト：２３１、２３４、２３５、２３６、及び２３７を含む、又はそれらから再構築され得る。ファイル２４２は、７つのセグメントオブジェクト：２３１、２３３、２３４、２３６、２３７、２３８、及び２３９から再構築され得る。ファイル２４３は、６つのセグメントオブジェクト：２３１、２３２、２３４、２３５、２３７、及び２３８から再構築され得る。ファイル２４４は、４つのセグメントオブジェクト：２３１、２３２、２３３、及び２３４から再構築され得る。セグメントオブジェクトのほとんどは、４つのファイル２４１〜２４４によって２回以上参照されるが、各セグメントオブジェクトの１つのコピーのみが、バックアップストレージ１６０において、（図２の）コンテナ２１０内に保存され、それによって、４つのファイル２４１〜２４４を保存するために必要とされる総ストレージ容量が減少する。
【００３０】
図３にはセグメントオブジェクトの参照２７０も示されており、セグメントオブジェクト２３１〜２３９の各々は、そのセグメントオブジェクトを参照する関連のファイルリストを有する。参照リスト２７０に関して多数の可能な実施形態が考えられる。例えば、ある実施形態では、ファイルのリンクリストを各セグメントオブジェクトの識別子と関連付けてもよい。Ｂツリー構造又はその他の方法を使用して、リスト２７０の保存及び維持を行ってもよい。このような多数の実施形態が可能であり、検討される。ある実施形態では、あるファイルが削除されると、削除されたファイルを識別するエントリ／エンティティを除去するために、セグメントオブジェクトの識別子２３１〜２３９のトラバースが行われ得る。理解され得るように、１つ又は複数のデータ構造２７０を完全に更新するためには、多くのエントリのトラバースを行う必要がある場合がある。一般的に言えば、このような削除に関連するオーバーヘッドは比較的高い。以下の説明では、代替の手法を説明する。
【００３１】
これより図４を参照すると、セグメントオブジェクト２３１〜２３９を包含するコンテナ２１０がボックス２８０内に示されている。一般的に言えば、システム内に保存された全てのセグメントオブジェクトは、コンテナ内に論理的に保存することができる。図示した単純な例では、コンテナ２１０は、６つのセグメントオブジェクトを含む。しかしながら、コンテナは、どのような数のセグメントオブジェクト、すなわち、数百、数千、又はそれ以上をも含むように構成することができる。その結果、コンテナの数は、セグメントオブジェクトの数の何分の１かである。上記に加えて、（図２の）コンテナ２１０のコンテナ参照リスト１７０の２つの実施形態をボックス２９０内に示す。第１の実施形態は、リンクリストとして示されており、第２の実施形態は、テーブルとして示されている。
【００３２】
コンテナ参照リストは、コンテナ内のセグメントオブジェクトを参照する各ファイルを識別する。コンテナ参照リスト１７０の第１の実施形態は、ファイル２４１〜２４４に関連するコンテナ参照２１０として描かれ、各ファイルは、コンテナ内に保存された少なくとも１つのセグメントオブジェクトを参照する。上記のセグメントオブジェクト参照リストと同様に、コンテナ参照リストを維持するために、任意の適切なデータ構造を利用することができる。図示した第１の実施形態では、コンテナ識別子２１０がコンテナ２１０内のセグメントオブジェクトを参照するファイル識別子のリンクリストを有するリンクリスト型構造が描かれている。前述同様に、Ｂツリー、二重連結リスト、及び他のデータ構造を利用してもよい。「コンテナ」及び「ファイル」のヘッダを有するコンテナ参照リスト１７０は、コンテナ２１０に関する粗いレベルのエントリを含む。このコンテナ参照リスト１７０は、例示目的でのみ提示されるものであり、本明細書に記載の方法及び機構に従って、コンテナ参照リストを実現する他の方法を利用してもよい。本明細書に記載の参照リストが１つ又は複数のリスト又は構造として維持され得ることにも留意されたい。複数のリストが維持される場合には、与えられたリストは、特定のデータセット、特定のデータタイプ、データのユーザ、特定のバックアップ等に関連付けられ得る。
【００３３】
リンク型構造に加えて、より配列指向型の構造を利用し得る。例えば、ある実施形態では、動的に配置可能なｎ次元配列を利用し得る。図４の例では、ファイル２４１〜２４４の各々のエントリを有する、コンテナ２１０に関する２次元配列が示されている。この様に、コンテナ２１０に保存されたセグメントオブジェクトの少なくとも１つを参照する各ファイルの粗いレベルのエントリが参照リスト１７０に存在する。４つのファイル２４１〜２４４がコンテナ２１０に保存されたセグメントオブジェクトを参照する。その結果、参照リストにおいて、コンテナ２１０に関する４つの粗いレベルのエントリが、コンテナ内に保存されたセグメントオブジェクトを参照するファイルの各々に対して１つずつ、存在する。
【００３４】
上述の通り、上記のようなコンテナ参照リストは、ストレージシステムにおけるセグメントオブジェクト参照リストのエントリのほんの一部を有する。このようなコンテナ参照ストレージリストを利用して、ずっと少ないオーバーヘッドで参照リストを維持する方法をこれより説明する。図５は、「ファイル指向の」コンテナ参照リストを維持する方法の概要の一実施形態を示す。コンテナリストは、コンテナ内の少なくとも１つのオブジェクトを参照するファイルのリストを各コンテナが有するので、ファイル指向であると言われる。既に述べたように、セグメントオブジェクト参照リストのトラバース及び維持は、比較的大量のオーバーヘッドを伴い得る。特にファイルを削除する際には、セグメントオブジェクト参照リストのトラバース及び更新は、比較的時間がかかり得る。このような手法の代替手段として、以下の方法は、セグメントオブジェクト参照がしばしば無視される手法を説明する。この様にして、このようなリストの維持に関連するオーバーヘッドが低減される。
【００３５】
図５の方法は、ファイル操作の検出から始まる（ブロック５１０）。その操作がファイル削除操作でなければ（決定ブロック５１５）、ファイルを分割し、システム内に既に保存された一致するオブジェクトの検索を行ってもよく（ブロック５４０）、これは、重複排除ストレージシステムにおける場合などであり得る。既に保存された一致するセグメントオブジェクトが存在する場合（決定ブロック５４５）、そのファイルの識別が、一致するセグメントオブジェクトを含むコンテナのコンテナ参照リストに加えられ（ブロック５６５）、処理を行うべき残りのファイルのデータセグメントが存在する場合（決定ブロック５７０）には、プロセスを繰り返してもよい。一方、既に保存された一致するセグメントオブジェクトが存在しない場合（決定ブロック５４５）、データは新しいセグメントオブジェクトとしてシステムに保存され、新しいセグメントオブジェクトを含むコンテナに関して、ファイルの識別を含むようにコンテナ参照リストを更新してもよい（ブロック５５０）。
【００３６】
検出されたファイル操作がファイル削除操作であることが判明すると（決定ブロック５１５）、ファイルの識別がコンテナ参照リストから除去される（ブロック５３０）。ある実施形態では、この時、セグメントオブジェクト参照リストは更新又は維持されないことに留意されたい。正しくは、削除されたファイルを反映するためにコンテナ参照リストのみが更新される。システム内ではセグメントオブジェクトと比較してコンテナがずっと少ないので、コンテナ参照リストは、セグメントオブジェクト参照リストのエントリの何分の１かを含み、コンテナ参照リストの更新に関連するオーバーヘッドは、セグメントオブジェクトリストのものと比較してずっと少ない。以下の説明では、コンテナ及びセグメントオブジェクト参照リストの維持を示す幾つかの例を示す。説明を簡単にするために、この例は、リスト及びエントリを配列形式で示す。しかしながら、上述のように、実際の実施は、リンク構造、ツリー構造、又はその他の方法のものでもよい。さらに、説明では、単一のリストの一部として、粗いエントリ及び細かいエントリを説明する場合があるが、実際には維持される複数のリストが存在し得ることを理解されたい。
【００３７】
これより図６を参照すると、粗い及び細かいレベルのエントリを持つ（図２の）コンテナ２１０に関する参照リスト５００が示されている。図４の場合のように、テーブル及びリンクリスト形式の両方が示されている。参照リスト５００は、（図２の）バックアップストレージ１６０内に存在し得るコンテナ２１０に関する粗いレベルのエントリと、コンテナ２１０内に保存されたセグメントオブジェクトに関する細かいレベルのエントリとを含む。別の実施形態では、参照リスト５００は、バックアップストレージ１６０に保存された複数のコンテナに関するエントリを含み得る。さらなる実施形態では、参照リスト５００は、バックアップストレージ１６０に保存された全てのコンテナに関するエントリを包含することができる。またさらなる実施形態では、（図２の）重複排除サーバ１５０は、バックアップストレージ１６０に保存されたコンテナごとに別個の参照リストを維持してもよい。
【００３８】
コンテナ２１０に保存されたセグメントオブジェクトの内の少なくとも１つを参照する各ファイルの粗いレベルのエントリが参照リスト５００内に存在する。（図３の）４つのファイル２４１〜２４４は、コンテナ２１０に保存されたセグメントオブジェクトを参照し、従って、参照リストにコンテナ２１０に関する４つのエントリが存在し、コンテナ内に保存されたセグメントオブジェクトを指し示すファイルの各々につき１つのエントリである。コンテナ２１０に関するこれらのエントリは、参照リスト５００の粗いレベルのエントリである。各セグメントオブジェクトに関するエントリは、参照リスト５００の細かいレベルのエントリである。各セグメントオブジェクトは、それを参照する各ファイルに関する細かいレベルのエントリを包含し得る。ファイルによるセグメントオブジェクトの参照は、読み出し又は復元操作中にこのファイルを再作成するためにこのセグメントオブジェクトが使用され得る場合、又は、このセグメントオブジェクトが、このファイルを構成するデータの一部を成す場合に行われ得る。
【００３９】
セグメントオブジェクト２３１は、参照リスト５００内に、それを指し示す４つのファイル（２４１〜２４４）に関する４つの細かいレベルのエントリを含む。さらに、セグメントオブジェクト２３２は、リスト内に、ファイル２４３及び２４４の２つの細かいレベルのエントリを含み、セグメントオブジェクト２３３は、ファイル２４２及び２４４の２つの細かいレベルのエントリを含み、セグメントオブジェクト２３４は、ファイル２４１〜２４４の４つの細かいレベルのエントリを含み、セグメントオブジェクト２３５は、ファイル２４１及び２４３の２つの細かいレベルのエントリを含み、セグメントオブジェクト２３６は、ファイル２４１及び２４２の２つの細かいレベルのエントリを含み、セグメントオブジェクト２３７は、ファイル２４１〜２４３の３つの細かいレベルのエントリを含み、セグメントオブジェクト２３８は、ファイル２４２及び２４３の２つの細かいレベルのエントリを含み、セグメントオブジェクト２３９は、ファイル２４２の１つの細かいレベルのエントリを含む。
【００４０】
図６に示されるように、参照リスト５００において、細かいレベルのエントリは、粗いレベルのエントリの後に来てもよい。ある実施形態では、参照リスト５００が２つ以上のコンテナに関するエントリを含む場合には、第１のコンテナに関する粗い及び細かいレベルのエントリは、一緒にグループ化され、第２のコンテナに関する粗い及び細かいレベルのエントリが後に続き、残りのコンテナに関しても同様であってもよい。別の実施形態では、全てのコンテナに関する粗いレベルのエントリが一緒にグループ化され、全てのコンテナに関する全ての細かいレベルのエントリが後に続いてもよい。粗い及び細かいレベルのエントリを一緒にグループ化し、参照リスト５００を編成する他の方法が可能であり、検討される。
【００４１】
これより図７を参照すると、ストレージシステムからのファイル２４３の削除に続いてリストが更新された後のコンテナ２１０に関する参照リスト５００が示されている。ここでも、テーブル及びリンクリスト形式の両方が示されている。図７に示したように、参照リストは、粗いレベルのエントリに関してのみ更新されている。この参照リストの閾値は、３などの任意の数でよい。従って、コンテナ２１０を指し示すファイルの数が３より少なくなると、参照リストは、粗い及び細かいレベルのエントリの両方を更新するように切り替わってもよい。別の実施形態では、閾値は異なる値をとってもよい。さらなる実施形態では、サーバ１５０（図１のもの）は、少なくとも部分的に、バックアップストレージ１６０（図１のもの）において現在利用されている記憶空間の割合に基づいて、閾値の値を決定してもよい。またさらなる実施形態では、サーバは、少なくとも部分的に、参照リスト内のエントリのサイズ又は数に基づいて、閾値の値を決定してもよい。閾値の値を設定又は決定するための任意の所望の条件を用いることができる。
【００４２】
コンテナ２１０は、ファイル２４３のエントリが削除された後には、参照リスト５００において、３つの粗いレベルのエントリを有する。ファイル２４３によって参照されたセグメントオブジェクトに関する参照リスト５００中のエントリは、まだリスト中に残っている。参照リスト５００は、粗いレベルのエントリに関してのみ更新されているので、ファイルが削除される際に、細かいレベルのエントリは削除されない。参照リストを粗いレベルで更新する利点は、処理するエントリがおそらく少ないので、リストの更新プロセスをスピードアップし得る点である。参照リスト５００の場合、ファイル２４３が削除される際に、たった１つの粗いレベルのエントリが削除され得る。また、削除されたファイルがコンテナを参照するか否かを決定するために、４つのエントリ（粗いレベルのエントリ）のみを処理する必要があり得る。参照リスト５００が細かいレベルで更新されたとすると、ファイル２４３によって指し示された各セグメントオブジェクトに対して６つの追加のエントリが削除された可能性がある。また、参照リスト５００が細かいレベルで更新されたとすると、全ての細かいレベルのエントリの処理が行われた可能性がある。多数のコンテナ及びセグメントオブジェクトを保存する大規模な重複排除に基づくストレージシステムにおいては、１つ又は複数の参照リストの粗いレベルのエントリのみを更新することにより、１つのファイル又はファイルグループの削除に続いて行われる更新及び処理操作の数を大幅に減らすことができる。
【００４３】
参照リストを粗いレベルで更新するデメリットも存在し得る。コンテナ内のセグメントオブジェクトの一部がどのファイルによっても使用されていない場合には、参照リストは、これを示さない場合がある。これにより、そうでなければ解放され、再使用が可能な記憶空間を消費する使用されていないセグメントオブジェクトが生じ得る。使用されていないセグメントオブジェクトの保存を軽減するために、ある特定のコンテナに関する参照リストエントリは、このコンテナに関する粗いレベルのエントリの数が閾値を下回った際に細かいレベルで更新されてもよい。ある特定のコンテナに関してごくわずかの粗いレベルのエントリが存在する時には、セグメントオブジェクトを再利用できる可能性がより高く、従って、粗いレベルの更新のみの利用と比較して、細かいレベルの更新への切り替えは、より速いリソース再利用を促進し得る。また、ある特定のコンテナに関して少数の粗いレベルのエントリが存在する場合には、細かいレベルの更新への切り替えは、多数の粗いレベルのエントリが存在した場合と比較して、リスト更新の処理負担は、僅かに増加するだけであることもある。
【００４４】
参照リストがある特定のコンテナに関して細かいレベルの更新へと切り替わった後に、この特定のコンテナ内に保存されたセグメントオブジェクトを参照する新しいファイルは、バックアップストレージシステムに加えられてもよい。コンテナを参照するファイルの数が閾値を超えて増加すると、参照リストは、このコンテナに関して元の粗いレベルの更新へと切り替わってもよい。参照リストは、ある特定のコンテナに関する粗いレベルのエントリの数が、いずれの方向にしても閾値を越える度に何度でも、細かいレベルから粗いレベルの更新へと交互に切り替わってもよい。
【００４５】
これより図８を参照すると、ファイル２４２がストレージシステムから削除された後のコンテナ２１０に関する参照リスト５００（テーブル及びリンクリスト形式の両方）が示されている。ファイル２４２の削除後には、コンテナ２１０に関する粗いレベルのエントリの数は２である。従って、参照リスト５００は、エントリの数が３の閾値を下回っているので、粗い及び細かいレベルのエントリの両方の更新へと切り替わってもよい。他の実施形態では、複数の参照リストが異なる閾値を有していてもよく、これらの参照リストは、異なる数の粗いレベルのエントリで、粗いレベルの更新から細かいレベルの更新へと切り替わってもよい。
【００４６】
図８では、ファイル２４２に関するコンテナ２１０の粗いレベルのエントリが参照リスト５００から削除され得る。さらに、セグメントオブジェクト（又は細かいレベル）のエントリも更新され得る。ファイル２４２に関する全ての細かいレベルのエントリがリストから削除され得る。また、ファイル２４３に関する粗いレベルのエントリ（前の操作において削除済み）がもはや存在しないので、ファイル２４３に関する全ての細かいエントリがリストから削除され得る。図７に示されるように、ファイル２４３が削除された時、参照リスト５００は粗いレベルの更新モードにあり、ファイル２４３の粗いレベルのエントリのみがリストから削除されている。参照リスト５００が細かいレベルの更新へと切り替わると、細かいレベルのエントリは、コンテナ２１０に関する粗いレベルのエントリと一致するように更新される必要があり得る。これにより、何個のファイルが各セグメントオブジェクトを参照するかをリストが正確に反映することが可能となる。図８に示されるように、参照リスト５００からファイル２４２及び２４３に関連する全ての細かいレベルのエントリを削除した後、セグメントオブジェクト２３８及び２３９は、どのファイルからも参照されない。従って、これらの２つのセグメントオブジェクトは、削除され、これらのオブジェクトによって占められていた記憶空間を再使用することができる。セグメントオブジェクトは直ぐに削除されてもよいし、あるいは、これらに削除の印を付け、他の使用されていないセグメントオブジェクトに関与するバッチ操作において、後で削除されてもよい。さらなる実施形態では、セグメントオブジェクトに印を付け、再利用を行う他の方法が可能であり、検討される。
【００４７】
ファイルがバックアップストレージシステムに加えられると、ファイルは、既に保存されたセグメントオブジェクトと同一のデータセグメントへと分割され得る。これらの同一のセグメントオブジェクトを保存するコンテナの参照リストが更新され得る。ある実施形態では、粗いレベルのエントリの数が閾値を下回ると、粗い参照リストのみが更新される。ファイルが削除され、粗いレベルの参照リストが閾値に達する場合には、細かい参照リストが再構築され得る。この様に、必要な場合にのみ細かいレベルの参照リストに関する行為が行われる。粗い参照リストのコンテナが閾値に達することがほとんどなければ、細かい参照更新のオーバーヘッドが全く存在しない。ある代替実施形態では、ファイルがコンテナに加えられると、たとえ粗いレベルのエントリの数が閾値を下回る場合であっても、細かい及びコースレベルの両方で、参照リストを更新してもよい。このような実施形態では、新しく保存されたファイルによって参照されるセグメントオブジェクトは、参照リストにおいて粗いレベルで処理が行われているコンテナに保存されてもよい。粗いレベルで処理が行われているコンテナの場合、新しいファイルがバックアップストレージシステムに加えられると、これらのコンテナのセグメントオブジェクトエントリは、やはり更新されてもよい。
【００４８】
一部の実施形態では、コンテナは、細かいレベルのエントリを更新することなく、その粗いレベルのエントリを全て参照リストから削除し得る。これは、コンテナの参照リストが粗いレベルのエントリのみを含む場合に生じ得る。これは、コンテナの参照リストが粗い及び細かいレベルのエントリを含み、かつ閾値がゼロの場合にも生じ得る。あるいは、これは、ファイルグループが一度に削除され、コンテナの粗いレベルのエントリの全てが１つの操作で削除される場合に生じ得る。ある特定のコンテナに関する全ての粗いレベルのエントリが削除されると、参照リストの細かいレベルのエントリが更新又は処理されることなく、そのコンテナのセグメントオブジェクトは、再利用されてもよく、あるいは、再利用の準備が出来ているものとして印が付けられてもよい。これにより、参照リストの細かいレベルのエントリを処理する必要なく、セグメントオブジェクトによって使用されるリソースを再利用することにより、処理時間及びオーバーヘッドを省くことができる。
【００４９】
これより、図９を参照すると、コンテナ２１０に関する「バックアップ指向の」参照リスト８００が示されている。コンテナ参照リストは、各コンテナが、コンテナ内の少なくともオブジェクト上を参照するバックアップのリストを有する点で、バックアップ指向である。従って、図５〜７の参照リスト５００とは対照的に、参照リスト８００は、バックアップトランザクション２５０に関連するエントリを含む。前の例の場合のように、テーブル及びリンクリスト形式の両方が示されている。図２に示されるように、バックアップトランザクション２５０は、ファイル２４１〜２４４を含む。図９の参照リスト８００は、ファイル２４３及び２４２の削除前の図６の参照リスト５００に対応する。参照リスト８００のエントリの数は、個々のファイルに準じる代わりに、バックアップトランザクションに準じて、コンテナ２１０及びセグメントオブジェクト２３１〜２３９をトラッキングすることによって、減少している。参照リスト８００のサイズの減少は、リストの保存に必要な記憶空間を減少させることがあり、バックアップトランザクションがストレージシステムに加えられる、又はストレージシステムから削除される際のリストのエントリの処理に必要な処理時間を減少させることがある。ある実施形態では、参照リスト８００は、１つのコンテナ又はセグメントオブジェクトを参照するバックアップトランザクションの各インスタンスに対して１つのエントリを含み得る。別の実施形態では、（図２の）重複排除サーバ１５０は、複数のバックアップトランザクションを１つのバックアップトランザクショングループに編成してもよく、参照リスト８００は、１つのコンテナ又はセグメントオブジェクトを参照するバックアップトランザクショングループの各インスタンスに対して複数のエントリを含んでもよい。さらなる実施形態では、ファイル及びバックアップトランザクションの他のグループ化を用いて、参照リスト８００がエントリを記録する方法を決定してもよい。理解され得るように、複数のファイルを含む１つのバックアップトランザクションを説明したが、ファイルの他の識別可能なグループ化を同様に用いてもよい。
【００５０】
さらに、参照リストの粗いレベルのエントリは、２つ以上のコンテナに対応してもよい。例えば、ある実施形態では、複数のコンテナを一緒にグループ化してもよい。この複数のコンテナは、１つのバックアップトランザクションからのデータを保存してもよい。あるいは、他の要素に基づいて、複数のコンテナを選択及び一緒にグループ化してもよい。粗いレベルのエントリが単一のコンテナではなく複数のコンテナに対応するように、参照リストが編成されてもよい。この様に参照リストを編成することにより、少ない数のエントリを有するより小さな参照リストが生じる結果となり、ファイル又はバックアップトランザクションがシステムに加えられる、又はシステムから削除される際の更新処理がより速くなる結果となり得る。
【００５１】
これより図１０を参照すると、バックアップ指向の参照リストを維持するための方法の一実施形態が示されている。説明目的で、この実施形態のステップは、順次的な順序で示される。以下に記載する方法の様々な実施形態において、記載する要素の内の１つ又は複数を同時に行う、示した順序とは異なる順序で行う、又は完全に省いてもよいことに留意されたい。要望通りに他の追加の要素を行うことも可能である。
【００５２】
図１０の方法は、ブロック９０５において開始され、次に、ブロック９１０において、ストレージ操作が検出され得る。この図面は、概ねバックアップ操作を説明しているので、ストレージ操作は、新しいバックアップを行っている、又は以前のバックアップを削除している可能性がある。条件ブロック９１５では、操作がバックアップの削除であると決定されると、次に、コンテナ参照リストのどのコンテナが削除中のバックアップの識別を含むかが決定され得る（ブロック９２５）。次に、コンテナの参照リストにおいて、削除されたバックアップに関するエントリが削除され得る（ブロック９３０）。
【００５３】
検出された操作が新しいバックアップである場合には（条件ブロック９１５）、追加が行われている各ファイルに対して、追加されたファイルから分割されたデータセグメントと同一のストレージ内の一致するセグメントオブジェクトの検索が行われ得る（ブロック９４０）。一致するセグメントオブジェクトが存在する場合（条件ブロック９４５）、一致するセグメントオブジェクトの場所が特定され得る（ブロック９５５）。一致するセグメントオブジェクトが存在しない場合（条件ブロック９４５）、新しいセグメントオブジェクト（追加されたファイルからのデータセグメントに対応）がコンテナ内に保存され、ファイルエントリがコンテナの参照リストに追加され得る（ブロック９５０）。
【００５４】
一致するセグメントオブジェクトの場所が特定されると（ブロック９５５）、どのコンテナが一致するセグメントオブジェクトを保持するかが決定され得る（ブロック９６０）。次に、新しいファイルに対応するバックアップトランザクションのエントリがコンテナの参照リストに追加され得る（ブロック９６５）。バックアップトランザクションがそのコンテナに関するエントリを既に有する場合には、新しいエントリが必要ではない場合がある。追加されたファイルからのさらなるデータセグメントが存在する場合には（条件ブロック９７０）、本方法は、ブロック９４０に戻り、一致するセグメントオブジェクトを検索し得る。追加されたファイルからのデータセグメントがそれ以上存在しない場合には（条件ブロック９７０）、本方法は、ブロック９７５で終了し得る。
【００５５】
ファイル指向及びバックアップ指向のコンテナ参照リストの両方の実施形態を説明したが、様々な実施形態において、セグメントオブジェクト参照リストを含んだ、このような実施形態の組み合わせを同時に維持することができる。このような実施形態では、ある状況において参照リストを更新するか否か及びどの参照リストを更新するかを決定するために、様々な条件を利用することができる。
【００５６】
これより図１１を参照すると、上記の方法及び機構に基づくハイブリッド手法の一実施形態が示されている。この例では、コンテナ参照リストとセグメントオブジェクト参照リストとのハイブリッドが説明される。方法１０００は、コンテナ参照リスト又はセグメントオブジェクト参照リストのどちらを維持するかを決定する方法の一実施形態を示す。説明目的で、この実施形態のステップは、順次的な順序で示される。以下に記載する方法の様々な実施形態において、記載する要素の内の１つ又は複数を同時に行う、示した順序とは異なる順序で行う、又は完全に省いてもよいことに留意されたい。要望通りに他の追加の要素を行ってもよい。
【００５７】
以下の説明では、説明目的で、ファイル指向のコンテナ参照リストを使用する（図５で説明したものに類似）。しかしながら、この方法は、バックアップ指向のコンテナ参照リストにも適用することができる。図示される方法１０００は、ブロック１０１０においてファイルを削除する要求から開始される。ブロック１０２０では、重複排除サーバ（又は他の構成要素）が、削除されたファイルによって参照されるコンテナを識別する（すなわち、ファイルは、コンテナに保存されたセグメントオブジェクトを含む）。コンテナを識別すると、重複排除サーバは、他の何個のファイルがそのコンテナを参照するかを決定し得る（ブロック１０２５）。ファイルの数が所与の閾値を上回る場合には（条件ブロック１０３０）、重複排除サーバは、コンテナ参照リストを維持し、削除されたファイルの識別をコンテナ参照リストから削除してもよい（ブロック１０３５）。エントリの削除は、図５又は図１０で説明された通りでよい。ファイル指向のコンテナ参照リストの場合には、削除されたファイルの識別は、そのファイルに関するコンテナ参照リストから除去されてもよい。バックアップ指向のコンテナ参照リストの場合には、削除されたバックアップの識別は、コンテナ参照リストから除去されてもよい。
【００５８】
コンテナ参照リストにおける所与のコンテナに関するファイル数が閾値を下回ると（条件ブロック１０３０）、重複排除サーバは、セグメントオブジェクト参照リストを維持し、削除されたファイルに対応するエントリをセグメントオブジェクト参照リストから削除してもよい（ブロック１０４０）。ある実施形態では、コンテナ参照リストの維持からセグメントオブジェクト参照リストの維持へと切り替わると、識別されたコンテナに対応するセグメントオブジェクト参照リストのエントリは、まだ存在しない場合がある。例えば、ファイルの追加中にコンテナ参照リストのみが維持されている場合、対応するセグメントオブジェクト参照リストは維持されていない。その結果、セグメントオブジェクト参照リストの維持への切り替えが所与のコンテナに関して行われた際に、そのコンテナを参照するファイルがまだ存在する場合には、そのコンテナに関するセグメントオブジェクト参照リストのエントリはまだ存在しない。このような場合には、そのコンテナに関するセグメントオブジェクト参照リストを作成する必要がある。ある実施形態では、これらのセグメントオブジェクト参照リストのエントリの作成は、セグメントオブジェクト参照リストの維持を決定した時点で行われてもよい（ブロック１０４）。次に、重複排除サーバは、このコンテナが削除されたファイルによって参照される最後のコンテナであるかどうかを決定してもよい（条件ブロック１０４５）。これが、削除されたファイルによって指し示される最後のコンテナであった場合には（条件ブロック１０４５）、この方法は、ブロック１０５５において終了し得る。これが、削除されたファイルによって指し示される最後のコンテナではなかった場合には（条件ブロック１０４５）、この方法は、削除されたファイルによって指し示される次のコンテナを見つけ出してもよい（ブロック１０５０）。次に、サーバは、他に何個のファイルが次のコンテナを指し示すかを決定するために、ブロック１０２５に戻ってもよい。
【００５９】
上記の実施形態がソフトウェアを含み得ることに留意されたい。このような実施形態では、説明したシステム及び／又は方法を表すプログラム命令及び／又はデータベース（どちらも「命令」と呼ばれ得る）は、コンピュータ可読ストレージ媒体に保存されてもよい。一般的に言えば、コンピュータ可読ストレージ媒体は、命令及び／又はデータをコンピュータに提供するために、使用中にコンピュータによってアクセス可能な任意のストレージ媒体を含み得る。例えば、コンピュータ可読ストレージ媒体は、磁気又は光媒体、例えばディスク（固定又はリムーバブル）、テープ、ＣＤ−ＲＯＭ、ＤＶＤ−ＲＯＭ、ＣＤ−Ｒ、ＣＤ−ＲＷ、ＤＶＤ−Ｒ、ＤＶＤ−ＲＷ、又はＢｌｕ−Ｒａｙ等のストレージ媒体を含み得る。ストレージ媒体は、ＲＡＭ（例えば、同期型ダイナミックＲＡＭ（ＳＤＲＡＭ））、ダブルデータレート（ＤＤＲ、ＤＤＲ２、ＤＤＲ３等）ＳＤＲＡＭ、低電力ＤＤＲ（ＬＰＤＤＲ２等）ＳＤＲＡＭ、Ｒａｍｂｕｓ  ＤＲＡＭ（ＲＤＲＡＭ）、スタティックＲＡＭ（ＳＲＡＭ）、ＲＯＭ、フラッシュメモリ、ＵＳＢインタフェース等の周辺インタフェースを介してアクセス可能な不揮発性メモリ（例えばフラッシュメモリ）等の揮発性又は不揮発性メモリ媒体をさらに含み得る。ストレージ媒体は、微小電気機械システム（ＭＥＭＳ）、並びに、ネットワーク及び／又は無線リンク等の通信媒体を介してアクセス可能なストレージ媒体を含み得る。
【００６０】
様々な実施形態において、本明細書に記載した方法及び機構の一部又は複数の部分は、クラウドコンピュータ環境の一部を形成し得る。このような実施形態では、１つ又は複数の様々なモデルに準じたサービスとして、インターネット上でリソースが提供され得る。このようなモデルには、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ（ＩａａＳ）、Ｐｌａｔｆｏｒｍ  ａｓ  ａ  Ｓｅｒｖｉｃｅ（ＰａａＳ）、及びＳｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ（ＳａａＳ）が含まれ得る。ＩａａＳでは、コンピュータインフラがサービスとして提供される。このような場合、計算機器は、一般的にサービスプロバイダによって所有され、かつ操作される。ＰａａＳモデルでは、ソフトウェアソリューションを開発するために開発者によって使用されるソフトウェアツール及び基礎となる機器は、サービスプロバイダによって、サービスとして提供され、ホストされ得る。ＳａａＳは、一般的に、オンデマンドでサービスとしてソフトウェアの使用を許諾するサービスプロバイダを含む。サービスプロバイダは、ソフトウェアをホストしてもよく、あるいは、所与の期間だけソフトウェアを顧客に配布してもよい。上記のモデルの多数の組み合わせが可能であり、検討される。
【００６１】
手法の幾つかの実施形態を図示及び説明したが、記載した手法に対して多数の変更、改変、又は修正を行うことができることは当業者には明らかとなるであろう。従って、変更形態、改変形態、又は修正形態は、本明細書に記載した方法及び機構の範囲内と見なされるものとする。上記の実施形態は、実施の非限定的例に過ぎないことも当然強調されることである。
【図１】
2013541083.tif 000003
【図２】
2013541083.tif 000004
【図３】
2013541083.tif 000005
【図４】
2013541083.tif 000006
【図５】
2013541083.tif 000007
【図６】
2013541083.tif 000008
【図７】
2013541083.tif 000009
【図８】
2013541083.tif 000010
【図９】
2013541083.tif 000011
【図１０】
2013541083.tif 000012
【図１１】
2013541083.tif 000013
【国際調査報告】
2013541083.tif 000014
2013541083.tif 000015