JP5309015B2

JP5309015B2 - データ圧縮技術およびデータ格納技術

Info

Publication number: JP5309015B2
Application number: JP2009504506A
Authority: JP
Inventors: ドッド、ブライアン; ムーア、マイケル
Original assignee: Data Storage Group
Current assignee: Data Storage Group
Priority date: 2006-04-07
Filing date: 2007-04-09
Publication date: 2013-10-09
Anticipated expiration: 2027-04-09
Also published as: DK2013974T3; AU2007234696A1; EP2013974A2; AU2007234696B2; WO2007118243A2; JP2009533731A; CA2648428C; EP2013974B1; US20110087640A1; WO2007118243A3; EP2013974A4; US7860843B2; CA2648428A1; US20080034268A1

Description

本出願は、デジタルデータを格納することに関する。より具体的には、本出願は、いくつかの態様が、データアーカイブにおいて応用されるデジタルデータのより効率的な格納に使用するためのユーティリティに関する。

（関連出願の相互参照）
本出願は、内容の全体を本明細書に援用する２００６年４月７日の出願日を有する「ＣｏｎｔｅｎｔＦａｃｔｏｒｉｎｇｆｏｒＬｏｎｇＴｅｒｍＤｉｇｉｔａｌＡｒｃｈｉｖｉｎｇ」という名称の米国仮出願第６０／７４４，４７７号からの優先権を主張する、２００７年４月９日の出願日を有する「ＤａｔａＣｏｍｐｒｅｓｓｉｏｎａｎｄＳｔｏｒａｇｅＴｅｃｈｎｉｑｕｅｓ」という名称の米国出願第１１／７３３，０８６号の優先権を主張する。

組織は、長期のデータ保持要件を満たす際に新たな課題に直面しており、ＩＴ専門家は、州および連邦政府の多くの新たな規制およびガイドラインの遵守を維持する責任を有する。これらの規制は、組織が、過去に、使用可能な仕方で必要な情報を利用可能にしておくことに苦労したために存在する。この問題を悪化させているのが、デジタル情報の継続的な爆発的増加である。ドキュメントは、コンテンツがより豊かであり、しばしば、関連する仕事を参照し、管理されるべき途方もない量の情報をもたらす。

基礎をなすアクセスパターンをよりよく理解するため、デジタル情報の分類を最初に簡単に説明することが役立つ。すべてのデジタル情報のコレクションは、一般に、構造化されたもの、または構造化されていないものとして分類可能である。構造化された情報とは、リレーショナルデータベース内部に保持されるデータを指す。構造化されていない情報は、その他すべて、すなわちドキュメント、イメージ、映画などである。構造化されたデータと構造化されていないデータはともに、ユーザまたはアプリケーションによって活発に参照される、または将来の参照または遵守のために変更されないままに保たれる。構造化された情報、および構造化されていない情報のうち、活性の情報は、定常的に参照される、または変更されるのに対して、非活性の情報は、時々しか参照されない、または将来の何からの時点で参照される可能性を有するに過ぎない。情報が活性である、または非活性である特定の時間枠は、純粋に主観的である。

デジタル情報の下位分類が、動的または固定としてデータの可変性を表す。トランザクションデータベース内のレコードなどの動的コンテンツは、頻繁に、または継続的に変化する。スキャンされるチェックイメージまたは電子メールメッセージなどの固定のコンテンツは、静的な読み取り専用の情報であり、つまり、作成され、決して変更されない。長期アーカイビングに関して、構造化された、または構造化されていない非活性の情報は、常に固定コンテンツを有すると考えられ、変化しない。

時とともに、情報は、それほど頻繁にアクセスされなくなる傾向があり、アクセスパターンは、より読み取り専門になる傾向がある。固定コンテンツの読み取り専用情報は、アーカイビングの点で管理するのが比較的簡単明瞭である。もちろん、サブファイルレベルにおいてさえ、構造化された、または構造化されていない動的情報が、静的である大きいコンテンツセグメントを含む可能性がある。このタイプの情報の例には、コンテンツが追加されているデータベースファイル、および編集されるドキュメントが含まれる。

固定であれ、動的であれ、デジタル情報のタイプにかかわらず、多くの組織は、組織のデジタルデータを固定でバックアップする。例えば、多くの組織は、すべてのデジタルデータが複製される毎週のバックアップを実行する。さらに、これらの組織の多くは、毎日のインクリメンタルバックアップを実行して、日々のデジタルデータの変更が格納されるようにする。しかし、従来のバックアップシステムは、いくつかの欠点および非効率を有する。例えば、すべてのデジタルデータが複製される毎週のバックアップ中、変更されていない固定のファイルが、複製される。理解され得るとおり、このことは、デジタル情報の不必要な冗長性とともに、処理要件および／または帯域幅要件の増大をもたらす。毎週のバックアップとインクリメンタルバックアップの両方に関する別の問題は、動的ファイルのわずかな変更が、デジタルデータの非効率な複製をもたらす可能性があることである。例えば、１０ＭＢファイルの１文字の編集により、そのファイルのコンテンツ全体がバックアップされ、カタログされることが要求される。状況は、ＯｕｔｌｏｏｋＰｅｒｓｏｎａｌＦｏｌｄｅｒｓ（．ｐｓｔファイル）などのより大きいファイルに関してはるかに悪く、これらのファイルを開く動作そのものにより、これらのファイルが変更されることになり、すると、このことが、別のバックアップを要求する。

これらの欠点および非効率の通常の結果は、大量のバックアップデータの生成であり、最も一般的なバックアップシステムにおいて、複数のデータストレージテープの生成である。これに関して、非効率なバックアップは、複数のバックアップテープの生成をもたらし、次に、これらのテープが、格納されなければならない。通常、そのようなテープは、オフラインで格納される。つまり、それらのテープは、コンピュータ化されたアクセスが即時に利用可能でない場所に格納される。したがって、バックアップテープから情報を回復することは、アーカイビング施設と連絡をとり、テープを特定し、その施設が、そのテープを探し出して、ロードするのを待つことを要求する可能性がある。

ディスクストレージの価格が下がってきているなかで、ディスクバックアップを利用して、テープバックアップの問題を軽減しようとする試みが行われてきた。しかし、これらのディスクバックアップは、依然として、データの非効率な複製を見込む大量のストレージを要求する。したがって、デジタルデータの前のバックアップと現在のデジタルデータセットとの間に生じた動的変化を識別する試みが行われてきた。これに関して、目標は、前のデジタルデータセットに対して変更されているデータ（すなわち、動的データ）のバックアップに限って作成することである。

データバックアップの合間の動的変化を識別して、それらの動的変化だけを格納しようとする１つの試みが、ＣＯＳ（容量最適化ストレージ）によって代表される。ＣＯＳの目標は、バックアップセット間の冗長性を重複除外することである。つまり、ＣＯＳの目標は、現在のデータセットを以前に格納されたデータセットと比較して、新たなデータだけを格納することである。一般に、ＣＯＳ処理は、デジタルデータ（例えば、第１のバックアップコピー）のセット全体をデータチャンク（例えば、２５６ｋＢ）に分割して、それらのデータチャンクにハッシュアルゴリズムを適用することである。当分野の技術者によって理解されるとおり、このことは、ハッシュコード／アルゴリズムに従ってデータを表すキーアドレスをもたらす。バックアップのための新たなデータセット（例えば、第２のバックアップコピー）が受け取られると、データセットは、データチャンクに再び分割され、ハッシュアルゴリズムが適用される。理論上、第１のデータセットと第２のデータセットの間の対応するデータチャンクが同一である場合、バックアップの合間に変更は、全くなかったものと想定される。したがって、第１のバックアップセットとは異なるチャンクだけが、保存されて、後続のバックアップに関するストレージ要件が低減される。ＣＯＳの主な欠点は、バックアップセット間の冗長性を大幅に減らすのに、ますます小さいデータチャンクを利用することが望ましいことである。しかし、データチャンクのサイズが縮小されるにつれ、キーアドレスの数は、増加する。したがって、より多くのキーアドレスの格納および索引付けが、より少ない量の重複データの利益を消すように作用する。

ＣＯＳ処理の使用により、ディスクアクセス可能なデータバックアップの作成が可能になり、バックアップされたデータセットへのより容易なアクセスが可能になる。これに関して、ＣＯＳは、仮想テープライブラリＶＴＬがテープストレージデバイスをエミュレートするように、仮想テープライブラリＶＴＬに組み込まれる。システムは、ユーザが、バックアップのためにオフサイトのディスクストレージセンタにデータを送信することを可能にする。しかし、このことは、データセット全体が、ＶＴＬに伝送されることを要求し、ＶＴＬにおいて、このデータセット全体が、格納のために最適化される（例えば、ＣＯＳ）。さらに、後続の各バックアップに関して、そのデータセット全体が、オフサイトのストレージセンタに再び伝送されなければならない。理解され得るとおり、バックアップを要求する大きいデータセットを有する大きい組織に関して、データセット全体の伝送を要求するそのようなオフサイトのストレージシステムには、データを転送する大きい帯域幅要件、およびデータを最適化し、比較する高い処理要件がかかわる可能性がある。最後に、オフサイトＶＴＬを利用する組織は、組織のデータの復元に関してバックアップアプリケーションに１００％依存し、やはり、ユーザは、潜在的に、不慮の削除またはディスク破損の場合に情報が利用できない可能性にさらされたままとなる。

既存の短期データ保護ソリューションは、法外な費用がかかり、アーカイブされた情報への向上したアクセスを可能にすることにほとんど効果がない。本明細書で説明されるアーカイブ技術は、情報を管理することの長期ソリューションを提供するとともに、ディスクベースのアーカイブにおいて利用可能なソリューションを提供する。これらの技術は、既存のディスクリソースを使用して、アーカイブされた情報のコレクションへの容易なアクセスを提供する。この技術が、オープンアーキテクチャオブジェクトベースのコンテンツストアと相俟って、既存の短期データ保護手続きを全く変更することなしに、ディスクベースのシステムの有効容量の大幅な増加（例えば、２０：１）を可能にする。

さらに、コンテンツの長期ストレージをよりうまく最適化するのに、これらの新たな技術は、所与のデータセットに関して格納される冗長な情報を減らす。適応コンテンツファクタリングは、固有のデータにキーが付けられ、１回格納される、本発明者らによって開発された技術である。従来のコンテンツファクタリング技術または適応差分技術とは異なり、適応コンテンツファクタリングは、発見的方法を使用して、格納される各データ量子のサイズを最適化する。適応コンテンツファクタリングは、データ圧縮と関係するが、局所化されたコンテンツに限定されない。データセットの所与のバージョンに関して、新たな情報が、異なる時点で保存された個別の各セグメントからのバージョンを再構成するのに使用されるメタデータと一緒に格納される。このメタデータ−再構成段階は、通常のファイルシステムがＩ／Ｏ要求に応える際に行うことと同様である。

本発明の第１の態様により、データを格納する方法およびシステム（ユーティリティ）が提供される。このユーティリティは、第１のデータセットを受け取ること、および辞書ベースの圧縮エンジンを使用して第１のデータセットを圧縮することが必然的に伴う。そのような圧縮により、第１のデータセットを表す第１の圧縮ファイルが生成される。次に、この第１の圧縮ファイルが格納される。次に、この第１の圧縮ファイルを利用して、第１のデータセットの後続のバージョンにおける変化が識別される。本明細書で利用される「データセット」には、限定なしに、個々のデータファイル、ならびに複数のデータファイルを含むフォルダ、および／または複数のフォルダを含むことが可能なドライブが含まれることが意図される。そのような事例においては、第１のデータセットを圧縮することにより、対応する複数の第１の圧縮ファイルが生成される。

一つの構成では、第１の圧縮ファイルを使用して変化を識別することは、辞書ベースの圧縮エンジンに第１の圧縮ファイルを事前ロードして、条件付き圧縮エンジンを定義することを含む。つまり、第１の圧縮ファイルは、圧縮エンジンにロードされることにより、圧縮エンジンのための辞書を定義する。第１のデータセットと後続のデータセットが実質的に同様である場合、圧縮エンジンに関する辞書として第１のデータセットを使用することは、圧縮率の高い第２のデータセットをもたらす。このため、ユーティリティは、第１のデータセットの後続のバージョンを、条件付き圧縮エンジンを使用して圧縮することを含む。これに関して、第１のデータセットの後続のバージョンを示す第２の圧縮ファイルが生成される。この第２の圧縮ファイルは、後続のデータセットと第１のデータセットの間の変化をやはり示す。さらに、第２の圧縮ファイルは、第１の圧縮ファイルに対する１つまたは複数のリファレンスを含む。第２の圧縮ファイルは、第１の圧縮ファイルよりも相当に小さくなる。より早期の１つまたは複数のデータセットを、辞書ベースの圧縮エンジンに関する辞書として利用することにより、複数の後続のデータセットを圧縮することが可能となる。

第１のデータセットの対応する部分を、第２のデータセットの対応する部分（例えば、対応するファイル）と同一視するため、ユーティリティは、データセットの個々の１つまたは複数の部分に関する識別子情報を生成することをさらに必然的に伴う。例えば、ハッシュコード情報（本明細書で「ハッシュ情報」および「ハッシュ」または「複数のハッシュ」とも呼ばれる）が、データセットの個々の部分に関して生成される。さらに、そのようなハッシュ情報が、データセットの個別の各部分の個々の構成要素に関して生成される。一つの構成において、１つまたは複数のハッシュコードが、所与のファイルに関連するメタデータに関連し、別のハッシュコードが、ファイルのコンテンツに関して生成される。したがって、そのようなハッシュコードを利用して、圧縮の目的で、第１のデータセットと後続のデータセットの対応する部分を識別することが可能である。対応するハッシュコードが、後続のデータセットのいくつかの部分に関して存在する場合、通常の圧縮方法が、後続のデータセットのそれらの部分に対して利用することが可能となる。

別の態様によれば、データを圧縮するためのシステムおよび方法（ユーティリティ）が提供される。ユーティリティは、ファイルを受け取ること、およびこのファイルの前のバージョンが以前に格納されていると判定することを含む。そのような判定が行われると、ファイルを、そのファイルの前のバージョンから生成された圧縮辞書語を使用して圧縮することが可能となる。こうして、受け取られたファイルに関する圧縮ファイルが生成される。次に、この圧縮ファイルが格納される。圧縮辞書語は、ファイルの前のバージョンから、またはファイルの前のバージョンの圧縮バージョンから生成される。いずれの構成においても、ユーティリティは、ファイルの前のバージョンを圧縮エンジンに事前ロードすること、および受け取られたファイルを、圧縮エンジンを使用していくつかの部分に分けてバッファリングすることを含むことが可能である。そうすることにより、受け取られたファイルのバッファリングされた部分と、前のファイルの同様のサイズの部分との実質的なマッチングが可能となる。

ファイルの前のバージョンが以前に格納されているという判定は、任意の適切な方法で行われる。例えば、ファイルは個別に保存されて、ユーザが、バックアップ手続き中にファイルの以前に格納されたバージョンを選択することが可能である。別の構成において、バージョンリファレンスに関連する（例えば、ファイルのメタデータに関連する）ハッシュを利用することで、ファイル間の関係を判定することが可能である。一つの構成において、第１のハッシュおよび第２のハッシュは、以前に格納されたファイルのメタデータ、および受け取られたファイルのメタデータに関連する。そのような構成において、ファイルの対応する第１のハッシュが合致する（例えば、ストレージロケーションに対応して）一方で、ファイルの第２の対応するハッシュ（例えば、バージョンリファレンス）は合致しない。これに関して、これらのファイルは、関係するが、これらのファイル間に変更があると判定される。したがって、バックアップ目的で量を減らすために、前のファイルを利用して後続のファイルを圧縮することが望ましい可能性がある。

別の発明の態様によれば、データをアーカイブする際、および／または格納する際に使用するシステムおよび方法（ユーティリティ）が提供される。ユーティリティは、データセットに関する個別のシグネチャを生成することが必然的に伴う。このシグネチャが、後続のデータセットと比較されることにより、対応する部分、または同様の部分が識別される。そのため、それらのデータセット間の違いを識別することが可能となる。したがって、データセットの同様の部分は、バックアップ手続きにおいてコピーされる必要がない。そうではなく、後続のデータセットの新たな部分（例えば、違い）だけが、アーカイビング／バックアップ目的でコピーされればよい。

一つの態様において、ユーティリティは、第１のデータセットに関連する第１のシグネチャを生成することを含む。第１のシグネチャを生成することは、第１のデータセットのメタデータに関連する第１のハッシュセット（例えば、ハッシュコード）を生成することを含む。さらに、第１のデータセットに関して、第１のデータセットのコンテンツに関連するコンテンツハッシュのセットが生成される。例えば、データセットの中の個別の各ファイルは、メタデータに関連する第１のハッシュ（例えば、識別子ハッシュ）と、そのファイルのコンテンツに関連する第２のハッシュ（例えば、コンテンツハッシュ）とを含む。これらが生成されると、第１のハッシュと、コンテンツハッシュとを含むシグネチャを個々に、および／または組み合わせで利用して、第１のデータセットと後続のデータセットとの間の変化が識別される。例えば、第１のデータセットの識別子ハッシュが、後続のデータセットの対応するハッシュと比較される。そのような比較に基づき、第１のデータセットと後続のデータセットの１つまたは複数の部分の間で変化が存在すると判定される。つまり、第１のデータセットと第２のデータセットの１つまたは複数の部分の間で変化が存在するかどうかが判定される。

一つの構成において、第２のデータセットの識別子ハッシュが、第１のデータセットの識別子ハッシュと合致しない場合、この合致しない識別子ハッシュに関連するコンテンツが、第１のデータセットのコンテンツと比較される。より詳細には、そのコンテンツをハッシュすることによって得られたコンテンツハッシュコードが、第１のデータセットに関連するコンテンツハッシュコードと比較される。これに関して、コンテンツの識別子が第１のデータセットにおける識別子と合致しない場合でさえ、そのコンテンツが第１のデータセットの中に既に存在するかどうかを判定する第２の検査が実行される。そのコンテンツハッシュコードが存在する場合、そのコンテンツは、ストレージロケーションに伝送されない、またはそれ以外で格納されない可能性がある。合致しない識別子ハッシュのコンテンツハッシュコードが、第１のデータセット内のコンテンツハッシュコードと合致しない場合、そのコンテンツは、ストレージロケーションに格納される。

一つの構成において、メタデータに関連する識別子ハッシュは、第１の識別子ハッシュと、第２の識別子ハッシュとを含む。これらのハッシュのそれぞれは、メタデータのいくつかの部分に関連する。例えば、これらのハッシュの１つは、他のハッシュの下位部分であり得る。これに関して、データセットの間で、より細かい比較が行われて、データセット間の変化が識別される。

さらなる発明の態様において、アーカイビング目的の分散処理を可能にするためのシステムおよび方法（ユーティリティ）が提供される。これに関して、データセット全体をアーカイブロケーションに転送するのではなく、アーカイブデータセットと現在のデータセットとの間の変化の識別が、現在のデータセットのロケーション（例えば、データ起源ロケーション）において実行される。したがって、アーカイブロケーションに送られる可能性がある情報は、以前に格納されたデータセットと現在のデータセットとの間の違いだけである。

一つの態様によれば、格納のための第１のデータセットが受け取られる（例えば、アーカイブ／バックアップロケーションにおいて）。したがって、第１のデータセットのメタデータに関連する識別子ハッシュのセットが生成される。また、同様に、第１のデータセットのコンテンツに関連するコンテンツハッシュのセットも生成される。第１のデータセットに関連する現在のデータセットをバックアップすることが必要になると、これらの識別子ハッシュおよびコンテンツハッシュが、第１のデータセットに関連するデータ起源ロケーションに供給される。データ起源ロケーションにおいて、これらのハッシュを利用して、第１のデータセットと後続のデータセットとの間の変化が特定されて、これらの変化が、ストレージロケーションに転送される。これに関して、ユーティリティには、供給された識別子ハッシュおよび／またはコンテンツハッシュのいずれか、または両方と合致しなかった後続のデータセットからデータを受け取ることも必然的に伴う。そのような時点で、新たに受け取られたデータがハッシュされ、そのハッシュ情報が、後続のバックアップの目的で既存のハッシュ情報に追加される。

別の態様によれば、以前に格納されたデータセットのメタデータに関連する識別子ハッシュのセットが受け取られるユーティリティが提供される。これらの識別子ハッシュは、現在のデータセットの識別子ハッシュと比較される。このデータセットの少なくとも一部分が、以前に格納されたデータセットの後続のバージョンを形成する。これらの識別子ハッシュを比較することにより、現在のデータセットの合致しない識別子ハッシュを識別することが可能になる。したがって、合致しない識別子ハッシュに関連するコンテンツの一部分または全部が、ストレージロケーションに送られる。

さらなる構成において、ユーティリティは、以前に格納されたデータセットのコンテンツに関連するコンテンツハッシュのセットを受け取ることをさらに含む。そのような構成において、現在のデータセットの合致しないハッシュのコンテンツに関連するコンテンツハッシュが、以前に格納されたデータセットのコンテンツハッシュと比較される。したがって、そのような構成において、識別子ハッシュも、コンテンツハッシュも、以前に格納されたデータセットのハッシュに対応しない場合、その合致しないコンテンツが、ストレージロケーションに送られる。

前述の２つの態様において、送信する／供給する工程、および／または受け取る工程は、例えば、コンピュータとストレージロケーション（例えば、直接に接続されたストレージ、取り外し可能なハードドライブ、または他のポータブルストレージデバイス）との間の直接接続によって、あるいはネットワーク接続によって実行される。ネットワーク接続によって実行される場合、そのようなネットワーク接続には、ワイドエリアネットワーク、インターネット、直接接続されたストレージネットワークおよび／またはピアコンピュータが含まれる。

さらなる態様において、データセットの複数の異なるバージョン（例えば、連続したバージョン）を格納するための、およびそのようなバージョンへのアクセスを提供するためのシステムおよび方法が提供される。このユーティリティには、異なる時点で異なるデータセットのカタログを生成することが含まれる。各カタログは、或る特定の時点における関連するデータセットを再構成するのに必要とされる情報を含む。つまり、或る時点に関する或る特定のデータセットの完全なコピーを生成するのではなく、このユーティリティは、所与のデータセットを再構成するのに要求されるデータのロケーションに対するリファレンスを有するカタログを生成する。

一つの構成において、カタログは、異なるデータストリーム（例えば、ファイルの構成要素）に関する様々なハッシュコードを含む。これらのハッシュコードは、カタログ内で所与のファイルの構成要素を識別し、探し出すことができるようにする。したがって、これらの構成要素は、カタログが生成された際に存在していた形態でファイルを形成するように再構成される。別の言い方をすると、所与のファイルのデータを格納するのではなく、カタログは、そのファイルに関連するデータのロケーションに対するリファレンスを格納して、ファイルの構成要素を複製することが、必ずしも必要でないようにする。さらに、所与のカタログの格納されたリファレンスは、異なる時点で保存されている所与のファイルの異なるセグメントを参照可能である。

例示的な実施形態が図に示される。本明細書で開示される実施形態および図は、限定するものではなく、例示的であるものと考えられることが意図されている。

次に、添付の図面を参照して、本発明の様々な特徴を説明する。本発明は、ここでは、主として、電子データのアーカイビング／バックアップストレージに関連して説明されるものの、本発明は、本明細書に含まれる発明の目的を実現することが所望される他の応用例にも適用可能である。つまり、本発明は、任意のデータストレージ環境において利用することが可能である。これに関して、アーカイビングのための使用の以下の説明は、例示および説明の目的で提示される。さらに、この説明は、本発明を、本明細書で開示される形態に限定することを意図していない。したがって、以下の教示、および当該技術分野の技能および知識に相応する変種および変形は、本発明の範囲に含まれる。本明細書で説明される実施形態は、本発明を実施する当業者が、本発明を、そのような実施形態において、または他の実施形態において、本発明の特定の応用例または用法によって要求される様々な変形とともに利用することができるようにすることをさらに意図している。

アーカイビングの目的でバックアップ工程および復元工程だけを厳密に使用することは、ほとんどの規制された環境に関して容認できない。ディスクベースのバックアップ環境に関して、従来の方法を使用することは、一般に、法外な費用がかかる。より高い利用可能性に対処し、ディスクストレージの費用を最小限に抑える２つの一般的な方法は、ＨＢＤＬ（ハードウェアベースのディスクライブラリ）またはＶＴＬ（仮想テープライブラリ）を組み込むことである。いずれのソリューションも、データ冗長性問題に対処せず、これらのソリューションは、全体的なＴＣＯ（総所有コスト）を低減することにほとんど効果がない。

ＩＴ組織によって採用される代替のアプローチは、ボリュームシャドウコピーサービスなどのブロックレベルスナップショット技術、または類似したハードウェアベンダによって提供されるスナップショット技術を使用することである。この場合、所与の回復ポイントに関して、変更されたブロックが記録される。しかし、これらのシステムは、通常、指定された数のスナップショットの後、またはボリューム容量閾値に達すると、リセットされる（ロールオーバする）。すべての場合において、ブロックが再使用された後、削除された情報は、もはや利用できない。さらに、スナップショット技術は、長期アーカイビングに適したデータを編成する能力を欠いている。

図１は、アーカイビング要件に対処するように毎月のボリュームイメージを保持することを含む通常の４週間ローテーションスキームを使用して、２年間にわたって１テラバイトのボリュームを管理するのに要求される容量を示す。この例は、５０％の複合年間データ成長レートをモデル化する。バックアップされるべきデータの全体的な量が、５０％増加する一方で、既存のバックアップ技術に基づいて１年の期間にわたってこのデータをバックアップするのに要求されるデータリソースは、元のコンテンツ／データのほぼ２０倍である。やはり図示されるのが、本明細書で提供される技術（例えば、適応コンテンツファクタリング技術）に基づくディスクベースのアーカイビング方法を使用して達せられることが可能な、元のコンテンツ／データに対する、ほぼ線形のスケーリングである。バックエンドストレージ要件は、より多くの回復ポイント、およびアーカイブされた情報への向上したニアラインアクセスを提供しながら、ほぼ２０分の１に低減される（有効容量比として表された軸を参照）。ＴＣＯは、低位ないし中位のディスクストレージ上に展開された場合の、従来のテープベースのバックアップシステムのＴＣＯに近づく。

本明細書で開示されるアーカイブ技術は、リファレンス／格納された情報へのオンライン／動的アクセスも可能にし得る長期データ保持戦略として特徴付けられる。この技術は、適応コンテンツファクタリングを利用して、ディスクベースのストレージシステムの有効容量を増加させて、デジタルアーカイビングに関するＴＣＯを大幅に低減する。従来のバックアップおよび回復とは異なり、管理されるすべてのデータは、オンラインであり、利用可能である。さらに、アーカイブ内のすべてのデータが、有効期限が切れるまで、アクセス可能なままである。統合された探索−アーカイブコレクション管理フィーチャが、アーカイブされた情報の全体的な編成および管理を向上させる。

コンテンツの長期ストレージをよりうまく最適化するのに、この新たなアーカイビング技術は、所与のデータセットに関して格納される冗長な情報を減らす。冗長な情報が減らされると、データの連続するバージョンを格納するのに要求されるストレージリソースが、より少なくなる。これに関して、適応コンテンツファクタリングは、固有のデータにキーが付けられ、１回、格納される技術である。従来のコンテンツファクタリング技術または適応差分技術とは異なり、適応コンテンツファクタリングは、発見的方法を使用して、格納されるデータの各量子のサイズを最適化する。適応コンテンツファクタリングは、データ圧縮と関係するが、局所化されたコンテンツに限定されない。データセットの所与のバージョンに関して、新たな情報は、異なる時点において保存された個別の各セグメントからのバージョンを再構成するのに使用されるメタデータと一緒に格納される。このメタデータ−再構成段階は、Ｉ／Ｏ要求に応じる際に通常のファイルシステムが行うことと同様である。

図２は、適応コンテンツファクタリングの背後の基本的概念を示す。Ｔ_０において、データセットＶ_０（ファイル、ボリューム、またはデータベース）がセグメント化され、個々の要素にキーが付けられ、このデータセットを再構成するのに使用されるセグメントおよび工程を記述するメタデータと一緒に格納される。Ｔ_１およびＴ_２において、このデータセットは、データセットが、それぞれ、Ｖ_１およびＶ_２になるように更新される。しかし、データセットＶ_１およびＶ_２の新たなバージョン全体を格納するのではなく、これらのデータセットの更新部分を表す変更だけが、バージョンＶ_１およびＶ_２を再構成するのに使用されるメタデータと一緒に格納される。

本明細書でさらに説明されるとおり、新規な方法が、初期データセットＶ_０と後続のデータセットＶ_１との間の変化（例えば、データブロック３’および１０）を識別して、データチャンクのより大きいセット（例えば、ファイル、ディレクトリなど）が、そのファイル、またはそのディレクトリの前のバージョンと比較されて、後続のバージョンにおける変化だけがアーカイブされるようにすることが可能であるようにすることを提供する。これに関して、変化していない元のデータセットＶ_０（例えば、ベースラインバージョン）の部分（例えば、データブロック１、２、および４〜９）が、不必要に複製されない。そうではなく、変化のセットを含むファイルまたはディレクトリを再現する際、そのファイル／ディレクトリのベースラインバージョンが利用され、記録された変化（例えば、３’および１０）、つまり、デルタが、回復された後続のバージョンに組み込まれる。これに関して、時刻Ｔ_１においてデータセットＶ_１をバックアップする際、データセットＶ_１を事実上、バックアップするのに初期データセットＶ_０に対する変更だけが保存されればよい。

データセットの後続のバージョン（例えば、Ｖ_０およびＶ_１）の間の変化を識別するため、本発明は、新規な圧縮技術を利用する。理解されるとおり、データ圧縮は、データストリームの中のパターンの識別によって機能する。データ圧縮アルゴリズムが、同一の情報を表すより効率的な方法を選択する。基本的に、可能な限り多くの冗長性を取り除くためにデータにアルゴリズムが適用される。圧縮スキームの効率および有効性は、圧縮されたデータに対する圧縮されていないデータのサイズの比である、圧縮比によって測定される。２対１の圧縮比（標準の圧縮アルゴリズムにおいて比較的一般的である）は、元のデータのサイズの半分である圧縮されたデータを意味する。

様々な圧縮アルゴリズム／エンジンが、データを圧縮するために異なる方法を利用する。しかし、いくつかの損失のない圧縮アルゴリズムは、辞書ベースの圧縮アルゴリズムである。辞書ベースのアルゴリズムは、圧縮されているテキストの中で以前に見られたストリングの辞書を自動的に構築することが可能であるという洞察を中心に構築されている。これに関して、圧縮中に生成される辞書（例えば、もたらされる圧縮されたファイル）は、展開器が、圧縮器と同一の仕方で辞書を構築することができ、正しく符号化された場合、テキストにおける同一の箇所で圧縮器辞書が有するのと全く同一のストリングを有することになるので、圧縮されたテキストと一緒に伝送されなくてもよい。そのような構成において、辞書は、初期の圧縮に関連して、生成される。

本発明者らは、辞書を、圧縮中に生成する代わりに、データセットを圧縮する目的で圧縮器に与えることが可能であることを認識した。特に、本発明者らは、図２に示される第１の時刻Ｔ_０に関連する元のデータセットＶ_０を辞書として利用することで、その後の時刻Ｔ_１における後続の対応するデータセットＶ_１を圧縮可能であることを認識した。これに関して、圧縮器は、元のデータセットＶ_０を辞書として利用し、後続のデータセットＶ_１の中のデータの大きいストリングは、最初のセットにおけるストリングと完全に重複するものであり得る。例えば、図２に示されるとおり、時刻Ｔ_１におけるＶ_１の実際の格納は、時刻Ｔ_０におけるＶ_０のデータブロックに対応するいくつかのブロックを組み込む可能性がある。つまり、第２のデータセットＶ_１におけるブロックのいくつかは、データセットの間で変化していない。したがって、変化していないデータブロックを格納する（例えば、そのデータブロックを複製する）のではなく、ＶＯからの対応するデータブロックを参照する識別子が格納される。そのような識別子は、非常に小さい、例えば、１０バイトのオーダである。例えば、識別子は、ベースラインの辞書ブロックを参照することが可能である。データのブロック、例えば、３’に変更があった事例において、圧縮器は、３’の変更を、ベースラインＶ_０との違い、ならびにブロック３における変更を含むエントリに圧縮するように動作する。さらに、追加のテキストが、後続のバージョン（例えば、ブロック１０’）に加えられた場合、このテキストが、後続のバージョンＴ_１の中に保存される。

データセットの後続のバージョンの間で非常にわずかな変更が行われた場合、非常に大きい圧縮比が達成される。これらの圧縮比は、５０対１、１００対１、２００対１、またはそれより大きいものとなる。つまり、１０ページのテキストドキュメント内で単一の文字が変更された事例において、元のバージョンと後続のバージョンとの間の圧縮は、その１つのわずかな変更を除いて、ほとんど完全である。理解されるとおり、圧縮アルゴリズムのための起源の辞書として元のデータセットを利用することは、後続のデータセットの間の変化を容易に識別して、ベースラインデータセットＶ_０からの後続の変化を格納するのに、非常に少しのストレージしか要求しないものになる。したがって、データセットの後続のバージョンを再現することになった際に、データセットの所望されるバージョンに関する辞書識別子が識別される。これに関して、変化が全く存在しない場合、辞書識別子は、ベースラインデータセットＶ_０の元のブロックをポイントする。変化が存在する（例えば、３’または６’）場合、識別子は、元のベースラインデータセットおよびデルタデータセットをポイントする。そのような構成は、限られたストレージリソースを利用して、データセットの複数の後続のバージョンを保存することを可能にする。

この方法は、データセットの後続のバージョンのバックアップの間でわずかな変化しか存在しない場合、特にうまく機能する。しかし、以前にバックアップされたデータセットと比べてデータセットに相当な変化が生じている場合においてさえ、データのサイズの大幅な縮小が、依然として達せられる。例えば、元のデータセットが、１０ページのテキストドキュメントに相当し、後続の対応するドキュメントが、１５の新たなページを組み込む（すなわち、合計で２５ページ）場合、最初の１０ページは、ほぼ完璧な圧縮（例えば、２００対１）を実現する一方で、新たなテキストの１５ページは、例えば、２対１という、より普通の圧縮オーダで圧縮され得る。しかし、さらなる後続のバックアップ（例えば、第３のバージョン）が、バージョン１および２の新たなテキストをベースラインリファレンスとして利用することができる。代替として、圧縮が、或る所定の圧縮比閾値に達しない場合、変化が、データの元のバージョンを、その後、ベースライン値となる後続のデータバージョンで置き換えることが妥当とされるだけ十分に大きいと判定される。

図３は、ベースラインデータセットを利用して、データセットの後続のバージョンが圧縮される工程１００を示す。図示されるとおり、初期データセットが取得される（１０２）。このことには、この初期データセットを受け取り、格納すること、および／または、例えば、標準の圧縮技術を利用して、このデータセットを圧縮すること（１０４）が含まれる。これに関して、この初期データセットを表す圧縮ファイルが生成され、後の時点で、この初期データセットを利用することにより（１０６）、後続のデータセットにおける違いが識別される。そのような利用には、元のデータ（圧縮された、または圧縮されていない）で辞書ベースの圧縮エンジンを条件付けすること（１０８）、および元のデータセットを辞書として利用する圧縮エンジンを利用して、後続のデータセットを圧縮すること（１１０）が含まれる。このことにより、初期データセットと後続のデータセットとの間の変化を示す圧縮ファイルが生成される（１１２）。さらに、そのような圧縮ファイルは、圧縮辞書（例えば、元のデータセットおよび／または初期の圧縮ファイル）に対するリファレンスを含み得る。したがって、後続のデータセットを示す圧縮ファイルが、例えば、データ復元のために後でアクセス可能な、或る時点のアーカイブとして格納される（１１４）。後続の対応するデータセットの圧縮のための辞書としてベースラインデータセットを使用することにより、以下のアプリケーションのいくつかが、或る程度、容易になる。以下のアプリケーションは、それらの態様自体が新規である。

前述した圧縮技術を少なくとも或る程度、活用することが可能なアーカイビングサービスを提供するのに、初期データセットが、最初にカタログされなければならない。そのようなカタログは、データセットの様々な構成要素のロケーションのマップを形成し、後の時点におけるデータセットの再構成を可能にする。これに関して、データのセットが、そのデータのベースラインバージョンを生成するように初めてバックアップされる際に、そのデータが、１つまたは複数の知られているハッシュアルゴリズムを使用してハッシュされる。これに関して、初期カタログ工程は、主として、既存の工程と同様である。しかし、ハッシングを利用する他のアーカイビング工程とは異なり、このアプリケーションは、データセットの異なる部分に関して複数のハッシュを利用する。さらに、このアプリケーションは、共通の構成要素に関して２つ以上のハッシュを使用することが可能である。

例えば、データセットは、各々ハッシュされる異なる３つのデータストリームに分割される。これらのデータストリームは、異なるファイル、異なるフォルダ、および／または異なるデータセットに関するドライブ名／フォルダ名／ファイル名、および／またはサーバＩＤを含むベースラインリファレンスを含む。つまり、ベースラインリファレンスは、大きいデータセット／ブロックデータの識別と関係する。第２のハッシュが、ベースラインリファレンスのそれぞれに関するメタデータ（例えば、バージョンリファレンス）に対して実行される。この実施形態において、ベースラインリファレンス（例えば、ストレージロケーション）と関係する第１のハッシュは、第２のハッシュを形成するのに利用されるメタデータのサブセットである。これに関して、データセットの各ファイルに関連するメタデータは、いくつかの異なる特性を含み得る。例えば、そのような各バージョンリファレンスに関して１２〜１５のプロパティが存在する。これらのプロパティには、名前、パス、サーバおよびボリューム、最終変更時刻、ファイルリファレンスＩＤ、ファイルサイズ、ファイル属性、オブジェクトＩＤ、セキュリティＩＤ、および最終アーカイブ時刻が含まれる。最後に、各ベースラインリファレンスに関して、生のデータ、またはデータのＢｌｏｂ（バイナリラージオブジェクト）が存在する。一般に、データのそのようなＢｌｏｂは、ファイルコンテンツおよび／またはセキュリティ情報を含む。データセットをこれら３つの構成要素に分離して、これらの構成要素のそれぞれをハッシュすることにより、各データセットに対して、後続のバージョンに関する変化を識別する複数の検査を実行することが可能である。

第１のハッシュ
ベースラインリファレンス−Ｂｒｅｆ
１次フィールド
パス／フォルダ／ファイル名
ボリュームコンテキスト
修飾子
最終アーカイブ時刻
第２のハッシュ
バージョンリファレンス−Ｖｒｅｆ（１２〜１５のプロパティ）
１次フィールド（変化標識）
パス／フォルダ／ファイル名
リファレンスコンテキスト（１つまたは３つのフィールド）
ファイル最終変更時刻（２つのフィールド）
ファイルリファレンスＩＤ
ファイルサイズ（２つのフィールド）
２次フィールド（変化標識）
ファイル属性
ファイルオブジェクトＩＤ
ファイルセキュリティＩＤ
修飾子
最終アーカイブ時刻
第３のハッシュ（データの大半）
Ｂｌｏｂ（個々のデータストリーム）
１次データストリーム
セキュリティデータストリーム
残りのデータストリーム（オブジェクトＩＤストリームを除く）
別の構成において、合成ハッシュが、２つ以上のハッシュコードから作られる。つまり、ＶＲｅｆ識別子、ＢＲｅｆ識別子、およびＢｌｏｂ識別子は、２つのハッシュコードから構成される。例えば、高周波数（強い）ハッシュアルゴリズムが、低周波数（弱い）ハッシュアルゴリズムと共に利用される。弱ハッシュコードは、強ハッシュがどれだけ良好であるかを示し、確度の高いハッシュコード衝突（すなわち、合致するハッシュ）に関する１次標識である。代替として、さらに強い（より多くのバイト数の）ハッシュコードも利用可能であるが、さらに強いハッシュコードを生成するのに要求される処理時間が問題となる可能性がある。合成ハッシュコードは、以下のとおり表される。すなわち、
ｂａ＝“０１１５４９４３ｂ７ａ６ｅｅ０ｅ１ｂ３ｄｂ１ｄｄｆ０９９６ｅ９２４ｂ６０３２１ｄ”
｜強いハッシュ構成要素｜弱｜
｜高周波数｜低｜
これに関して、より大きい単一のハッシュコードと比べて、要求する処理リソースが合算して、より少ない２つのハッシュコードが、スタックされる。これによりもたらされるコードは、データセットの一部分／ファイルに関するさらなる情報を提供する。

一般に、図４に示されるとおり、初期データセットが、そのデータセットに関連するシグネチャを作成する（１２２）ために、ハッシュされて異なるプロパティになる。このシグネチャは、データセットの個々の部分（例えば、ファイル）に関するいくつかの異なるハッシュコードを含む。さらに、データセットの各部分は、互いに索引付け可能な複数のハッシュ（例えば、ハッシュ１〜３）を含む。例えば、データセットの各部分に関するハッシュは、メタデータ（例えば、ベースラインリファレンスおよび／またはバージョンリファレンス）に関連する識別子ハッシュ、およびデータセットのその部分のコンテンツに関連するコンテンツハッシュを含む。バックアップが実行可能となるように後続のデータセットが獲得されると（１２４）、その後続のデータセットがハッシュされて、シグネチャハッシュコードと比較するためのハッシュコードが生成される。

しかし、すべてのデータをハッシュすることとは異なり、一般に、データＢｌｏｂと比べて少ない量のデータを含む、後続のデータセットのメタデータおよびベースラインリファレンス、または識別子構成要素は、初期ベースライン格納以来、変更された、または追加されたファイル（例えば、合致しないハッシュ）を識別するために（１２８）、最初にハッシュされる（１２６）。これに関して、変更されているとして識別された合致しないハッシュのコンテンツ（例えば、ファイルのＢｌｏｂ）は、次に、ハッシュされて（１３０）、ベースラインデータセットの格納されたバージョンと比較される（１３２）。理解されるとおり、ファイルの名前が、第１のバックアップと第２のバックアップとの間で変わる場合がある。しかし、ファイルのテキストに全く変更が行われないことも珍しくない。そのような場合、バージョンリファレンス間のハッシュは、第１のバックアップと第２のバックアップとの間の変更時間における変化を示す。したがって、初期データセットに関連するコンテンツハッシュを識別し、これらのハッシュを、後続のデータセットのコンテンツハッシュと比較することが望ましい可能性がある。理解されるとおり、バックアップ間のドキュメントのテキストに全く変更が行われていない場合、コンテンツハッシュと、関連するデータ（例えば、Ｂｌｏｂ）とは、同一である。これに関して、名前が変更されたファイルに関連するデータを保存する（例えば、以前に保存されたデータを複製する）必要は全くない。したがって、新たなファイル名は、元のファイルのベースラインＢｌｏｂに対するリファレンスを共有することが可能である。同様に、同一のコンテンツを有するファイルが、同一のサーバの異なるボリューム上、または異なるサーバ上に存在可能である。例えば、ワークグループ内の多くのシステムは、ＭｉｃｒｏｓｏｆｔＷｏｒｄ（登録商標）に関するアプリケーションファイルの同一のコピー、またはＭｉｃｒｏｓｏｆｔＷｉｎｄｏｗｓ（登録商標）オペレーティングシステムを構成するファイルを含む。したがって、これらのファイルの各ファイルのファイルコンテンツは、同一である。これに関して、別のサーバ上で見られる同一のファイルに関連するデータを再保存する必要は全くない。したがって、ファイルは、別のボリューム、または別のサーバからの元のファイルのベースラインＢｌｏｂに対するリファレンスを共有する。データセットのベースラインバージョンからのデータセットの後続のバージョンにおいて合致しないコンテンツが存在する場合、後続のＢｌｏｂが、格納され（１３４）、および／または圧縮されて、格納される（１３４）。

重要なこととして、図４の工程１２０は、分散可能である。これに関して、格納されたデータに関連するハッシュコードは、データの起源ロケーションに供給される。つまり、初期データセットは、オフサイトのロケーションにおいて格納される。ハッシュコードをデータ起源ロケーションに供給することにより、何が新たなコンテンツであるかという判定が、データの起源ロケーションで行われる。したがって、新たなデータだけが、ストレージロケーションに転送されればよい。理解されるとおり、これにより、バックアップデータをオフサイトのストレージロケーションに転送するための帯域幅要件が低減される。

図５は、本発明のいくつかの態様に従ってデータをアーカイブするための工程の一実施形態を示す。最初、元のデータセットが、受け取られる（１）。このデータセットは、限定なしに、サーバ、データベース、またはファイルシステムから受け取られるデータを含む。このデータは、通常、このデータをバックアップする、またはアーカイブする目的で受け取られる。受け取られたデータ内の各アイテム／オブジェクト（例えば、ファイル、フォルダ、またはデータの任意のブロック）が処理され（２）、バージョンリファレンス（「Ｖｒｅｆ」）が計算される（３）。前述したとおり、Ｖｒｅｆは、オブジェクトのメタデータ３ａと関係する多数のフィールドを含む。これらのフィールドには、１次フィールドおよび２次フィールドが含まれる。これらのフィールドは、データセットの第１のインスタンスのアーカイビング（すなわち、バックアップ）と、後続のインスタンスのアーカイビング（すなわち、バックアップ）との間の変化を識別するのに利用される。

このことは、最初、オブジェクトデータが、アーカイブシステム内に存在するかどうかを判定することを可能にする。Ｖｒｅｆが計算されると（３）、Ｖｒｅｆはオブジェクトストア４ａに割り当てられる（４）。割り当てが行われると、共通コンテンツオブジェクトストアとの比較（５）が実行されて、そのＶｒｅｆに関連するオブジェクトが既に存在する（すなわち、前のアーカイブ動作から）かどうかが判定される（６）。この判定は、リファレンスルックアサイドテーブル７を利用して実行される。リファレンスルックアサイドテーブル７は、ＶｒｅｆハッシュコードおよびＢｒｅｆハッシュコードを含むテーブルである。いずれにしても、新たに受信されたデータからのオブジェクトのＶｒｅｆが、以前にアーカイブされたオブジェクトのＶｒｅｆと均等である場合、そのオブジェクトが、既に存在する可能性があるという判定が行われる。マッチが全く見出されない場合、処理は、本明細書で説明されるとおり進む。リファレンスルックアサイドテーブル７内でマッチが全く見出されない場合、オブジェクトの存在は、オブジェクトストアを探索することによってさらに判定される。マッチが見つかった場合、Ｖｒｅｆは、リファレンスルックアサイドテーブルにロードされる。

マッチが全く識別されない（例えば、オブジェクトが、新たなデータ、またはより早期のバックアップ以来、変更されているデータを表す）場合、データをアーカイブすることに関するストレージポリシーが選択される（８）。図示される実施形態では、汎用ポリシーが選択される。理解されるとおり、異なるデータタイプに関して異なるポリシーが選択される。例えば、知られていないデータに関して汎用ポリシーが選択される。これに対して、データの１つまたは複数の構成要素が知られているデータセットに関して、その特定のデータセットのニーズによりよく合致するポリシーを選択することが好ましい可能性がある。ポリシーが選択されると（９）、工程は、継続し、ベースラインリファレンス（「Ｂｒｅｆ」）９が、データソースの以前に合致しなかった各オブジェクト１０ａに関して計算される。Ｖｒｅｆデータのサブセットを利用して、ベースラインデータまたはＢｒｅｆデータが計算される。具体的には、前段で概説されるメタデータを利用して、ベースラインリファレンスオブジェクトに関するハッシュが計算される。

オブジェクトに関してＢｒｅｆ９が計算されると、Ｂｒｅｆは、ストアに割り当てられる（１１）。この割り当て（１１）は、対応するＶｒｅｆに関して行われた同一の割り当て（１１）に基づく。通常、計算されるＢｒｅｆは、最新のＢｒｅｆである。しかしながら、メタデータは、第１の時点と第２の時点（例えば、第１のアーカイビング工程と第２のアーカイビング工程）に関して同一である一方で、オブジェクトデータは、変化する可能性がある。そのような場合、現在のＢｒｅｆが、最新のＢｒｅｆであるかどうかの判定（１２）が、最終アーカイブ時刻修飾子を使用してオブジェクトストアの中の他のＢｒｅｆデータと比較することによって行われる。これにより、異なるアーカイビング工程の対応するオブジェクトの間で変更があったかどうかを確かめる冗長性検査が可能になる。

次に、現在のＢｒｅｆが、オブジェクトストア内に既に存在するかどうかの判定（１３）が行われる。この場合も、リファレンスルックアサイドテーブル７が、この判定のために利用される。これに関して、現在のＢｒｅｆデータのハッシュが、リファレンスルックアサイドテーブル７内の既存のハッシュと比較される。

オブジェクトが既に存在する場合、オブジェクトは、０と１の一連のバイナリデータを含むＢｌｏｂ（すなわち、バイナリラージオブジェクト）に解決される（１４）。Ｂｒｅｆを利用して、Ｖｒｅｆが調べられ、次に、Ｖｒｅｆを利用して、データの関連するＢｌｏｂが調べられる。一部の事例において、データのＢｌｏｂは、ルートベースラインＢｌｏｂである、さらなるＢｌｏｂを参照することが可能である。一部の事例において、共通のデータのＢｌｏｂが、多くのオブジェクトに関して存在する。例えば、多数の別々のコンピュータのオペレーティングシステムは、同一のファイルの多くを有して、実質的に同一であり得る。したがって、そのような別々のコンピュータのバックアップが実行される際、それらの共通のファイルに関する、もたらされるＢｌｏｂは、同一であることが可能である。したがって、異なるオブジェクトのＶｒｅｆおよびＢｒｅｆは、同一のＢｌｏｂを参照することが可能である。

ベースラインＢｌｏｂが探し出されると、このＢｌｏｂは、圧縮アルゴリズムのための辞書としてロードされる（１５）。Ｂｌｏｂは、辞書にロードされると（１５）、個々のデータチャンクに分割される。例えば、ベースラインＢｌｏｂは、３０ＫＢのデータチャンクに分割されるか、または操作者の選択に基づく他の任意のサイズのデータチャンクに分割される。これらの個々のチャンクは、圧縮アルゴリズムに事前に条件付けをするように圧縮器にロードされる。

事前に条件付けされることが可能である限り、複数の既知の圧縮技術のいずれも利用することができる。この事例では、圧縮アルゴリズムは、Ｂｌｏｂデータのいくつかの部分または全体で事前に条件付けられる。この時点まで、処理されたすべてのデータは、メタデータであった。しかし、この時点で、受け取られたオブジェクトは、ベースラインＢｌｏｂで事前に条件付けされた圧縮アルゴリズムを使用して圧縮される（１６）につれ、ハッシュされる。オブジェクトが、Ｂｒｅｆを有する場合、新たなオブジェクトとベースラインオブジェクトとの間の変化が、デルタＢｌｏｂ１７と呼ばれるアイテムのもたらされる圧縮によって特定される。オブジェクトが、Ｂｒｅｆを有する場合、対応するデルタＢｌｏｂは、しばしば、ベースラインＢｌｏｂのサイズの数分の１に過ぎず、１００：１という圧縮比が、珍しくない。

変化を識別する工程は、デルタＢｌｏｂ工程と呼ばれる。デルタＢｌｏｂ工程の出力は、ベースラインデータセットと新たなデータセットとの間の違いを表すバイナリデータセットであり、あるいはベースラインが存在しない場合、この出力が、将来の参照の目的でベースラインになることが可能である。いずれの場合でも、デルタＢｌｏｂまたはベースラインＢｌｏｂは、受け取られたデータのハッシュによって表され、現在、存在していない場合、オブジェクトストア５にコピー／格納される（１８）。なお、任意で、Ｂｒｅｆ、および対応するＶｒｅｆの、最終アーカイブ時刻修飾子によって特定される、より古いバージョン、およびベースラインＢｌｏｂまたはデルタＢｌｏｂデータが、オブジェクトストア内のスペースを空けるようにリサイクルされる。

理解されるとおり、前述したアーカイビングシステムは、完全に自己完結型であり、外部ストレージ要件を全く有さない。このため、オブジェクトストア５全体が、オフサイトの格納の目的で、単一の取り外し可能な媒体ユニット上でホストされる。すべての索引、すべてのリファレンス、およびすべてのコンテンツが、個々のアイテムとして単一のファイル構造内に保持されるため、さらに格納されたアイテムのいずれも、更新される必要がないので、オブジェクトストアを代替のロケーション、または遠隔ロケーションに複製するファシリティは、全く使用されない。この独特なストレージレイアウトは、任意の所与のディスク破損の影響を隔離する障害許容型の構造を提供する。さらに、アイテムの参照の完全性が、検証を可能にし、障害を隔離する。後続のアーカイビングジョブは、検出された破損を自己回復するのに使用可能である。取り外し可能な媒体に関して、ベースオブジェクトストアレイアウトおよびツリー深度が定義されると、同一の構造が、独立した時点をまたぐ媒体の連続的なローテーションを提供するような仕方で、任意の数の取り外し可能な媒体上に複製される。この工程は、テープ媒体ローテーションと同様であるが、共通のコンテンツが考慮に入れられるので、はるかに効率的である。この構造は、２０：１以上で均等の媒体ユニットに関する要件を緩和する。

図７および図８は、オブジェクトストアからのデータの再構成を示す。前述したとおり、この工程は、データのリアルタイムの、つまり、動的な、または「オンザフライ」の再構成を可能にする。そのような動的再構成を提供するのに、アーカイブされたデータは、データを再構成しようと試みるユーザがアクセスすることができる仮想ファイルシステムの中で表される。データを再構成するのに、所望されるオブジェクトまたはファイルのアドレスが、知られなければならない。そのアドレスがどのように知られるようになるかについて、後段で説明する。

最初に、システム内のすべてのデータが、オブジェクトストア内に格納され、図６に示されるとおり、仮想ファイルシステムの中で表される。図６は、この仮想ファイルシステムを使用して、この実施形態では、ウェブクライアントネットワークを使用して、アーカイブされたデータにアクセスすることを示す。しかし、アーカイブされたデータへのアクセスは、アーカイビングが所望されるシステムに接続されたスタンドアロンのユニットを介することも可能である。ＶＦＳ（仮想ファイルシステム）のいくつかの態様は、両方のシステムに適用可能である。ウェブクライアントネットワークの場合、アーカイブされたデータへのアクセスは、ＷｉｎｄｏｗｓＷｅｂＣｌｉｅｎｔサービスリダイレクタを使用してＷｅｂＤＡＶを介して達せられる。このリダイレクタは、ＵＮＣ（ユニバーサルネームコンベンション）パスを使用する、アーカイブされたデータへのアクセスを可能にする。この事例では、アーカイブされたデータを閲覧することへの入口点は、ＵＮＣパス、＼＼ｖｏｙａｇｅｒ＼ＯｂｊｅｃｔＳｔｏｒｅを介してである。さらに、ＷｅｂＣｌｉｅｎｔリダイレクタは、ドライブ名をＵＮＣパスにマップすることをサポートする。例えば、ドライブ名Ｌ：が、＼＼ｖｏｙａｇｅｒ＼ＯｂｊｅｃｔＳｔｏｒｅに割り当てられる。ドライブ名マッピングは、階層の任意のレベルに割り当てられることが可能であることに留意されたい。例えば、Ｘ：が、＼＼ｖｏｙａｇｅｒ＼ＯｂｊｅｃｔＳｔｏｒｅ＼ＩｍｐｏｒｔａｎｔＤｏｃｕｍｅｎｔｓに直接にマッピングされることも可能である。

図６は、ＶＦＳ階層におけるオブジェクトストアエントリを示す。この例では、オブジェクトストアインスタンスは、ＯｂｊｅｃｔＳｔｏｒｅと呼ばれる。オブジェクトストアは、複数のリソースからプールされた、アーカイブされたデータ（例えば、複数のソースからの共通のコンテンツ）と、或る特定の／個別のデータセットまたはカタログをより厳密に定義するアーカイブをともに含む。つまり、個々のデータセットには、それらのデータセット独自のアーカイブ（例えば、重要なドキュメント）内で索引が付けられる。これに関して、知られているデータセットに関連するデータを再構成しようと試みる際、オブジェクトストアの索引全体を探索するのではなく、そのデータセットのアーカイブが探索される。これにより、所望される情報に関して、大域的な索引を探索するのではなく、個別のアーカイブを探索することが可能になる。これにより、索引に関する格納要件、探索に関する計算要件、ならびにコアメモリ要件が低減される。

データセットが、システムの中に移動されるたびに、そのデータセットの現在の状態、または時点カタログが作成され、システム内に記録される。理解されるとおり、このことに必然的に伴うのは、データセットの生のデータを格納するのではなく、データに関連する情報（例えば、メタデータ）を格納することだけである（例えば、そのデータが、システム内に既に存在するものと想定して）。いずれにしても、データセットがシステム内に格納された時点が保存される。これにより、時点カタログ（例えば、図６のアーカイブされたＵＴＣエントリ）の生成がもたらされる。或る特定の時点に関するデータセットを表す各カタログは、或る特定のデータセットに関するすべてのメタデータの正確な表現を含む。しかし、或る特定の時点に関するデータセットに関連するすべての生のデータが、コピーされなければならない訳ではない。前述したとおり、前の時点と、現時点との間で変化したファイルだけが、システムの中にコピーされる。変化していないファイルに関して、時点カタログに関するメタデータは、前のカタログのデータに対する適切なリファレンスと一緒に格納される。

すべての情報、時点は、格納されなくてもよいので、多数のカタログが、多数の時点に関して生成され、保存される。つまり、限られた数の完全なバックアップデータセット（例えば、より新しいバックアップデータセットで定期的に置き換えられる）を提供し、データセットのそれぞれが、共通のデータの冗長なコピーを含むシステムではなく、比較的小さいカタログの使用が、データが再構成される時点の量を増加させることを可能にする。つまり、カタログは、ユーザに利用可能であるバックアップデータセットの細分性を大幅に高めることを可能にする。

つまり、各時点に関するデータを保存するのではなく、カタログは、所与の時点に関するデータを再現するためのコードを保存する。具体的には、或る時点に関するカタログは、仮想ファイルシステムによって、所与の時点に関するデータセットのレプリカを再現するのに使用される、各レコード（ファイル）に関する１つまたは複数のハッシュコードを含む。以下は、カタログの中の単一のレコードの例示的なサンプルであり、ｃａ、ｓａ、ｏａ、ｂａ、およびａａに関するエントリは、異なるデータストリームを表すハッシュコードである。例えば、＜ｃａ＞は、レコードに関するＶｒｅｆであり、或る特定のバージョンを識別するのに使用されるすべてのメタデータを組み込む。＜ｓａ＞は、セキュリティストリームに対するＢｌｏｂアドレス（ハッシュ）である。＜ｏａ＞は、オプションのオブジェクト識別ストリームに対するＢｌｏｂアドレスである。＜ｂａ＞は、１次Ｂｌｏｂアドレスである。＜ａａ＞は、代替の（または２次）Ｂｌｏｂアドレスである。

＜ｒｅｆｔｙ＝“２” ｎｍ＝“ｂｕｉｌｄ．ｐｒｏｐｅｒｔｉｅｓ．ｓａｍｐｌｅ” ｉｎ＝“＼ＬｉｔｔｌｅＴｅｓｔ” ｏｎ＝“３１６２６４５３０３” ｃｔ＝“１２８１０５３９１２８７９６８７５０” ａｔ＝“１２８１８６３６４５７１７１８７５０” ｍｔ＝“１２７４８３０６０７９０００００００” ｓｚ＝“１６４４” ｆｌ＝“１２８” ｉｄ＝“５６２９４９９５３４４８８２９４” ｃａ＝“１ｄ１６４９ｃｂ２ｂ３９８１６ｄ６９９６４ｃ１ｃ９５ａ４ａ６ａｄ７９ａ４１６８７” ｓａ＝“３ａｆ４ｅｃ９５８１８ｂｄｃ０６ａ６ｆ１０５１２３ｃ２７３７ｂｅ６ｅａ２８８ｄｆ” ｏａ＝“” ｂａ＝“０１１５４９４３ｂ７ａ６ｅｅ０ｅ１ｂ３ｄｂ１ｄｄｆ０９９６ｅ９２４ｂ６０３２１ｄ” ａａ＝“” ｏｐ＝“１”／＞
上記のとおり、カタログのこの部分は、所与のファイルのメタデータおよびコンテンツを探し出して、再現することを可能にするレコードを形成する。

図６を再び参照すると、カタログは、元のデータセットを表し、ボリューム、フォルダ、およびファイルを含む階層形態になっている。この階層におけるエントリのそれぞれは、エントリのプロパティを記述するメタデータを含む。さらに、フォルダレコードおよびファイルレコードは、Ｖｒｅｆアドレスを含み、タイムスタンプをアーカイブする。この階層は、バックアップされるデータセットの階層を模倣する。例えば、階層は、個々のユーザを含む。選択された特定のユーザ、例えば、マイク（Ｍｉｋｅ）に関して、そのユーザのコンピュータ、サーバなどのコンテンツが、そのユーザのコンピュータ、サーバなどと同一の仕方で格納される。

この階層は、前述したとおり、格納されたデータの任意のセットに遠隔でアクセスするのに使用可能であり、本明細書で説明されるアーカイビングシステム以外にも応用されるＶＦＳ（仮想ファイルシステム）の一部分として提示される。ユーザは、ＶＦＳ階層にアクセスして、オブジェクトストアの適切なアーカイブからデータを再構成することができる。これに関して、ユーザは、ユーザのスクリーン上で、図６に示される表現を見ることができる。ユーザは、或る特定のアーカイブまでＶＦＳの中を移動し、所望される時点カタログを選択して、そのフォルダを展開することができる。その時点で、その時点カタログより下の階層が提供されて、ユーザが、その時点カタログ内の所望されるドキュメントまで移動することができるようにする。つまり、ユーザは、ユーザが再構成したいと望むドキュメントを探し出すまで、ユーザの標準のストレージインタフェースを模倣するＶＦＳの中を移動することができる。特に、特定の時点が、ユーザによって全く選択されなくてもよい。例えば、探索エンジンが、各時点アーカイブを、そのアーカイブの中の所望されるデータに関して探索する能力を有してもよい。重要なこととして、ＶＦＳにアクセスするのに、特化されたクライアントアプリケーションは、全く要求されない。これに関して、許可されたユーザが、ユーザ自身のコンピュータ上で所望されるファイルにアクセスする場合と同様に、アーカイブされたデータセットにアクセスするためにユーザの標準のオペレーティングシステムを利用することができる。

前述したとおり、図６は、アーカイブされたデータの表現である。この場合、データは、ファイルシステムの完全に閲覧可能なバージョンをユーザが利用できるように複数回のアーカイビング実行によって保っているＷｉｎｄｏｗｓファイルシステムからである。注目すべきこととして、ＶＦＳにおける遷移は、アーカイビング時点階層が、止まり、ソースからのデータの表現が始まるＶＦＳ階層において生じる。この例では、遷移またはピボットは、「ＡｒｃｈｉｖｅｄＵＴＣ−２００６．０４．０３−２３．５７．０１．１２５」と名付けられている。階層においてこのポイントより下のフォルダは、アーカイビングタスクのためのファイル／フォルダ基準として指定されるルートファイルシステムを表す。「’ｖｏｙａｇｅｒ’上のユーザ（Ｕ＄）」は、Ｕｓｅｒというラベル、Ｕというドライブ名を有し、ｖｏｙａｇｅｒと名付けられたシステムからのファイルボリュームである。しかし、他のファイルシステム（例えば、非Ｗｉｎｄｏｗｓシステム）が表現されることも可能である。或る特定の時点に関してアーカイブ内で或るファイルレベルに到達すると、ユーザは、或る特定のファイルを選択することができる。すると、この選択により、バージョンリファレンスアドレス（Ｖｒｅｆ）が与えられ、アーカイブ時刻を利用して、その特定のファイルの再構成が始められる。

ＢｌｏｂアドレスをＶｒｅｆと共に格納することの重要性は、そうすることにより、そのアドレスが、Ｂｌｏｂであるか、またはデルタＢｌｏｂであるかにかかわらず、Ｖｒｅｆが、オブジェクトストア５内の実際のコンテンツを参照することが可能になることである。アドレスがデルタＢｌｏｂである場合、そのデルタＢｌｏｂは、ベースラインＢｌｏｂをさらに参照することが可能である。したがって、情報は、所望されるデータを再構成しようとして獲得される。この時点で、ベースラインＢｌｏｂ、および存在する場合、デルタＢｌｏｂが識別されており、つまり、データが、この時点で再構成される。

ユーザは、或る特定の期間からの（例えば、或る特定のＶｒｅｆに関する）データを再構成するために、アーカイブ時刻を指定することができる（３２）。理解されるとおり、実際のアーカイブ時刻は、ユーザによって与えられる、所望される期間と同一ではない可能性がある。いずれにしても、システムは、最も妥当な再構成時刻（例えば、所望される時刻より前、または所望される時刻のすぐ後に実行されたバックアップからのデータ）を特定する（３４）。初期ＶｒｅｆがデルタＢｌｏｂを有するかどうかについての初期判定（３６）が行われる。デルタＢｌｏｂが、このＶｒｅｆに関して存在する場合、そのデルタＢｌｏｂがオブジェクトストアから獲得される（３８）。また、対応するベースラインＢｌｏｂがオブジェクトストアから獲得される（４０）。デルタＢｌｏｂが存在しない場合、ベースラインＢｌｏｂだけが獲得される。Ｖｒｅｆが、圧縮されていないオブジェクト（例えば、個別のファイル）を参照する場合、その圧縮されていないオブジェクトが、後続の読み取りのために獲得される（４４）。

Ｂｌｏｂ（または圧縮されていないオブジェクト）は、獲得されると、圧縮されていないデータの出力を生成するように再構成される。図８を参照すると、この工程において、Ｖｒｅｆ（すなわち、デルタＢｌｏｂまたはベースラインＢｌｏｂを参照する）が、獲得されたＢｌｏｂからの個々のチャンクまたはバッファの中で再構成される。そのようなバッファの長さは、固定長であっても、可変長であってもよく、このことは、ユーザによって指定可能である。Ｖｒｅｆが、前述したとおり獲得されたデルタＢｌｏｂを参照する事例において、そのデルタＢｌｏｂが、次に、展開されて、Ｖｒｅｆデータが再構成される。オブジェクト（例えば、デルタＢｌｏｂ）が読み取られ（５２）、バッファ５４が一杯になるまで展開される。このことが、オブジェクト全体が展開されるまで、繰り返し反復される。デルタＢｌｏｂの各展開に関して、そのデルタＢｌｏｂの一部分が、バッファを埋めるのにベースラインの参照される部分を要求する可能性がある。これに関して、デルタＢｌｏｂのその特定の部分を展開する展開情報を提供する新たな辞書（例えば、ベースラインＢｌｏｂの部分）が要求されるかどうかの判定（５６）が行われる。つまり、必要な場合、システムは、デルタＢｌｏｂの現在の部分を展開する（６２）ように展開アルゴリズムに事前に条件付けをする（６０）開かれたベースラインＢｌｏｂの一部分を獲得する（５８）。

Ｖｒｅｆアドレスおよびアーカイブ時刻という２つのデータを所与として、これら２つのデータが、取り込まれ、正確なＶｒｅｆおよびアーカイブ時刻マッチ、または１つ前のＶｒｅｆアーカイブ時刻に関してオブジェクトストアを探索するのに利用される。図７を参照すると、例えば、再構成されるべき所望されるファイルが、より早期のバックアップ以来、変更されていない場合、Ｖｒｅｆアドレスは、そのファイルに関するデータが格納された実際の時刻を表す、より早期のＶｒｅｆ時刻を参照する。このレベルまで解決されると、Ｖｒｅｆの属性が読み取られて、そのＶｒｅｆが、デルタＶｒｅｆであるか、またはベースラインＶｒｅｆであるかが判定されるべきである。

デルタＢｌｏｂが存在せず、ベースラインＢｌｏｂだけが存在する場合（６４）、工程は、オブジェクトストアからのＶｒｅｆに基づいて、ベースラインＢｌｏｂを獲得し（６６）、バッファを埋めるようにベースラインＢｌｏｂを展開する（６８）。バッファが、展開されたデータで埋められると、データのこのバッファが、要求側ユーザに戻される。一つの構成では、オブジェクトは、圧縮されていないデータであることが可能である。この事例において、データセットが、圧縮されていない形態で存在し得る。そのような事例において、バッファは、展開工程を要求することなしに埋められる（７０）。バッファを埋めること、および戻すことは、例えば、ファイルの終わりに達するまで、繰り返される。データセットから複数のファイル（例えば、複数のＶｒｅｆ）を取得可能であることが理解される。さらに、データセット全体を取得することも可能である。

適応コンテンツファクタリング技術に関する一つの応用例は、従来のディスクベースのバックアップから情報を取り入れることである。ほとんどの場合において、相当な量の情報が２つの完全なバックアップデータセットの間で共通である。共通のデータを除外することにより、所与のストレージデバイスの有効容量が、機能の損失なしに、アーカイビングシステムの向上した性能を伴って、大幅に増加する。このことにより、長期のディスクベースのアーカイビングが、経済的に実現可能となる。そのようなアーカイビングは、ローカルで実行することも、ネットワークを介して実行することも可能である。例えば、図９を参照すると、当業者には理解されるとおり、ネットワーク帯域幅が低下するにつれ、所与のデータセットの共通のコンテンツを識別して、遠隔サーバから中央アーカイブに変更だけを送信することが有利である。これに関して、コンテンツが既に格納されているかどうかを判定するのに使用される索引が、ネットワーク８０を介して効率的に格納され、分散されることから、前述した新規なアプローチは特にうまく機能する。所与のデータセット、または同様のデータセットに固有のコンテンツ索引を作成して、保持することにより、索引の対応するサイズが、局所化されたコンテンツに縮小される。例えば、索引におけるエントリが、１アイテム当たり８バイトである場合、データセットは、５００００のアイテムを含む。索引の対応するサイズは、４０００００バイトに過ぎない。このことは、アーカイブされた数百万の離散的なアイテムに対する一体構造の索引を使用する他のシステムとは対照的である。このため、より小さい分散型の索引が、ローカルで、またはネットワークにおいて格納される。一部の場合において、索引をローカルで格納することが好ましい可能性がある。索引が、ネットワーク内に格納される場合、索引の小さいサイズにより、索引は、ローカルプログラムメモリに効率的にロードされて、ローカルコンテンツファクタリングを円滑にする。

説明される技術は、共通のコンテンツに対する索引のローカルでキャッシュ可能なネットワークを提供する。つまり、複数のサーバ／コンピュータ８２が、共通のストレージファシリティ８４を共有することが可能である。このコンテンツは、共通のコンテンツが共有されてストレージ要件を低減するように、アーカイビング機器８８によって処理される。必要なカタログは、共通ストレージファシリティ８４において、または２次ストレージ８６において格納される。個々のサーバ／コンピュータをバックアップ可能にするのに、この技術は、データセットごとに分散型の索引を使用する。つまり、識別子とコンテンツハッシュの固有のセットが、特定のサーバ／コンピュータに提供される。一般に、索引内の情報は、データセット内の所与のアイテムに対するハッシュ（例えば、Ｖｒｅｆ）に対応する。しかし、理解されるとおり、データセットが、異なるホストシステムからのアイテムに対応する場合でさえ、異なるデータセット間のデータセット内のアイテムに共通する可能性があるファイルセキュリティ情報またはオブジェクトセキュリティ情報などの、非常によく参照されるコンテンツ索引またはＢｌｏｂ索引を格納して、これらのＢｌｏｂが既に格納されていることを迅速に識別することも望ましい。これに関して、この技術は、元のデータセットコンテンツを、一連のＢｌｏｂアドレスと、その後に続く０で埋められたバイトアレイで置き換えることによって、Ｂｌｏｂに対する代替の索引を使用する。Ｂｌｏｂアドレスと、これに加えられた、０で埋められたアレイは、元のコンテンツの各セグメントの論理サイズと完全に合致するようになっている。当業者には理解されるとおり、０で埋められたアレイは、いくつものデータ圧縮アルゴリズムによって極めて容易に圧縮可能である。本発明は、データセットをまず、離散的なオブジェクトデータストリームに分割し、各オブジェクトデータストリームを、後段で説明されるＭ３工程、または類似した工程を使用して以前にアーカイブされた、または同時にアーカイブされるコンテンツ（またはＢｌｏｂ）に対するストリームアドレスで置き換え、次に、再マップされたデータストリームの残りの部分を０で埋めることによって、任意の知られているファイルフォーマットで機能する。最後に、この再マップされたストリームが、圧縮され、これにより、０で埋められたアレイにおける冗長性が基本的に取り除かれる。もたらされるファイルが、データストリームコンテンツの再マッピングを除いて、オリジナルと区別ができないことが望ましい。これに関して、ビットフラグが、元のファイルのメタデータ内で使用されて、ストリームデータが置き換えられていることを示して、データストリームが再マップされていると、元のデータを作成した元のプログラムを判定することができる。本発明は、ヘッダチェックサムにこだわらずに、ストリームヘッダの中で予約フラグを設定する。起元プログラムは、データセットをカタログすることができるが、データストリームが読み取られると、チェックサムが検査される。予約フラグが設定されているため、チェックサム試験は、不合格となり、アプリケーションが、再マップされたストリームを間違って読み取ることが防止される。図１０は、この工程を示す。ストリームアドレスの特定は、データセット内部に格納されたメタデータを使用する完全な工程を使用し、ストリームＢｌｏｂアドレスを特定する逆ルックアップを含むこと、またはストリームデータに対してハッシュアルゴリズムを使用して、一意のストリームＢｌｏｂアドレスを計算することが可能である。アンマップ工程は、動作の順序を単に逆にして、各Ｂｌｏｂアドレスと０で埋められたアレイが、元のコンテンツで置き換えられ、予約フラグが設定解除されるようにする。このアンマップ再構成工程の結果は、元のデータセットと同一のコピーである。

以上の説明は、例示および説明の目的で提示されてきた。さらに、この説明は、本発明を、本明細書で開示される形態に限定することを意図していない。いくつかの例示的な態様および実施形態が、以上に説明されてきたが、これらの態様および実施形態の、いくつかの変種、変形、置換、追加、および部分的組み合わせが、当業者には認識される。したがって、添付の特許請求の範囲は、本発明の思想および範囲に含まれる、すべてのそのような変種、変形、置換、追加、および部分的組み合わせを含むように解釈されることが意図される。

データセットの長期格納要件を示す図。バージョン間のデータセットに対する変更を示す図。関連するデータセット間の違いを識別するための工程を示す図。データセットに関するシグネチャを生成するための工程を示す図。データを格納するための工程を示す図。複数のアーカイブカタログのアクセス可能なカタログを示す図。データを取得するための工程を示す図。データを再構成するための工程を示す図。ネットワークを介するデータの格納を示す図。コンテンツデータと一緒にメタデータを格納することの一実施形態を示す図。

Claims

データをアーカイブする／格納する際に使用する、コンピュータにて実行される方法であって、
第１の時刻で生成されたデータセットの第１のバージョンをコンピュータで処理して、前記データセットの前記第１のバージョンのメタデータに関連する識別子ハッシュと、前記データセットの前記第１のバージョンのコンテンツに関連するコンテンツハッシュとを含む第１のシグネチャを生成すること、
前記第１のシグネチャをデータストレージに格納すること、
前記コンピュータを用いて前記第１のシグネチャの前記識別子ハッシュ及び前記コンテンツハッシュのうちの少なくとも１つを、後続の第２の時刻で生成された前記データセットの第２のバージョンにおける第２のシグネチャの識別子ハッシュ及びコンテンツハッシュのうちの１つと比較すること、
前記識別子ハッシュ及び前記コンテンツハッシュのうちの１つで識別された変化に基づき、前記データセットの前記第１のバージョンのコンテンツを用いて辞書ベース圧縮アルゴリズムの辞書を格納して条件付き圧縮アルゴリズムを定義するとともに、前記データセットの前記第１のバージョンのコンテンツを用いて辞書として格納された前記条件付き圧縮アルゴリズムを用いて前記データセットの前記第２のバージョンを圧縮すること、
を備え、前記データセットの前記第２のバージョンを表す圧縮ファイルが前記データセットの前記第１のバージョンと前記データセットの前記第２のバージョンとの間の変化を含むように生成されて前記データストレージに格納される、方法。
前記第１のシグネチャは第１のネットワークロケーションに格納され、前記データセットの前記第２のバージョンは第２のネットワークロケーションに位置づけられ、当該方法はさらに、
前記第１のネットワークロケーションから前記第２のネットワークロケーションに前記第１のシグネチャを転送すること、
前記第１のシグネチャの少なくとも１つのハッシュを、前記第２のネットワークロケーションにおける前記第２のシグネチャのハッシュと比較すること、
を備える、請求項１に記載の方法。
前記ハッシュ間の違いを識別した場合、前記データセットの前記第２のバージョンの少なくとも一部分を、格納のために前記第１のネットワークロケーションに転送することをさらに備える請求項２に記載の方法。
前記転送することは、ネットワークインタフェースを介して前記第１のシグネチャを転送することを含む、請求項２に記載の方法。
前記データセットの前記第１のバージョンを処理して前記識別子ハッシュを生成することは、メタデータ構成要素の第１および第２のセットにそれぞれ関連する第１および第２の識別子ハッシュを生成することをさらに含み、前記メタデータ構成要素の前記第１のセットと前記第２のセットとは異なる、請求項１に記載の方法。
データ格納の際に使用する、コンピュータにて実行される方法であって、
第１の時刻で生成されたデータセットの第１のバージョンをデータストレージロケーションに転送すること、
前記データセットの前記第１のバージョンをコンピュータで処理して、前記データセットの前記第１のバージョンのメタデータに関連する識別子ハッシュセットと、前記データセットの前記第１のバージョンのコンテンツに関連するコンテンツハッシュセットとを含むシグネチャを生成すること、
前記データセットの前記第１のバージョンを転送することの後に、第２の時刻で生成された前記データセットの第２のバージョンをコンピュータで処理して前記データセットの前記第２のバージョンのメタデータに関連する識別子ハッシュセットを生成し、前記データセットの前記第１のバージョンの識別子ハッシュセットと前記データセットの前記第２のバージョンの識別子ハッシュセットとを比較し、前記比較に基づいて前記データセットの前記第２のバージョンに関する合致しない識別子ハッシュを識別し、前記合致しない識別子ハッシュに関連するコンテンツの少なくとも一部分を前記データストレージロケーションに転送すること、
前記データセットの前記第１のバージョンの対応するコンテンツを用いて辞書ベース圧縮アルゴリズムの辞書を格納して条件付き圧縮アルゴリズムを定義すること、
前記データセットの前記第１のバージョンのコンテンツを用いて辞書として格納された前記条件付き圧縮アルゴリズムを用いて前記データセットの前記第２のバージョンのコンテンツを圧縮すること、
を備え、前記データセットの前記第２のバージョンを表す圧縮ファイルが、前記データセットの前記第１のバージョンと前記データセットの前記第２のバージョンとの間の変化を含み前記データセットの前記第２のバージョンのバックアップを定義するように生成されてデータストレージロケーションに格納される、方法。
前記データセットの前記第１のバージョンの識別子ハッシュと合致する前記データセットの前記第２のバージョンの識別子ハッシュに関連するコンテンツは、前記データストレージロケーションに転送されない、請求項６に記載の方法。
前記データセットの前記第２のバージョンの少なくとも１つの合致しないハッシュに関連するコンテンツに関するコンテンツハッシュを生成すること、
前記データセットの前記第１のバージョンに関して、合致するコンテンツハッシュが存在するかどうかを判定すること、
をさらに備える請求項６に記載の方法。
前記データセットの前記第１のバージョンに関して、前記合致するコンテンツハッシュが存在する場合、前記データストレージロケーションへの前記コンテンツの転送を差し控えること、
前記データセットの前記第１のバージョンに関して、合致するコンテンツハッシュが存在しない場合、前記データストレージロケーションに前記コンテンツを転送すること、
をさらに備える請求項８に記載の方法。
前記データセットの前記第１のバージョンは、ネットワークを介して起源ロケーションから前記データストレージロケーションに転送される、請求項６に記載の方法。
前記シグネチャは、前記データストレージロケーションに生成される、請求項１０に記載の方法。
前記データストレージロケーションから前記データセットの前記第２のバージョンの起源ロケーションに前記シグネチャを転送することをさらに備え、前記ハッシュの比較は、前記起源ロケーションにおいて実行される、請求項１０に記載の方法。