特許 6033241 データー重複排除のためのバックアップおよび復元方策

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6033241

(24)【登録日】2016年11月4日

(45)【発行日】2016年11月30日

(54)【発明の名称】データー重複排除のためのバックアップおよび復元方策

(51)【国際特許分類】

   G06F 12/00 20060101AFI20161121BHJP

【ＦＩ】

   G06F12/00 531M

【請求項の数】14

【全頁数】59

(21)【出願番号】特願2013-558039(P2013-558039)

(86)(22)【出願日】2012年3月3日

(65)【公表番号】特表2014-508362(P2014-508362A)

(43)【公表日】2014年4月3日

(86)【国際出願番号】US2012027636

(87)【国際公開番号】WO2012125314

(87)【国際公開日】20120920

【審査請求日】2015年1月30日

(31)【優先権主張番号】13/045,692

(32)【優先日】2011年3月11日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】314015767

【氏名又は名称】マイクロソフト テクノロジー ライセンシング，エルエルシー

(74)【代理人】

【識別番号】100140109

【弁理士】

【氏名又は名称】小野 新次郎

(74)【代理人】

【識別番号】100075270

【弁理士】

【氏名又は名称】小林 泰

(74)【代理人】

【識別番号】100101373

【弁理士】

【氏名又は名称】竹内 茂雄

(74)【代理人】

【識別番号】100118902

【弁理士】

【氏名又は名称】山本 修

(74)【代理人】

【識別番号】100153028

【弁理士】

【氏名又は名称】上田 忠

(74)【代理人】

【識別番号】100120112

【弁理士】

【氏名又は名称】中西 基晴

(74)【代理人】

【識別番号】100196508

【弁理士】

【氏名又は名称】松尾 淳一

(74)【代理人】

【識別番号】100147991

【弁理士】

【氏名又は名称】鳥居 健一

(74)【代理人】

【識別番号】100119781

【弁理士】

【氏名又は名称】中村 彰吾

(74)【代理人】

【識別番号】100162846

【弁理士】

【氏名又は名称】大牧 綾子

(74)【代理人】

【識別番号】100173565

【弁理士】

【氏名又は名称】末松 亮太

(74)【代理人】

【識別番号】100138759

【弁理士】

【氏名又は名称】大房 直樹

(72)【発明者】

【氏名】カラチ，ラン

(72)【発明者】

【氏名】チャン，チュン・ホー（イアン）

(72)【発明者】

【氏名】オルティーン，ポール・エイドリアン

(72)【発明者】

【氏名】ディクソン，マシュー・ジェームズ

【審査官】 篠塚 隆

(56)【参考文献】

【文献】 国際公開第２００９／０８７０２８（ＷＯ，Ａ１）

【文献】 特開２００８−２５７７１６（ＪＰ，Ａ）

【文献】 特開２００８−２９９４４１（ＪＰ，Ａ）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ１２／００

(57)【特許請求の範囲】

【請求項1】

データー・ストリーム・バックアップ方法であって、
チャンク・ストアに格納されている複数の最適化データー・ストリームをバックアップのために特定するステップであって、前記チャンク・ストアが、各最適化データー・ストリームを、複数のチャンクおよび対応する最適化ストリーム・メタデーターとして含み、前記複数のチャンクが少なくとも１つのデーター・チャンクを含み、前記対応する最適化ストリーム・メタデーターが前記少なくとも１つのデーター・チャンクを参照し、前記チャンク・ストアが、含まれるデーター・チャンクの全てを、重複解除した様式で含む、ステップと、
前記複数の最適化データー・ストリームをバックアップするために、前記チャンク・ストアの少なくとも一部をバックアップ・ストレージに格納するステップと、
を備えている、方法において、
前記格納するステップが、
バックアップの対象として特定された複数の最適化データー・ストリームの最適化サイズと論理サイズとの間の差に基づいてバックアップ技法におけるトレードオフを求め、前記バックアップ技法におけるトレードオフに基づいてバックアップ技法を選択するステップと、
前記複数の最適化データー・ストリームを前記バックアップ・ストレージにバックアップするために、前記バックアップ技法を実行するステップと、
を含む、方法。

【請求項2】

請求項１に記載の方法において、前記格納するステップが、
前記チャンク・ストアの全体を前記バックアップ・ストレージに格納するステップと、
前記複数の最適化データー・ストリームに対して、複数のストリーム・メタデーター・スタブを前記バックアップ・ストレージに格納するステップであって、各ストリーム・メタデーター・スタブが、データー・ストリームを前記チャンク・ストアにおける対応するデーターにリンクする、ステップと、
を含む、方法。

【請求項3】

請求項１又は２に記載の方法において、前記格納するステップが、
各最適化データー・ストリームをリハイドレートし、前記対応する最適化ストリーム・メタデーターによって参照されているいずれかのチャンクを含む、対応する無最適化データー・ストリームにするステップと、
各無最適化データー・ストリームを前記バックアップ・ストレージに格納するステップであって、前記チャンク・ストアを、前記バックアップ・ストレージに格納することから除外する、ステップと、
を含む、方法。

【請求項4】

請求項１〜３のいずれか一項に記載の方法において、前記格納するステップが、
バックアップのために特定された第１最適化データー・ストリームを受け取るステップと、
前記第１最適化データー・ストリームの最適化ストリーム・メタデーターによって参照されているデーター・チャンクの内、前記バックアップ・ストレージに未だ格納されていない１つ以上を判定するステップと、
前記第１最適化データー・ストリームの最適化ストリーム・メタデーターを前記バックアップ・ストレージに格納するステップと、
前記判定された１つ以上のデーター・チャンクを前記バックアップ・ストレージに格納するステップと、
を含む、方法。

【請求項5】

請求項１〜４のいずれか一項に記載の方法において、前記格納するステップが、
各最適化データー・ストリームに対応する前記最適化ストリーム・メタデーターを分析して、前記最適化ストリーム・メタデーターによって参照されている少なくとも１つのデーター・チャンクに対して、対応する少なくとも１つのデーター・チャンク識別子を決定するステップと、
最適化データー・ストリーム毎の最適化ストリーム構造を、前記バックアップ・ストレージに、前記対応する少なくとも１つのデーター・チャンク識別子と共に格納するステップと、
前記最適化データー・ストリームのデーター・チャンクを格納する前記チャンク・ストアの１つ以上のチャンク・コンテナを前記バックアップ・ストレージに格納するステップと、
を含む、方法。

【請求項6】

請求項１〜５のいずれか一項に記載の方法において、前記バックアップ技法におけるトレードオフに基づいてバックアップ技法を選択するステップが、
除外モードまたは包含モードにしたがって、前記複数の最適化データー・ストリームがバックアップのために選択されたか否か判断するステップであって、前記除外モードが、少なくとも１つのボリュームを特定してバックアップのために選択し、１つ以上のデーター・ストリームを特定してバックアップから除外するように選択する第１バックアップ・モードであり、前記包含モードが、少なくとも１つのデーター・ストリームを特定してバックアップのために選択する第２バックアップ・モードである、ステップと、
前記除外モードが選択されたと判断した場合、前記バックアップ技法が最適化データー・ストリーム・バックアップ技法となるように選択するステップと、
前記包含モードが選択されたと判断した場合、前記バックアップ技法が無最適化データー・ストリーム・バックアップ技法となるように選択するステップと、
を含む、方法。

【請求項7】

請求項１〜６のいずれか一項に記載の方法において、前記バックアップ技法におけるトレードオフに基づいてバックアップ技法を選択するステップが、
前記チャンク・ストアにおいて、バックアップのために特定された前記複数の最適化データー・ストリームによって参照されていない前記データー・チャンクによって消費される第１空間量を判定するステップと、
前記複数の最適化データー・ストリームの全てを無最適形式で格納するための空間量から、前記複数の最適化データー・ストリームの全てを最適化形式で格納するための空間量を差し引いた値として、第２空間量を判定するステップと、
前記判定した第１空間量が、前記判定した第２空間量よりも小さい場合、前記バックアップ技法が最適化データー・ストリーム・バックアップ技法となるように選択するステップと、
前記判定した第１空間量が、前記判定した第２空間量よりも大きい場合、前記バックアップ技法が無最適化データー・ストリーム・バックアップ技法となるように選択するステップと、
を含む、方法。

【請求項8】

請求項１〜７のいずれか一項に記載の方法において、前記バックアップ技法におけるトレードオフに基づいてバックアップ技法を選択するステップが、
バックアップのために特定された前記複数のデーター・ストリームの全てを無最適化形式で格納するための空間量として、第１空間量を判定するステップと、
バックアップのために特定された前記複数のデーター・ストリームの全てを最適化形式で格納するための空間量として、第２空間量を判定するステップと、
前記判定した第１空間量が、前記判定した第２空間量よりも大きい場合、前記バックアップ技法が最適化データー・ストリーム・バックアップ技法となるように選択するステップと、
前記判定した第１空間量が、前記判定した第２空間量よりも小さい場合、前記バックアップ技法が無最適化データー・ストリーム・バックアップ技法となるように選択するステップと、
を含む、方法。

【請求項9】

請求項１〜８のいずれか一項に記載の方法を実行するためのプログラム。

【請求項10】

請求項１〜８のいずれか一項に記載の方法を実行するためのプログラムを記録した記録媒体。

【請求項11】

システムであって、
チャンク・ストアに格納されている複数の最適化データー・ストリームの識別を、バックアップのために受け取るデーター・バックアップ・モジュールであって、前記チャンク・ストアが、各最適化データー・ストリームを、複数のチャンクおよび対応する最適化ストリーム・メタデーターとして含み、前記複数のチャンクが少なくとも１つのデーター・チャンクを含み、前記対応する最適化ストリーム・メタデーターが前記少なくとも１つのデーター・チャンクを参照し、前記チャンク・ストアが、含まれるデーター・チャンクの全てを重複解除した様式で含む、データー・バックアップ・モジュールを備えており、
前記データー・バックアップ・モジュールが、前記複数の最適化データー・ストリームをバックアップするために、前記チャンク・ストアの少なくとも一部をバックアップ・ストレージに格納するように構成されている、
システムにおいて、
前記データー・バックアップ・モジュールが、バックアップの対象として特定された複数の最適化データー・ストリームの最適化サイズと論理サイズとの間の差に基づいてバックアップ技法におけるトレードオフを求め、前記バックアップ技法におけるトレードオフに基づいてバックアップ技法を選択し、前記複数の最適化データー・ストリームを前記バックアップ・ストレージにバックアップするために、前記バックアップ技法を実行することを可能にするように構成されているモジュールを含む、システム。

【請求項12】

請求項１１に記載のシステムにおいて、前記データー・バックアップ・モジュールが、
前記チャンク・ストア全体を前記バックアップ・ストレージに格納するように構成されている最適化ファイル・バックアップ・モジュール、
各最適化データー・ストリームをリハイドレートして、前記対応する最適化ストリーム・メタデーターによって参照されているいずれのデーター・チャンクをも含む、対応する無最適化データー・ストリームにし、各無最適化データー・ストリームを前記バックアップ・ストレージに格納するように構成されているリハイドレーション・バックアップ・モジュール、
最適化データー・ストリーム毎に、前記最適化データー・ストリームの最適化ストリーム・メタデーターによって参照され未だ前記バックアップ・ストレージに格納されていない１つ以上のデーター・チャンクを判定し、前記最適化データー・ストリームの最適化ストリーム・メタデーターを前記バックアップ・ストレージに格納し、前記判定した１つ以上のデーター・チャンクを前記バックアップ・ストレージに格納するように構成されている項目レベル・バックアップ・モジュール、または、
各最適化データー・ストリームに対応する前記最適化ストリーム・メタデーターを分析して、前記最適化ストリーム・メタデーターによって参照されている少なくとも１つのデーター・チャンクに対して、対応する少なくとも１つのデーター・チャンク識別子を決定し、各最適化データー・ストリームを前記バックアップ・ストレージに、前記対応する少なくとも１つのデーター・チャンク識別子と共に格納し、前記最適化データー・ストリームのデーター・チャンクを格納する前記チャンク・ストアの１つ以上のチャンク・コンテナを前記バックアップ・ストレージに格納するように構成されているデーター・チャンク識別子バックアップ・モジュール、
の内少なくとも１つを備えている、システム。

【請求項13】

請求項１１又は１２に記載のシステムであって、更に、
前記バックアップ・ストレージにおけるチャンク・ストアからデーター・ストリームを引き出す要求を受けるファイル・リコンストラクターであって、前記要求が、前記データー・ストリームに対応する最適化ストリーム・メタデーターの識別子を含む、ファイル・リコンストラクターを備えており、
前記ファイル・リコンストラクターが、前記最適化ストリーム・メタデーター識別子に基づいて復元アプリケーションに第１コールを生成するコールバック・モジュールを含み、前記第１コールが、前記最適化ストリーム・メタデーター識別子によって特定される最適化ストリーム・メタデーターを格納するバックアップ・ストレージにおける第１チャンク・コンテナにファイル名称を指定し、前記第１チャンク・コンテナにおける前記最適化ストリーム・メタデーターにオフセットを指定し、
前記ファイル・リコンストラクターが、前記第１コールに応答して、前記最適化ストリーム・メタデーターを受け取り、前記最適化ストリーム・メタデーターにおいて参照されている少なくとも１つのデーター・チャンク識別子を判定し、
前記コールバック・モジュールが、前記バックアップ・ストレージにおける少なくとも１つのチャンク・コンテナから少なくとも１つのデーター・チャンクを得るために、前記少なくとも１つのデーター・チャンク識別子に対応して、前記復元アプリケーションに少なくとも１つの追加のコールを生成し、
前記ファイル・リコンストラクターが、前記少なくとも１つの追加のコールに応答して、前記少なくとも１つのデーター・チャンクを受け取り、前記データー・ストリームを復元するために前記少なくとも１つのデーター・チャンクを組み合わせる、システム。

【請求項14】

請求項１３に記載のシステムにおいて、前記コールバック・モジュールが、チャンク・コンテナをソートしたリストを生成するために、追加のコールを前記復元アプリケーションに対して生成し、
前記コールバック・モジュールが、前記ソートしたリストによって定められた順序で前記複数のデーター・チャンクに対応する複数の追加のコールを前記復元アプリケーションに対して生成する、システム。

【発明の詳細な説明】

【背景技術】

【0001】

[0001] データー重複排除は、データー最適化としても知られており、元のデーターの忠実性や完全性を損なうことなく、ディスク上に格納する、またはネットワークを跨いで送信する必要があるデーターの物理的バイト量を低減する動作(act)である。データー重複排除は、データーを格納するために必要とされる記憶容量を削減し、したがって、ストレージ・ハードウェアのコストおよびデーター管理コストに関して節約をもたらすことができる。データー重複排除は、急速に増大するディジタル格納データーを処理することに対する解決策を提供する。

【0002】

[0002] データー重複排除は、１つ以上の技法にしたがって、永続的に格納されるファイル内部およびこれらのファイル間における冗長性を排除するために実行することができる。例えば、１つの技法によれば、１つ以上のファイルにおいて多数回出現する一意のデーター領域を特定することができ、これら特定した一意のデーター領域の１つのコピーを物理的に格納することができる。これら特定した一意のデーター領域（データー「チャンク」とも呼ぶ）に対する参照を格納することができ、この参照は、当該ファイルと、これらを含むファイル内の位置を示す。この技法は、一般に単一インスタンス化(single instancing)と呼ばれている。単一インスタンス化に加えて、データーの圧縮も実行することができる。また、データー重複排除解解決手段の一部として、他のデーター削減技法を実施することもできる。

【発明の概要】

【0003】

[0003] データー重複排除技法にしたがって格納されたデーターを管理する際に、困難が生ずる。例えば、データー重複排除によって強制されるデーター断片化のために、重複排除にしたがって格納されたファイルにアクセスするときに、レイテンシーが生ずる可能性がある。このレイテンシーのために、特に、ユーザーがシームレスで高速なファイルへのアクセスを期待する主記憶データーに対して、データー重複排除解決策の採用が抑えられる。更に、重複排除アルゴリズムは、専用機器(appliance)上またはデーターを格納および供給するデバイス（例えば、ファイル・サーバ）上において実行する場合がある。ファイル・サーバの場合、データー重複排除はデバイスの主要機能ではないかもしれず、したがって、デバイスのリソース（例えば、メモリー、入力／出力（Ｉ／Ｏ）メカニズム、中央演算装置（ＣＰＵ）容量等）を消費し過ぎないように、効率的でなければならないと考えられる。更にまた、ディジタル・データーの量は非常に高い速度で増大しつつあり、記憶デバイス（例えば、記憶ディスク）のサイズ、および計算デバイスに付随する総記憶容量も増大しており、増大する記憶量と共にうまく増減しない(scale)データー重複排除技法では困難が生ずる。データー重複排除は、データーの圧縮によって、バックアップするデーターを少なくして、データー・バックアップを一層迅速に行うことを可能にし、その結果、バックアップしたデーターの復元を高速化することができる。しかしながら、重複排除したデーターをバックアップし、バックアップ・ストレージから重複排除したデーターを復元するときに課題がある。

【0004】

[0004] この摘要は、詳細な説明の章において以下で更に説明する概念から選択したものを簡略化された形式で紹介するために、設けられている。この摘要は、特許請求する主題の主要な特徴や必須の特徴を特定することを意図するのではなく、特許請求する主題の範囲を限定するために使用されることを意図するのでもない。

【0005】

[0005] 最適化したデーター・ストリームをバックアップ・ストレージにバックアップし、バックアップ・ストレージからデーター・ストリームを復元する方法、システム、およびコンピューター・プログラム生産物を提供する。本明細書における最適化データーとは、チャンクの単一インスタンス化または圧縮というような１つ以上のデーター重複排除技法によって、最適化されたデーター、即ち、重複排除されたデーターを指す。最適化ストリームとは、重複排除されたストリームを指し、言い換えると、データー重複排除技法を用いてそのデーターが最適化されたということである。

【0006】

[0006] 例えば、最適化データー・ストリームのバックアップのための実施態様について記載する。チャンク・ストアは、複数の最適化データー・ストリームを含み、各最適化データー・ストリームが複数のチャンクを有し、このチャンクが、少なくとも１つのデーター・チャンクと、最適化ストリーム・メタデーター（例えば、チャンク・ストア、グローバル・テーブル、データーベース等のチャンク・コンテナ内にストリーム・マップ・チャンクとして格納されるストリーム・マップ）とを含む。最適化ストリーム・メタデーターは、データー・チャンクの識別子を、チャンク・ストアにおけるデーター・チャンクの位置にマッピングする。チャンク・ストアは、重複排除した様式としたデーター・チャンクを含む。チャンク・ストアに格納されている最適化データー・ストリームの１つ以上を、バックアップのために特定することができる。特定した最適化データー・ストリームをバックアップするために、チャンク・ストアの少なくとも一部をバックアップ・ストレージに格納する。選択したバックアップ技法にしたがって、チャンク・ストア（その一部、またはその全体）をバックアップ・ストレージに格納する。

【0007】

[0007] 例えば、ある最適化バックアップ技法によれば、チャンク・ストアの１つ以上のチャンク・コンテナを、バックアップ・ストレージに全て格納する。複数の最適化ストリーム構造をバックアップ・ストレージに格納する。最適化ストリーム構造は、バックアップのために特定された最適データー・ストリームに対するリパース・ポイント(reparse point)となる。

【0008】

[0008] 無最適化バックアップ技法(un-optimized backup technique)によれば、バックアップのために特定された各最適化データー・ストリームを、対応する無最適化データー・ストリームにリハイドレートする(rehydrate)。無最適化データー・ストリームは、最適化データー・ストリームのメタデーターによって参照されているいずれのデーター・チャンクも含む。各無最適化データー・ストリームをバックアップ・ストレージに格納する。

【0009】

[0009] 項目レベル・バックアップ技法によれば、バックアップのために第１最適化データー・ストリームを特定する。第１最適化データー・ストリームのメタデーターによって参照されている１つ以上のデーター・チャンクの内、未だバックアップ・ストレージに格納されていないものを判定する。第１最適化データー・ストリームの最適化ストリーム・メタデーターをバックアップ・ストレージに格納する。未だバックアップされていないと判定されたデーター・チャンクも、バックアップ・ストレージに格納する。バックアップのために特定された各最適化データー・ストリームも、同様にしてバックアップ・ストレージに格納することができる。
[0010] データー・チャンク識別子バックアップ技法によれば、各最適化データー・ストリームの最適化ストリーム・メタデーターを分析し、最適化ストリーム・メタデーターによって参照されているデーター・チャンクに対してデーター・チャンク識別子を決定する。最適化データー・ストリーム毎の最適化ストリーム構造を、対応する少なくとも１つのデーター・チャンク識別子と共に、バックアップ・ストレージに格納する。チャンク・ストアの内、参照されているデーター・チャンクを格納する１つ以上のチャンク・コンテナも、バックアップ・ストレージに格納する。

【0010】

[0011] バックアップ技法は、発見法に基づくことができる。選択されたバックアップ技法は、複数の最適化データー・ストリームをバックアップ・ストレージにバックアップするために実行される。

【0011】

[0012] また、バックアップ・ストレージからの最適化データー・ストリームの復元のための実施態様についても記載する。バックアップ・ストレージにおけるチャンク・ストアから最適化データー・ストリームを引き出す要求を受ける。この要求は、データー・ストリームに対応する最適化ストリーム・メタデーターの識別子を含む。最適化ストリーム・メタデーターの識別子に基づいて、復元アプリケーションへの第１のコールを生成する。この第１のコールは、バックアップ・ストレージにおいて、最適化ストリーム・メタデーター識別子によって特定された最適化ストリーム・メタデーターを格納しているストリーム・コンテナのファイル名称を指定し、更にストリーム・コンテナにおける最適化ストリーム・メタデーターに対するオフセットを指定する。第１のコールに応答して、最適化ストリーム・メタデーターを受け取る。最適化ストリーム・メタデーターにおいて参照されている少なくとも１つのデーター・チャンク識別子を特定する。バックアップ・ストレージにおける少なくとも１つのチャンク・コンテナから少なくとも１つのデーター・チャンクを得るために、最適化ストリーム・メタデーターによって参照されているデーター・チャンク識別子（１つまたは複数）に対応して、復元アプリケーションに対する少なくとも１つの追加のコールを生成する。この追加のコール（１つまたは複数）に応答して、データー・チャンク（１つまたは複数）を受け取る。データー・チャンク（１つまたは複数）は、データー・ストリームを復元するために組み合わせ可能である。

【0012】

[0013] 一実施態様では、最適化ストリーム・メタデーターによって参照されているデーター・チャンク識別子は、第１ソート・キーとしてのチャンク・コンテナおよび第２キーとしてのチャンク・オフセットに基づいてソートすることができる。データー・チャンクを引き出すための復元アプリケーションに対するコールは、このソート処理によって定められる順序で生成することができる。

【0013】

[0014] 一実施態様では、復元エンジンが、復元計画(restore plan)を用いて、復元アプリケーションをコールすることができる。復元計画は、データー・チャンクを収容するバックアップ・ファイルをソートすることによって復元の順序を決定する要求を含むことができ、または復元アプリケーションがキャッシュ処理および先読み動作を実行することによって最適化できるように、どのファイル範囲を復元しようとしているのか、復元アプリケーションに知らせる要求を含むことができる。

【0014】

[0015] 最適化データー・ストリームのバックアップおよび／または復元システムの実施態様について記載する。一実施態様では、データー・バックアップ・モジュールが、チャンク・ストアに格納されている複数の最適化データー・ストリームの内バックアップしようとするものの識別を受け取る。データー・バックアップ・モジュールは、複数の最適化データー・ストリームをバックアップするために、チャンク・ストアの少なくとも一部をバックアップ・ストレージに格納するように構成されている。

【0015】

[0016] 実施態様では、データー・バックアップ・モジュールは最適化ファイル・バックアップ・モジュール、リハイドレーション・バックアップ・モジュール、項目レベル・バックアップ・モジュール、および／またはデーター・チャンク識別子バックアップ・モジュールの内１つ以上を含むことができる。最適化ファイル・バックアップ・モジュールは、チャンク・ストア全体をバックアップ・ストレージに格納し、更に最適化データー構造を最適化データー・ストリームのリパース・ポイントとして格納するように構成されている。リハイドレーション・バックアップ・モジュールは、各最適化データー・ストリームをリハイドレートし、最適化ストリーム・メタデーターによって参照されているいずれのデーター・チャンクも含む、対応する無最適化データー・ストリームを得るように構成されている。リハイドレーション・バックアップ・モジュールは、各無最適化データー・ストリームをバックアップ・ストレージに格納する。項目レベル・バックアップ・モジュールは、最適化データー・ストリーム毎に、未だバックアップ・ストレージに格納されていない最適化データー・ストリームの最適化ストリーム・メタデーターのメタデーターによって参照されている１つ以上のデーター・チャンクを判定するように構成されている。項目レベル・バックアップ・モジュールは、最適化データー・ストリームの最適化ストリーム・メタデーターをバックアップ・ストレージに格納し、重複でないと判定された１つ以上のデーター・チャンクをバックアップ・ストレージに格納する。データー・チャンク識別子バックアップ・モジュールは、各最適化データー・ストリームの最適化ストリーム・メタデーターを分析して、最適化ストリーム・メタデーターによって参照されているデーター・チャンク（１つまたは複数）に対して少なくとも１つのデーター・チャンク識別子を判定するように構成されている。データー・チャンク識別子バックアップ・モジュールは、各最適化データー・ストリームを、対応するデーター・チャンク識別子（１つまたは複数）と共に、バックアップ・ストレージに格納し、チャンク・ストアの１つ以上のチャンク・コンテナをバックアップ・ストレージに格納する。

【0016】

[0017] 一実施形態では、データー・バックアップ・モジュールは、発見法モジュールを含むことができる。発見法モジュールは、バックアップしようとするデーター・ストリームのサイズ、重複解除した後におけるデーター・ストリームのサイズ（冗長なデーター・チャンクを除去するため）、チャンク・ストアの全体的サイズ、およびこれらの量に基づいて生成することができる発見法というような発見法を含む、発見法に基づいて、バックアップ技法を選択するように構成されている。発見法モジュールは、複数の最適化データー・ストリームをバックアップ・ストレージにバックアップするために、バックアップ技法を実行することを可能にする。

【0017】

[0018] 他の実施態様では、データー復元モジュールは、最適化データー・ストリームをバックアップ・ストレージから復元するように構成されている。データー復元モジュールは、ファイル・リコンストラクターを含む。ファイル・リコンストラクターは、データー・ストリームをバックアップ・ストレージにおけるチャンク・ストアから引き出す要求を受け取る。この要求は、データー・ストリームに対応する最適化ストリーム・メタデーターの識別子を含む。ファイル・リコンストラクターは、コールバック・モジュール（例えば、バックアップ／復元システムによって設けられる）を含む。コールバック・モジュールは、最適化ストリーム・メタデーターの識別子に基づいて、復元アプリケーションに対する第１のコールを生成する。第１のコールは、バックアップ・ストレージにおいて、最適化ストリーム・メタデーター識別子によって特定された最適化ストリーム・メタデーターを格納する第１チャンク・コンテナにファイル名称を指定し、更に第１チャンク・コンテナにおける最適ストリーム・メタデーターに対するオフセットを指定する。ファイル・リコンストラクターは、第１のコールに応答して、最適化ストリーム・メタデーターを受け取り、この最適化ストリーム・メタデーターにおいて参照されている少なくとも１つのデーター・チャンク識別子を判定する。コールバック・モジュールは、バックアップ・ストレージにおける１つ以上のチャンク・コンテナから１つ以上のデーター・チャンクを得るために、データー・チャンク識別子（１つ以上）に対応して、復元アプリケーションに少なくとも１つの追加のコールを生成する。ファイル・リコンストラクターは、追加のコール（１つまたは複数）に応答してデーター・チャンク（１つまたは複数）を受け取り、データー・ストリームを復元するためにデーター・チャンク（１つまたは複数）を組み合わせることができる。あるいは、ファイル・リコンストラクターは、最適化ストリーム・メタデーターおよびデーター・チャンク（１つまたは複数）をチャンク・ストアに格納してもよく、データー・ストリームに対する最適化ストリーム構造は、チャンク・ストアに格納されているチャンクを参照するストレージに格納するのでもよい。

【0018】

[0019] また、コールバック・モジュールは、復元計画を用いて、復元アプリケーションをコールすることもできる。復元計画は、データー・チャンク・コンテナ・ファイル・リストをソートすることによって復元の順序を決定する要求を含むことができ、または復元アプリケーションがキャッシュ処理および先読み動作を実行することによって最適化できるように、どのファイル範囲をコンテナ・ファイルから復元しようとしているのか、復元アプリケーションに知らせる要求を含むことができる。

【0019】

[0020] また、本明細書では、最適化データー・ストリームをバックアップ・ストレージに格納するため、最適化データー・ストリームをバックアップ・ストレージから復元するため、および本明細書において記載する他の実施形態のためのコンピューター・プログラム生産物についても記載する。

【0020】

[0021] 本発明の更に他の特徴および利点、ならびに本発明の種々の実施形態の構造および動作について、添付図面を参照しながら以下で詳しく説明する。尚、本発明は、本明細書において記載する具体的な実施形態に限定されないことを注記しておく。このような実施形態は、本明細書では、例示の目的に限って紹介されるに過ぎない。本明細書に含まれる教示に基づけば、追加の実施形態も、関連技術（１つまたは複数）の当業者には明白であろう。

【0021】

[0022] 添付図面は、本明細書に組み込まれその一部を形成するが、本発明を例示し、本記載と共に、本発明の原理を説明し、当業者が本発明を行い使用することを可能にする役割を果たす。

【図面の簡単な説明】

【0022】

【図1】図１は、一実施形態例によるデーター重複排除システムのブロック図を示す。

【図2】図２は、一実施形態例によるチャック・ストアのブロック図を示す。

【図3】図３は、一実施形態例によるチャンク・ストアのブロック図を示す。

【図4】図４は、一実施形態例によるデーター・ストリーム・ストア・システムのブロック図を示す。

【図5】図５は、一実施形態例によるデーター・ストリームを格納するフローチャートを示す。

【図6】図６は、一実施形態によるデーター・ストナ内へのデーター・ストリームの格納の一例を表すブロック図を示す。

【図7】図７は、一実施形態例による、リハイドレーション(rehydration)モジュールを含むチャンク・ストア・インターフェースのブロック図を示す。

【図8】図８は、一実施形態例によるチャンク・コンテナのブロック図を示す。

【図9】図９は、一実施形態例によるリダイレクション・テーブルのブロック図を示す。

【図10】図１０は、一実施形態例にしたがって、データー・ストリームを格納するフローチャートを示す。

【図11】図１１は、一実施形態例にしたがって、データー・ストリームをリハイドレートするためにチャンク・ストアにアクセスするリハイドレーション・モジュールのブロック図を示す。

【図12】図１２は、一実施形態例にしたがって、データー最適化システムにおいてデーターのバックアップを実行するフローチャートを示す。

【図13】図１３は、一実施形態例によるデーター・バックアップ・システムのブロック図を示す。

【図14】図１４は、実施形態例による最適化データー・ストリームに対して種々のバックアップ技法を実行するフローチャートを示す。

【図15】図１５は、実施形態例による最適化データー・ストリームに対して種々のバックアップ技法を実行するフローチャートを示す。

【図16】図１６は、実施形態例による最適化データー・ストリームに対して種々のバックアップ技法を実行するフローチャートを示す。

【図17】図１７は、実施形態例による最適化データー・ストリームに対して種々のバックアップ技法を実行するフローチャートを示す。

【図18】図１８は、一実施形態例にしたがって、発見法に基づいてバックアップ技法を選択し実行するプロセスを表すフローチャートを示す。

【図19】図１９は、一実施形態例にしたがって、データー最適化システムにおいてバックアップ・データーの復元を実行するフローチャートを示す。

【図20】図２０は、一実施形態例によるデーター復元システムのブロック図を示す。

【図21】図２１は、一実施形態にしたがって、再分配（redistribution)テーブルにアクセスするコールバック・モジュールのブロック図を示す。

【図22】図２２は、一実施形態例にしたがって、チャンクの更新オフセットを得るために再分配テーブルにアクセスするプロセスを表すフローチャートを示す。

【図23】図２３は、一実施形態例によるファイル・リコンストラクターのブロック図を示す。

【図24】図２４は、一実施形態例にしたがってデーター・チャンクを格納するプロセスを表すフローチャートを示す。

【図25】図２５は、本発明の実施形態を実現するために用いることができるコンピューター例のブロック図を示す。

【0023】

[0045] 本発明の特徴および利点は、以下に明記する詳細な説明を添付図面と合わせて検討することによって一層明らかとなろう。図面においては、同様の参照符合は全体を通じて対応する要素を特定する。図面において、同様の参照番号は、総じて、同一の要素、機能的に同様な要素、および／または構造的に同様な要素を示す。最初に要素が現れる図面は、対応する参照番号において一番左側の桁（１つまたは複数）によって示されている。

【発明を実施するための形態】

【0024】

Ｉ．序説
[0046] 本明細書は、本発明の特徴を組み込んだ１つ以上の実施形態を開示する。開示する実施形態（１つまたは複数）は、単に本発明を例示するに過ぎない。本発明の範囲は、開示する実施形態（１つまたは複数）に限定されるのではない。本発明は、本明細書に添付する特許請求の範囲によって定められるものとする。

【0025】

[0047] 本明細書において「一実施形態」、「実施形態」、「実施形態例」等に言及するときは、その記載される実施形態が特定の特徴、構造、または特性を含むことができるが、あらゆる実施形態がその特定の特徴、構造、または特性を必ずしも含まなくてもよいことを示す。更に、このような句は、必ずしも同じ実施形態に言及するとは限らない。更に、特定の特徴、構造、または特性をある実施形態と関連付けて説明するとき、明示的に記載されているか否かを問わず、このような特徴、構造、または特性を他の実施形態と関連付けて実施することは、当業者の知識の範囲内のことであることを具申する。

【0026】

[0048] 本明細書における最適化データーとは、チャンクの単一インスタンス化および圧縮というようなデーター重複排除技法の内１つ以上によって最適化、即ち、重複排除されているデーターを指す。最適化ストリームとは、重複排除されたストリーム、言い換えると、データー重複排除技法を用いて最適化されたそのデーターを指す。
ＩＩ．実施形態例
[0049] 実施形態は、データー重複排除のための技法を示す。このような実施形態は、データー量（例えば、バイト数）を格納すること、送信すること、またはデーターの忠実性や完全性を損なうことなく削減することを可能にする。たとえば、実施形態は、最適化データーにアクセスする際にレイテンシー量の低減を可能にする。更に、実施形態は、計算機械／デバイスのようなリソースを一層効率的に使用し、リソースの消費を低減することができる。その上更に、実施形態は、データー重複排除、重複排除データーのバックアップ、およびストレージからのバックアップ・データーの復元のための技術も提供し、これらは、格納するディジタル・データー量の増大に合わせて拡大可能(scalable)である。

【0027】

[0050] 例えば、一実施形態では、データー重複排除のために、スケーラブルなチャンク・ストアを提供する。このチャンク・ストアは、最適化データーのアクセスにおいてレイテンシーを最小限に抑え、機械のリソース消費（例えば、メモリーおよびディスクＩ／Ｏ）を削減し、ならびにデーター重複排除、データーのバックアップ、およびデーターの復元の間における信頼性を高める種々の技法を可能にする。以下の副章において実施形態例について更に詳しく説明する。

【0028】

Ａ．データー重複排除の実施形態例
[0051] 実施形態では、格納しようとするデーターを最適化して、そのデーターに必要な記憶量を削減することができる。例えば、データー・ストリームを一意のデーター・チャンクの形態で格納することができる。データー・チャンクは、データー・ストリームを定める最適化データー・メタデーターによって参照することができる。このように、同じデーター・チャンクを多数回格納するのではなく、多数のデーター・ストリームのメタデーターが、格納されている同じデーター・チャンクを参照すればよいので、データー・ストリームが一層効率的に格納されることになる。更に、所望に応じてストレージから最適化データーを要求することもできる（例えば、アプリケーションによって）。このような場合、データー・ストリームは、対応するメタデーターにしたがって、格納されているデーター・チャンクから組み立て直すことができる。

【0029】

[0052] 例えば、図１は、一実施形態例によるデーター重複排除システム１００のブロック図を示す。図１に示すように、システム１００は、記憶システム１０２、データー重複排除モジュール１０４、維持モジュール１０６、およびストレージ１０８を含む。更に、記憶システム１０２は、データー・ストリームＡＰＩ（アプリケーション・プログラミング・インターフェース）１１０、チャンク維持ＡＰＩ１１２、およびデーター・アクセスＡＰＩ１１４を含む。システム１００について、最適化データーの格納、およびストレージからの最適化データーの復元を例示するために、以下のように説明するが、これは限定することを意図するのではない。

【0030】

[0053] システム１００は、効率的にデーターをストレージ１０８に格納することを可能にするように、そしてストレージ１０８からデーターを引き出すことを可能にするように構成されている。例えば、一実施形態では、データー重複排除モジュール１０４があるとよい。データー重複排除モジュール１０４は、受信データーを格納に最適化するように構成されている。例えば、データー重複排除モジュール１０４は、データー・ストリーム１３２として受信した受信データーを圧縮することができる。データー・ストリーム１３２は、データー・ファイルの一部、１つのデーター・ファイル、多数のデーター・ファイル、および／またはファイルおよび／またはファイル部分のあらゆる組み合わせを含むことができる。図１に示すように、データー重複排除モジュール１０４は、データー・チャンク１２４を生成する。データー・チャンク１２４は、データー・ストリームを圧縮および区分したバージョンとすることができる。

【0031】

[0054] データー・ストリームＡＰＩ１１０は、記憶システム１０２がデーター・チャンク１２４を受け取るためのインターフェースを設ける。データー・チャンク１２４は、このデーター・チャンク１２４が生成された元であるデーター・ストリーム１３２を形成する複数のデーター・チャンクを含むことができる。データー・ストリームＡＰＩ１１０は、関連技術（１つまたは複数）の当業者には周知である、適したやり方であればいずれでも構成することができる。データー・ストリームＡＰＩ１１０は、チャンク・ストア・インターフェース１１６によって受け取られるデーター・チャンク１２４を出力することができる。

【0032】

[0055] 図１に示すように、ストレージ１０８は記憶システム１０２に結合されている。チャンク・ストア・インターフェース１１６は、ＡＰＩ１１０、１１２、および１１４とストレージ１０８との間のインターフェースである。例えば、チャンク・ストア・インターフェース１１６は、データー・チャンク１２４を受け取ることができ、データー・チャンク１２４のデーター・チャンクをストレージ１０８に格納することができる。例えば、図１に示すように、ストレージ１０８はチャンク・ストア１１８を含む。チャンク・ストア・インターフェース１１６は、受け取ったデーター・チャンク１２４のデーター・チャンクをチャンク・ストア１１８に、データー・チャンク１２８として格納することができる。

【0033】

[0056] データー・アクセスＡＰＩ１１４は、アプリケーションが記憶システム１０２のデーターを要求するためのインターフェースを設ける。例えば、図１に示すように、データー・アクセスＡＰＩ１１４は、データー・ストリーム要求１２０を受ける。データー・アクセスＡＰＩ１１４は、関連技術（１つまたは複数）における当業者には周知である、適したやり方であればいずれでも構成することができる。データー・アクセスＡＰＩ１１４は、チャンク・ストア・インターフェース１１６が受けたデーター・ストリーム要求１２０を出力することができる。チャンク・ストア・インターフェース１１６は、データー・チャンクを、データー・ストリーム要求１２０の要求されたデーター・ストリームに対応するストレージ１０８に（例えば、チャンク・ストア１１８に）要求することができる。チャンク・ストア・インターフェース１１６は、要求されたデーター・チャンクをストレージ１０８から、データー・チャンク１３０として受け取ることができ、データー・チャンク１３０を含むデーター・ストリームをデーター・アクセスＡＰＩ１１４に供給することができる。データー・アクセスＡＰＩ１１４は、このデーター・ストリーム（例えば、１つのファイルまたは組み立て直されたファイル）を要求元のアプリケーションに、データー・ストリーム応答１２２として供給することができる。

【0034】

[0057] 更に、維持モジュール１０６は、チャンク・ストア１１８に格納されているデーター・チャンクに関する１つ以上の維持作業を実行するためにあるとよい。例えば、維持モジュール１０６は、ストレージ１０８に格納されているデーター・チャンクの断片化解消を実行するために、断片化解消モジュールを含むことができる。例えば、断片化解消モジュールは、ストレージ１０８における空き空間を排除する（例えば、コンパクション(compaction)を実行する）、関連データー・チャンクを纏めてシーケンスにする、および／または他の関連タスクを実行するように構成することができる。他の例では、維持モジュール１０６は、ストレージ１０８に格納されているデーター／チャンクのガベージ・コレクションを実行するために、ガベージ・コレクション・モジュールを含むこともできる。例えば、ガベージ・コレクション・モジュールは、ストレージ１０８における使用されていないデーター・チャンクを削除するように構成することができる。更に他の実施形態では、維持モジュール１０６は、ストレージ１０８に関して追加のまたは代わりの維持タスクを実行することもできる。

【0035】

[0058] 図１に示すように、チャンク維持ＡＰＩ１１２は、維持モジュール１０６が記憶システム１０２と相互作用するためのインターフェースを設ける。維持モジュール１０６は、維持タスク１２６（例えば、断片化解消命令、コンパクション命令、データー・チャンク削除命令等）を生成することができる。維持タスク１２６は、チャンク維持ＡＰＩ１１２によって受けられる。チャンク維持ＡＰＩ１１２は、関連技術（１つまたは複数）の当業者には周知である、適したやり方であればいずれでも構成することができる。チャンク維持ＡＰＩ１１２は、は、維持タスク１２６をチャンク・ストア・インターフェース１１６に付与することができる。チャンク・ストア・インターフェース１１６は、ストレージ１０８に格納されているデーター・チャンクに対して維持タスク１２６を実行することを可能にすることができる。

【0036】

[0059] 記憶システム１０２は、１つ以上のコンピューター／計算デバイスの形態を含む、適した形態であればいずれにでも実現することができる。ストレージ１０８は、磁気ディスク（例えば、ハード・ディスク・ドライブにおける）、光ディスク（例えば、光ディスク・ドライブにおける）、磁気テープ（例えば、テープ・ドライブにおける）、および／または他のあらゆる適したタイプの記憶媒体を含む、あらゆるタイプのメカニズムの内１つ以上を含むことができる。

【0037】

[0060] 尚、データー重複排除システム１００は、本発明の実施形態を実現することができる環境の一例であることを注記しておく。データー重複排除紙アステム１００は、例示の目的に限って提示するのであって、限定することを意図するのではない。実施形態は、データー重複排除システムの更に他のタイプおよび構成にも組み込むこともできる。

【0038】

Ｂ．データー・チャンク局在性(locality)を可能にするチャンク・ストアの実施形態例
[0061] 図１のチャンク・ストア１１８は、データー・チャンクの形態でデーター・ストリームをいずれのやり方でも格納することができる。例えば、チャンク・ストア１１８は、データー・ストリームに含まれるデーター・チャンクを示す最適化ストリーム・メタデーターを、マップ、データーベース、または他の形態で格納することができる。チャンク・ストア１１８は、更に、参照されているデーター・チャンクも格納することができる。一実施形態では、チャンク・ストア１１８は、データー重複排除技法にしたがって、データー・チャンクの重複コピーを格納しない。

【0039】

[0062] 例えば、図２は、一実施形態例による、チャンク・ストア１１８のブロック図を示す。図２に示すように、チャンク・ストア１１８は、ストリーム・コンテナ２０２とチャンク・コンテナ２０４とを含む。ストリーム・コンテナ２０２は、１つ以上のデーター・ストリームについての最適化ストリーム・メタデーター２０６を含み、チャンク・コンテナ２０４は、複数のデーター・チャンク２０８を含む。データー・チャンク２０８は、１つ以上のデーター・ストリーム（例えば、図１のデーター・ストリーム１３２）によって参照されているデーターのセグメントである。最適化ストリーム・メタデーター２０６は、元のデーター・ストリーム構造と最適化データー・チャンク構造との間におけるマッピングを記述するデーター構造である。最適化ストリーム・メタデーター２０６は、参照されているデーター・チャンクを突き止め、ファイル・ストリーム・ビューに組み立てることができるように、データー・チャンク位置情報を、直接収容するかまたは間接層を介して収容する。最適化ストリーム・メタデーター２０６は、実施形態では、種々の形態をなすことができ、ストリーム・マップ（各ストリーム・マップが、対応するデーター・ストリームについてのデーター・チャンク位置を示す）、データーベース、またはグローバル・テーブル（全てのデーター・ストリームに対してデーター・チャンク位置を示す）の形態、あるいは他の形態を有することを含む。図２の例では、データー・チャンク２０８および最適化ストリーム・メタデーター２０６は、それぞれ、ストリーム・コンテナ２０２およびチャンク・コンテナ２０４に格納されている。これらのコンテナは、ファイル・システムにおけるファイルであってよい。一実施形態では、チャンク・ストア１１８は、最適化ストリーム・メタデーター２０６が、ファイル・ストリーム−データー・チャンク２０８のマッピング、データー・チャンク・アドレス、およびハッシュを記述するための内部メタデーター（データー・ストリーム・メタデーター）を収容するデーター・チャンク（例えば、各ストリーム・マップをデーター・チャンクとして格納する）として格納されるように、全てのデーターをチャンクの形態で格納することができる。あるいは、最適化ストリーム・メタデーター２０６を他の形態（例えば、中央データーベースまたはテーブル等）で格納してもよい。

【0040】

[0063] ストリーム・コンテナ２０２およびチャンク・コンテナ２０４は、実施形態では、種々の方法で構成することができる。例えば、図３は、一実施形態例によるチャンク・ストア３００のブロック図を示す。チャンク・ストア３００は、図２のチャンク・ストア１１８の一例である。図３に示すように、チャンク・ストア３００は、ストレージ・コンテナ３０２とチャンク・コンテナ３０４とを含む。ストレージ・コンテナ３０２は、図２のストレージ・コンテナ２０２の一例であり、チャンク・コンテナ３０４は、図２のチャンク・コンテナ２０４の一例である。図３の実施形態では、ストレージ・コンテナ３０２は、ファイル・ヘッダー３０６、リダイレクション・テーブル３０８、および複数のストリーム・マップ３１０を含む。ストリーム・マップ３１０は、最適化ストリーム・メタデーター２０６の例であり、図示を容易にするために設けられている。例示の目的に限って、最適化ストリーム・メタデーター２０６は、ここではストリーム・マップに関して頻繁に記載されることがあるが、他の実施形態では、最適化ストリーム・メタデーター２０６を代わりにデーターベース、グローバル・テーブル等として格納してもよいことが理解されることを意図している。

【0041】

[0064] 図３には、例示の目的に限って、第１および第２ストリーム・マップ３１０ａおよび３１０ｂが示されているが、実施形態では、いずれの数のストリーム・マップ３１０でもストリーム・コンテナ３０２に含まれてもよく、数百、数千、そしてそれよりも更に多い数のストリーム・マップ３１０を含む。チャンク・コンテナ３０４は、ファイル・ヘッダー３１８、リダイレクション・テーブル３２０、および複数のデーター・チャンク３２２を含む。図３には、例示の目的に限って、第１および第２データー・チャンク３２２ａおよび３２２ｂが示されているが、実施形態では、いずれの数のデーター・チャンク３２２でもチャンク・コンテナ３０４に含まれてもよく、数百、数千、そしてそれよりも更に多い数のデーター・チャンク３２２を含む。図３のこれらの特徴について、以下のように説明する。

【0042】

[0065] ファイル・ヘッダー３０６は、ストリーム・コンテナ３０２がファイルとして格納される実施形態では、ストリーム・コンテナ３０２のファイル・ヘッダーとなる。ファイル・ヘッダー３０６は、ストリーム・コンテナ識別子（例えば、ストリーム・コンテナ識別番号）等を含む、ストリーム・コンテナ３０２と関連のある情報を含むことができる。

【0043】

[0066] リダイレクション・テーブル３０８がストリーム・コンテナ３０２内にあるのは任意である。ある場合、リダイレクション・テーブル３０８は、ストリーム・マップ３１０の内いずれのストリーム・コンテナ３０２における位置変化に関する情報も格納することができる。例えば、第１ストリーム・マップ３１０ａをストリーム・コンテナ３０２から削除することもあり、第２ストリーム・マップ３１０ｂを第１ストリーム・マップ３１０ａの位置に移動させることもある（例えば、断片化解消またはコンパクション・ルーチンのために）。この移動に続いて、アプリケーションがストリーム・コンテナ３０２にアクセスして、第２ストリーム・マップ３１０ｂを引き出すことができる。しかしながら、このアプリケーションは、第２ストリーム・マップ３１０ｂの以前の位置も引き続き使っている場合もある。リダイレクション・テーブル３０８は、第２ストリーム・マップ３１０ｂの現在の位置を示す第２ストリーム・マップ３１０ｂについてのマッピングを含むことができる。したがって、アプリケーションは、リダイレクション・テーブル３０８にアクセスして、第２ストリーム・マップ３１０ｂの現在の位置を判定することができ、これによってこの新たな位置から第２ストリーム・マップ３１０ｂを引き出すことを可能にすることができる。

【0044】

[0067] ストリーム・マップ３１０は、図２の最適化ストリーム・メタデーター２０６の例である。ストリーム・マップ３１０の各々は、特定のデーター・ストリームを構成するデーター・チャンク３３２のシーケンスを定めるために用いられる。図３に示すように、ストリーム・マップ３１０の各々は、ストリーム・ヘッダー３１２、メタデーター３１４、およびハッシュ値３１６を含むことができる。例えば、第１ストリーム・マップ３１０ａは、ストリーム・ヘッダー３１２ａ、メタデーター３１４ａ、およびハッシュ値３１６ａを含むことが示されており、第２ストリーム・マップ３１０ｂは、ストリーム・ヘッダー３１２ｂ、メタデーター３１４ｂ、およびハッシュ値３１６ｂを含むことが示されている。各ストリーム・ヘッダー３１２は、ストリーム・マップ識別子（例えば、ストリーム・マップ識別番号のような）等のような、対応するストリーム・マップ３１０に関連する情報を含む。各メタデーター３１４は、対応するストリーム・マップ３１０によって定められるデーター・ストリームを構成するデーター・チャンク３２２を記述する情報を含む。ハッシュ値３１６が存在するのは任意である。ハッシュ値３１６は、対応するストリーム・マップ３１０によって定められるデーター・ストリームを構成するデーター・チャンク３２２に対するハッシュ値である。ハッシュ値３１６は、対応するデーター・ストリームを構成するデーター・チャンクのハッシュ・ベクトルに効率的なアクセスを付与するために、ストリーム・マップ３１０に格納するとよい。例えば、これは、データー・ストリーム・ハッシュのリスト全体（全ての最適化ファイル・チャンクに対するハッシュ）に対する高速アクセスが望まれる、ワイヤ・データー転送の状況(wire data transfer scenario)には有用である場合がある。

【0045】

[0068] メタデーター３１４は、データー・チャンク毎のメタデーター、またはデーター・チャンク特定のメタデーターであり、参照されているデーター・チャンク３３２毎にストリーム・マップ３１０に含むことができる。種々のタイプの情報をメタデーター３１４に含ませることができる。例えば、一実施形態では、データー・チャンク３２２についてのメタデーター３１４は、データー・ストリーム・オフセット、データー・チャンク識別子、および位置関係インディケーター(locality indicator)の内１つ以上を含むことができる。データー・ストリーム・オフセットは、特定のストリーム・マップ３１０によって定められるデーター・ストリームにおける、関連するデーター・チャンク３２２の位置を示す（例えば、データー・ストリームの先頭から、または関連するデーター・チャンク３２２が始まるデーター・ストリームにおける他の基準点からのバイト数）。データー・チャンク識別子は、チャンクｉｄまたは「信頼性のあるチャンク・ロケータ」(reliable chunk locator)としても知られており、チャンク・コンテナ３０４における対応するデーター・チャンク３２２への参照またはポインタである。位置関係インディケーターは、チャンク・コンテナ３０４におけるチャンク挿入順序を表し、どのデーター・チャンク３２２を共通のストリーム・マップ３１０によって参照するとよいかという判断を行うことを可能にする。他の実施形態では、メタデーター３１４は、参照されているデーター・チャンク３２２毎に追加の情報および／または代わりの情報を含むこともできる。

【0046】

[0069] 図３のチャンク・コンテナ３０４を参照すると、ファイル・ヘッダー３１８は、チャンク・コンテナ３０４がファイルに格納される実施形態では、チャンク・コンテナ３０２に対するファイル・ヘッダーとなる。ファイル・ヘッダー３１８は、チャンク・コンテナ３０４に関連する情報を含むことができ、チャンク・コンテナ識別子（例えば、チャンク・コンテナ識別番号）、チャンク・コンテナ３０４の改訂回数(revision number)を示すチャンク・コンテナ生成インディケーター等を含む。

【0047】

[0070] リダイレクション・テーブル３２０がチャンク・コンテナ３０４内にあるのは任意である。ある場合、リダイレクション・テーブル３２０は、ストリーム・コンテナ３０２のリダイレクション・テーブル３０８がストリーム・マップ３１０の位置変化を扱うのと同様に、データー・チャンク３２２のいずれのチャンク・コンテナ３０４における位置変化に関する情報も格納することができる。

【0048】

[0071] データー・チャンク３２２は、図２のデーター・チャンク２０８の例である。図３に示すように、データー・チャンク３２２の各々は、チャンク・ヘッダー３２４とチャンク・データー３２６とを含む。例えば、第１データー・チャンク３２２ａはチャンク・ヘッダー３２４ａとチャンク・データー３２６ａとを含み、第２データー・チャンク３２２ｂは、チャンク・ヘッダー３２４ｂとチャンク・データー３２６ｂとを含む。各チャンク・ヘッダー３１２は、データー・チャンク識別子等のような、対応するデーター・チャンク３２２に関連する情報を含む。各チャンク・データー３２６は、対応するデーターを含む。このデーターは、圧縮形態または非圧縮形態であってもよい。

【0049】

[0072] ストリーム・マップ３１０およびデーター・チャンク３２２は、データー重複排除を可能にするために、それぞれ、ストリーム・コンテナ３０２およびチャンク・コンテナ３０４に格納される。例えば、図１のチャンク・ストア・インターフェース１１６は、データー・ストリーム１３２に関連するデーター・チャンク１２４を受け取り、図３のチャンク・ストア３００にこのデーター・チャンクを格納することができる。例えば、特定のデーター・ストリーム１３２について、チャンク・ストア・インターフェース１１６は、ストリーム・マップを生成することができ、このストリーム・マップを、ストリーム・コンテナ３０２に、チャンク・ストア・インターフェース１１６によってチャンク・コンテナ３０４に格納された１つ以上のデーター・チャンク３２２を参照するストリーム・マップ３１０として格納する。

【0050】

[0073] 例えば、図３は、一実施形態例による、ストリーム・マップ３１０によって参照されている数個のデーター・チャンク３３２を示す。図３に示すように、第１ストリーム・マップ３１０ａは、チャンク・コンテナ３０４内にある第１および第２データー・チャンク３２２ａおよび３２２ｂに対する参照を含むメタデーター３１４ａを含む。つまり、第１および第２データー・チャンク３２２ａおよび３２２ｂは、第１ストリーム・マップ３１０ａに関連するソース・データー・ストリームの中に含まれている。例えば、メタデーター３１４ａは、第１ストリーム・マップ３１０ａによって定められるソース・データー・ストリーム内における第１データー・チャンク３２２ａの位置を第１データー・チャンク３２２ａに対して示すデーター・ストリーム・オフセット４０２値と、チャンク・コンテナ３０４内における第１データー・チャンク３２２ａに対するデーター・チャンク識別子４０４（例えば、チャンク・ヘッダー３２４ａ内に格納されている第１データー・チャンク３２２ａに対するデーター・チャンク識別子）と、更に第１データー・チャンク３２２ａに対する位置関係インディケーター４０６とを含むことができる。更に、メタデーター３１４ａは、ソース・データー・ストリーム内における第２データー・チャンク３２２ｂの位置を第２データー・チャンク３２２ｂに対して示すデーター・ストリーム・オフセット４０２値と、チャンク・コンテナ３０４内における第２データー・チャンク３２２ｂに対するデーター・チャンク識別子（例えば、チャンク・ヘッダー３２４ｂ内に格納されている第２データー・チャンク３２２ｂに対するデーター・チャンク識別子）と、更に第２データー・チャンク３２２ｂに対する位置関係インディケーター４０６とを含むことができる。一実施形態では、第１および第２データー・チャンク３２２ａおよび３２２ｂは、これらの位置関係インディケーターに同じ値を有することもあり、この値は、第１ストリーム・マップ３１０ａによって定められるソース・データー・ストリームに対応するように生成され、第１および第２データー・チャンク３２２ａおよび３２２ｂが連続的に（隣接して）チャンク・コンテナ３０４に格納されていることを示す。

【0051】

[0074] 更に、第２ストリーム・マップ３１０ｂは、チャンク・コンテナ３０４内にある第２データー・チャンク３２２ｂに対する参照を含むメタデーター３１４ｂを含む。例えば、メタデーター３１４ｂは、第２ストリーム・マップ３１０ｂによって定められるソース・データー・ストリーム内における第２データー・チャンク３２２ｂの位置を第２データー・チャンク３２２ｂに対して示すデーター・ストリーム・オフセット４０２値と、チャンク・コンテナ３０４内における第２データー・チャンク３２２ｂに対するデーター・チャンク識別子４０４（例えば、チャンク・ヘッダー３２４ｂ内に格納されている第２データー・チャンク３２２ｂに対するデーター・チャンク識別子）と、第２データー・チャンク３２２ｂに対する位置関係インディケーター４０６とを含むことができる。第２データー・チャンク３２２ｂについてのメタデーター３１４ｂにおける位置関係インディケーター４０６は、第１および第２データー・チャンク３２２ａおよび３２２ｂに対して生成された位置関係インディケーターと同じ値を有する。何故なら、第２データー・チャンク３２２ｂは、本来第１ストリーム・マップ３１０ａのためにチャンク・コンテナ３０４に格納されたからである。第２ストリーム・マップ３１０ｂによって定められるソース・データー・ストリームがチャンク・ストア３００に格納されたときに、他のデーター・チャンク３２２（図３には示されていない）がチャンク・コンテナ３０４に新たに格納された場合、そのいずれにも、位置関係インディケーター４０６に対して新たな値が割り当てられる。

【0052】

[0075] 図１のチャンク・ストア・インターフェース１１６は、図３のチャンク・ストア３００内にデーター・ストリームを格納するために、種々の方法で構成することができる。例えば、図４は、一実施形態例によるデーター・ストリーム・ストア・システムのブロック図を示す。図４に示すように、データー・ストリーム・ストア・システム４００は、データー・ストリーム・パーサー４０２、チャンク・ストア・インターフェース１１６、ストリーム・コンテナ３０２、およびチャンク・コンテナ３０４を含む。一実施形態では、データー・ストリーム・パーサー４０２は、図１のデーター重複排除モジュール１０４に含まれてもよい。図４の実施形態では、チャンク・ストア・インターフェース１１６は、データー・チャンク記憶マネージャー４０４、メタデーター生成器４０６、およびストリーム・マップ生成器４０８を含む。図４のこれらの特徴について、図５に関して次のように説明する。図５は、一実施形態例にしたがって、データー・ストリームを格納するフローチャート５００を示す。一実施形態では、図４のシステム４００は、フローチャート５００にしたがって動作することができる。フローチャート５００に関する論述に基づけば、関連技術（１つまたは複数）の当業者には、更に他の構造および動作的実施形態も明白であろう。フローチャート５００およびシステム４００について、以下のように説明する。

【0053】

[0076] フローチャート５００は、ステップ５０２から開始する。ステップ５０２において、データー・ストリームを解析してデーター・チャンクを求める。例えば、図４に示すように、データー・ストリーム・パーサー４０２は、データー・ストリーム４１０を受け取ることができる。データー・ストリーム４１０は、図１のデーター・ストリーム１３２と同様に、１つ以上のファイルおよび／またはファイルの一部を含むことができる。データー・ストリーム・パーサー４０２は、データー・ストリーム４１０を解析して、データー・チャンク・シーケンス４１２として示す、データー・チャンクのシーケンスを求める。例えば、一実施形態では、データー・チャンク・シーケンス４１２は、データー・チャンクがデーター・ストリーム４１０において位置する順序で、これらのデーター・チャンクのシーケンスを含むことができる。データー・チャンク・シーケンス４１２のデーター・チャンクは、同じサイズを有することができ、または異なるサイズを有することもできる。

【0054】

[0077] ステップ５０４において、これらのデーター・チャンクのいずれかが、チャンク・コンテナに格納されているデーター・チャンクの複製であるか否か判断する。例えば、図４に示すように、データー・チャンク記憶マネージャー４０４は、データー・チャンク・シーケンス４１２を受け取る。データー・チャンク記憶マネージャー４０４は、データー・チャンク・シーケンス４１２のデーター・チャンクのいずれかが既にチャンク・コンテナ３０４に格納されており、したがって複製であるか否か判断するように構成されている。例えば、一実施形態では、図４に示すように、データー・チャンク記憶マネージャー４０４は、データー・チャンク情報４２６をチャンク・コンテナ３０４から受け取ることができる。データー・チャンク情報４２６は、チャンク・コンテナ３０４に格納されているデーター・チャンク毎にハッシュ値を含むことができる。他の実施形態では、データー・チャンク記憶マネージャー４０４は、ストリーム・コンテナ３０２からハッシュ値３１６（図３）を受け取ることができる。これらのハッシュ値３１６は、チャンク・コンテナ３０４に格納されているデーター・チャンク３２２に対するハッシュ値である。データー・チャンク記憶マネージャー４０４は、データー・チャンク・シーケンス４１２のデーター・チャンク毎にハッシュ値を生成することができ、生成したハッシュ値を、データー・チャンク情報４２６において受け取ったハッシュ値（またはストリーム・コンテナ３０２からの）と比較して、データー・チャンク・シーケンス４１２のどのデーター・チャンクが既にチャンク・コンテナ３０４に格納されているか判断することができる。更に他の実施形態では、データー・チャンク記憶マネージャー４０４は、データー・チャンク・シーケンス４１２のどのデーター・チャンクが既にチャンク・コンテナ３０４に格納されているのか、関連技術（１つまたは複数）の当業者には周知である他の方法で判断することができる。

【0055】

[0078] 図４に示すように、データー・チャンク記憶マネージャー４０４は、格納チャンク指示４１６を生成する。格納チャンク指示４１６は、データー・チャンク・シーケンス４１２のどのデーター・チャンクが既にチャンク・コンテナ３０４に格納されているのか指示する。

【0056】

[0079] 再度図５を参照すると、ステップ５０６において、複製ではないと判断されたデーター・チャンクを、連続配置で、そしてデーター・ストリームにおけると同じシーケンスで、チャンク・コンテナに格納する。例えば、一実施形態では、データー・チャンク記憶マネージャー４０４は、データー・チャンク・シーケンスの内、チャンク・コンテナ３０４に格納されていると判断されなかったデーター・チャンクを格納するように構成されている。例えば、一実施形態では、データー・チャンク記憶マネージャー４０４は、新たなデーター・チャンク毎にチャンク・ヘッダー３２４（例えば、データー・チャンク識別子）を生成し、新たな各データー・チャンクを、データー・チャンク３２２として、チャンク・ヘッダー３２４およびチャンク・データー３２６と共に格納することができる。更に、一実施形態では、データー・チャンク記憶マネージャー４０４は、新たなデーター・チャンクを連続配置で、ソース・データー・ストリームにおけるのと同じ順序で（例えば、データー・チャンク・シーケンス４１２において受け取った順序で）チャンク・コンテナ３０４に格納するように構成されている。

【0057】

[0080] ステップ５０８において、複製でないと判断されたデーター・チャンクの各々について、メタデーターを生成する。このデーター・チャンクについてのメタデーターは、データー・ストリーム・オフセット、チャンク・コンテナにおける位置へのポインタ、および位置関係インディケーターを含む。例えば、図４に示すように、メタデーター生成器４０６は、データー・チャンク・シーケンス４１２および格納チャンク指示(stored chunk indication)４１６を受け取ることができる。一実施形態では、メタデーター生成器４０６はメタデーター(例えば、図３のメタデーター３１４）を生成するように構成することができる。メタデーター生成器４０６は、データー・チャンク・シーケンス４１２のデーター・チャンク毎にメタデーターを生成することができ、このメタデーターは、データー・ストリーム・オフセット４０２と、データー・チャンク識別子４０４と、位置関係インディケーター４０６とを含む。チャンク・コンテナ３０４に既に格納されていると判断されたデーター・チャンク（ステップ５０４において）に対して、データー・チャンク識別子４０４は、既に格納されているデーター・チャンクを指し示すように構成されている。ステップ５０８においてチャンク・コンテナ３０４に新たに格納されたデーター・チャンクに対して、データー・チャンク識別子４０４は、新たに格納されたデーター・チャンクを指し示すように構成されている。

【0058】

[0081] 再度図５を参照すると、ステップ５１０において、生成したメタデーターを含むデーター・ストリームについてのストリーム・マップを生成する。例えば、図４に示すように、ストリーム・マップ生成器４０８は、特定のデーター・ストリームに対してデーター・チャンク・シーケンス４１２において受け取ったデーター・チャンク毎にデーター・チャンク・メタデーター４２０を受け取る。ストリーム・マップ生成器４０８は、受け取ったデーター・チャンク毎のデーター・チャンク・メタデーター４２０を含むデーター・ストリームに関連するストリーム・マップ４２４を生成する。更に、ストリーム・マップ生成器４０８は、ストリーム・マップ４２４に対してストリーム・ヘッダー３１２を生成することができ、ストリーム・マップ４２４内に、受け取ったデーター・チャンク毎にハッシュ値３１６を含めることができる。

【0059】

[0082] ステップ５１２において、ストリーム・マップをストリーム・コンテナに格納する。例えば、図４に示すように、ストリーム・マップ生成器４０８はストリーム・マップ４２４をストリーム・コンテナ３０２に（例えば、ストリーム・マップ３１０として）格納する（または「存続させる」）ことができる。尚、代替実施形態では、データー・ストリームについてストリーム・マップを生成し格納する代わりに、データー・ストリームによって参照されるデーター・チャンクの位置を指し示す(pointing to)または示す(indicating)メタデーターを含むエントリを、データーベースまたはグローバル・テーブル内にデーター・ストリームに対して作成することもできる。

【0060】

[0083] 図６は、一実施形態にしたがってデーター・ストリームをデーター・ストアに格納する一例を表すブロック図を示す。図６は、例示の目的に限って提示されるのであり、限定することは意図していない。図６の例では、第１データー・ストリーム６０２ａをデーター・ストアに格納し、続いて、第２データー・ストリーム６０２ｂをデーター・ストアに格納する。ストリーム・リンク６０８ａ（「ストリーム・ポインタ」または「ストリーム・メタデーター・スタブ」としても知られている）が、第１データー・ストリーム６０２ａに対して示されており、ストリーム・リンク６０８ｂが第２データー・ストリーム６０２ｂに対して示されている。各ストリーム・リンク６０８は、データー・ストリーム６９２をチャンク・ストア内にある対応するデーター（例えば、ストリーム・マップ６０４または他の最適化ストリーム・メタデーター）にリンクし、データー・ストリーム６０２を組み立て直すことを可能にする。図６に示すように、第１データー・ストリーム６０２ａは、４つのデーター・チャンク６１４ａ〜６１４ｄを含む。前述のように、ストリーム・マップ６０４ａは、第１データー・ストリーム６０２ａについて生成するとよく、４つのデーター・チャンク６１４ａ〜６１４ｄをチャンク・コンテナ６０６に格納することができる。ストリーム・マップ６０４ａは、データー・チャンク６１４ａ〜６１４ｄの各々へのポインタ（図６では矢印で表されている）を含む。データー・チャンク６１４ａ〜６１４ｄは、全て新しくチャンク・コンテナ６０６に対して一意であるデーター・チャンクという１つの組に分類することができる。したがって、データー・チャンク６１４ａ〜６１４ｄは、連続配列で、データー・ストリーム６０２ａにおけると同じ順序でチャンク・コンテナ６０６に格納することができる。例えば、データー・チャンク６１４ａ〜６１４ｄは、チャンク・コンテナ６０６に格納される最初の４つのデーター・チャンクにすることができ、または１つ以上のデーター・チャンクが既にチャンク・コンテナ６０６に格納されている場合、データー・チャンク６１４ａ〜６１４ｄは、既に格納されているデーター・チャンクの直後に、チャンク・コンテナ６０６に格納することができる。データー・チャンク６１４ａ〜６１４ｄの各々には、ストリーム・マップ６０４ａにおける同じ位置関係インディケーターが割り当てられ、位置関係インディケーターの値は、第１データー・ストリーム６０２ａに対して選択されたものである。

【0061】

[0084] 第２データー・ストリーム６０２ａは、４つのデーター・チャンク６１４ｂ、６１４ｃ、６１４ｅ、および６１４ｆを含む。ストリーム・マップ６０４ｂは、第２データー・ストリーム６０２ｂについて生成することができる。データー・チャンク６１４ｂ、６１４ｃ、６１４ｅ、および６１４ｆは、フローチャート５００のステップ５０４にしたがって、２組のデーター・チャンクに分類することができる。第１組は、チャンク・コンテナ６０６に存在するコピーを既に有するチャンク６１４ｂおよび６１４ｃを含み（第１データー・ストリーム６０２ａのチャンク・シーケンスのため）、第２組は、新しく一意のデーター・チャンクである（チャンク・コンテナ６０６に既に格納されているコピーを有さない）、チャンク６１４ｅおよび６１４ｆを含む。データー・チャンク６１４ｂおよび６１４ｃは既にチャンク・コンテナ６０６に格納されているので、ストリーム・マップ６０４ｂは、チャンク・コンテナ６０６に既に格納されているデーター・チャンク６１４ｂおよび６１４ｃに対するポインタ（データー・チャンク識別子４０４に対する値）を含む。つまり、データー・チャンク６１４ｂおよび６１４ｃは、チャンク・コンテナ６０６内にある既存のデーター・チャンクへのポインタとして格納し、データー・チャンク６１４ｂおよび６１４ｃのチャンク・データーを格納しなくてよい。データー・チャンク６１４ｅおよび６１４ｆは未だチャンク・コンテナ６０６に格納されていないので、前述のように、データー・チャンク６１４ｅおよび６１４ｆをチャンク・コンテナ６０６に格納すればよい。例えば、データー・チャンク６１４ｅおよび６１４ｆはチャンク・コンテナ６０６にとって新しく一意のデーター・チャンクであるので、チャンク６１４ｅおよび６１４ｆは、チャンク・コンテナ６０６に現在格納されている最後の格納データー・チャンク（例えば、データー・チャンク６１４ｄ）の後ろに、連続配列で、データー・ストリーム６０２ｂにおけると同じ順序で格納すればよい。ストリーム・マップ６０４ｂは、第１から第４までのデーター・チャンク識別子６１２ａ〜６１２ｄを含み、これらは、それぞれ、チャンク・コンテナ６０６に格納されているデーター・チャンク６１４ｂ、６１４ｃ、６１４ｅ、および６１４ｆを指し示す。ストリーム・マップ６０４ｂでは、データー・チャンク６１４ｂおよび６１４ｃには、第１データー・ストリーム６０２ａに関連する位置関係インディケーター値が割り当てられ、データー・チャンク６１４ｅおよび６１４ｆには、第２データー・ストリーム６０２ｂに対して選択された位置関係インディケーター値が割り当てられる。

【0062】

[0085] 尚、データー・ストリーム６０２ａおよび６０２ｂに続いて、いかなる数の追加のデーター・ストリーム６０２でも同様に格納できることを注記しておく。更に、図６の例では、第２ストリーム・マップ６０４ｂのデーター・チャンクには、各々、２つの位置関係インディケーター値の内１つが割り当てられた。即ち、第２ストリーム・マップ６０４ｂに対して選択された新たな位置関係インディケーター値、または第１ストリーム・マップ６０４ａのデーター・チャンクに関連する位置関係インディケーター値のいずれかである。実施形態では、特定のストリーム・マップのデーター・チャンクには、チャンク・コンテナの中に既に存在するストリーム・マップのデーター・チャンクに関連する異なる位置関係インディケーターの数に応じて、いずれの数の位置関係インディケーター値からでも、その１つでも割り当てることができる。例えば、前述のように、チャンク・コンテナに対する新たなデーター・チャンクには、ストリーム・マップに関連する特定のデーター・ストリームに対して選択された新たな位置関係インディケーター値を割り当てることができる。更に、チャンク・コンテナ内に既に存在するストリーム・マップによって参照されるデーター・チャンクは、いずれの数でも、チャンク・コンテナに既に存在するデーター・チャンクの対応する位置関係インディケーター値が割り当てられる。これが意味するのは、データー・ストリームのデーター・チャンクの組は、１つ以上のいずれの数でも、データー・ストリームのデーター・チャンクに２つ、３つ、またはそれよりも更に多い異なる位置関係インディケーター値から選択された位置関係インディケーターを割り当てることができるように、対応する位置関係インディケーター値を割り当てることができるということである。

【0063】

[0086] したがって、ストリーム・マップ・メタデーターの位置関係インディケーターによって、データー・ストリーム内におけるデーター・チャンクの位置関係(locality)を確認することが可能になる。これは、重複データー・チャンクが集合単位で発生する傾向があるからである。新たなデーター・ストリームが既に知られているデーター・チャンク（チャンク・コンテナに既に格納されている）を収容しているとき、この新たなデーター・ストリーム内にある次のデーター・チャンクも複製データー・チャンク（チャンク・コンテナ内に既に格納されている）であることに妥当な確率がある。新たな元のデーター・チャンクは位置関係インディケーターにしたがって互いに隣接してチャンク・コンテナ内に格納されるので、この新たなデーター・ストリームが参照する、既に存在するデーター・チャンクもチャンク・コンテナ内において連続して格納されている可能性は一層高くなる。これは、チャンク・ストアから最適化データー・ストリームを読み出す性能(performance)を向上させるのに役立つ。例えば、対応するストリーム・マップおよびデーター・チャンクに基づいてデーター・ストリームを組み立て直すように構成されているリハイドレーション・モジュールは、先読みバッファーにおける次のデーター・チャンクの必要性を見出すことを予期して、チャンク・コンテナ内に格納されているデーター・チャンクに対して先読み(read ahead)を実行することができる。更に、断片化解消およびコンパクションというようなチャンク・ストア維持タスクは、既存の隣接するチャンクをチャンク・コンテナ内であちこち移動させるときにこれらを一緒に保持することによって、元の位置関係を維持しようとしつつ、そのタスクを実行することができる。

【0064】

[0087] 例えば、データー・ストリームを最適化しチャンク・ストア３００内にストリーム・マップ３１０およびデーター・チャンク３２２の形態で格納した後、これらのデーター・ストリームをチャンク・ストア３００から読み出すことができる。図７は、一実施形態による、リハイドレーション・モジュール７０２を含むチャンク・ストア・インターフェース１１６のブロック図を示す。リハイドレーション・モジュール７０２は、要求されたデーター・ストリーム（例えば、図１に示したデーター・ストリーム要求１２０にしたがって要求される）を組み立て直すように構成されている。例えば、データー・ストリーム要求１２０（図１）に応答してチャンク・ストア３００から読み出されるデーター・ストリームに対して、リハイドレーション・モジュール７０２は、チャンク・ストア３００から（例えば、リパース位置において）データー・ストリーム要求１２０の最適化ファイルによって参照されるストリーム・マップ３１０を決定して受け取る。例えば、リハイドレーション・モジュール７０２は、要求１２０のストリーム・マップ識別子を図３のチャンク・ストア３００に供給することができる。チャンク・ストア３００は、ストリーム・マップ識別子に基づいて対応するストリーム・マップ３１０を引き出し（例えば、ストリーム・マップ・ヘッダー３１２をスキャンすることによって）、リハイドレーション・モジュール７０２は、この引き出されたストリーム・マップ３１０にしたがってデーター・ストリームを再生する、即ち、「リハイドレート」(rehydrate)ことができる。引き出されたストリーム・マップ３１０は、チャンク・コンテナ３０４内におけるデーター・ストリームに含まれるデーター・チャンクの各々に対するポインタ（図４のデーター・チャンク識別子４０４）を含む。リハイドレーション・モジュール７０２は、このポインタを用いて、データー・チャンク３２２の各々を引き出す。リハイドレーション・モジュール７０２は、引き出したストリーム・マップ３１０に含まれるデーター・ストリーム・オフセット４０２を（例えば、引き出されたストリーム・マップ３１０に含まれるかもしれないデーター・チャンク長情報と共に）用いて、引き出したデーター・チャンク３２２を適正な順序に並べて、データー・ストリームを再生する(regenerate)ことができ、このデーター・ストリームがリハイドレーション・モジュール７０２によってデーター・ストリーム７０４として出力される。

【0065】

[0088] 位置関係インディケーター４０６の使用によって、チャンク・コンテナ３０４からデーター・チャンク３２２の順次読み出しを行うことができる。例えば、順次Ｉ／Ｏ（入力／出力）要求または１つよりも多いデーター・チャンク境界に跨がる(encompass)何らかのＩ／Ｏ要求を用いてリハイドレーション・モジュール７０２によってチャンク・ストア３００内にあるファイル・ストリームにアクセスしているとき、ストリーム・マップ３１０は、データー・チャンクへの高速アクセスを可能にする。これは、チャンク・ストア３００がストリーム・マップ３１０を作成した時点で、新たなデーター・チャンクがチャンク・コンテナ３０４内に連続してストリーム・マップの順に格納されるからである。したがって、リハイドレーション・モジュール７０２による順次データー・アクセスの間、同じデーター・ストリームに属するデーター・チャンクが連続して格納される可能性が高くなり、このような連続するデーター・チャンクに１回のデーター・アクセス「シーク」（例えば、読み出すべき次の格納データー・チャンクを発見するためのチャンク・コンテナ全域にわたる順方向および逆方向の移動）でアクセスし読み出すことができ、断片化は一意でないデーター・チャンク（対応するデーター・ストリームを格納する前にチャンク・コンテナ内に既に存在していたストリーム・マップによって参照されているデーター・チャンク）に限られる(reduce)。順次データー・アクセスの間におけるデーター・アクセス・シークは、１つのデーター・チャンクまたはデーター・ストリームの一連のチャンクがチャンク・ストア内に既に存在することが分かっているときに制限される。ストリーム・マップ３１０は、データー重複排除システムの他のモジュール（例えば、ファイル複写(replication)モジュールによって用いられるハッシュ値のリスト）によって必要とされるかもしれない最適化ファイル・メタデーター（例えば、メタデーター３１４）に、効率的なメタデーター・コンテナを付与する。ストリーム・マップ３１０は、簡潔であり、高速アクセスのためにメモリーにキャッシュすることができる。チャンク・ストア３００は、ＬＲＵ（最も長い間使われていない）アルゴリズムまたは他のタイプのキャッシュ・アルゴリズムに基づいて、頻繁にアクセスされるストリーム・マップ３１０（リハイドレーション・モジュール７０２によって頻繁に要求されリハイドレートされた最適データー・ストリーム）をキャッシュすることができる。

【0066】

Ｃ．信頼性の高いデーター・チャンクの位置検出を可能にするチャンク・ストアの実施形態例
[0089] 前述のように、断片化解消技法のために、ガベージ・コレクションを実行するコンパクション技法のために等というように、種々の理由のためにチャンク・コンテナ内部でデーター・チャンクを移動させる場合がある。この副章において、チャンク・コンテナ内部におけるデーター・チャンクの移動を追跡し続ける実施形態について説明する。

【0067】

[0090] 図８は、一実施形態によるチャンク・コンテナ３０４のブロック図を示す。図８に示すように、チャンク・コンテナ３０４は、総じて図３のチャンク・コンテナに似ており、ファイル・ヘッダー３１８に含まれるチャンク・コンテナ識別子８０２およびチャンク・コンテナ生成指示８０４が追加されている。チャンク・コンテナ識別子８０２は、チャンク・コンテナ３０４を、チャンク・ストア３００内に存在するかもしれない他のチャンク・コンテナから区別するためにチャンク・コンテナ３０４に割り当てられた一意の識別子（例えば、識別番号）である。チャンク・コンテナ生成指示８０４は、チャンク・コンテナ３０４に対する改訂(revision)または生成を示す。例えば、１つ以上のデーター・チャンク３２２がチャンク・コンテナ３０４内部で移動させられる毎に、生成指示８０４を変更することができる（例えば、０のような開始生成レベル、またはその他の開始値から始めて、次の生成レベルに高めることができる）。

【0068】

[0091] 一実施形態では、チャンク・コンテナ３０４を、チャンク・コンテナ識別子８０２とチャンク・コンテナ生成指示８０４の組み合わせによって特定することができる（例えば、チャンク・コンテナ３０４のファイル名を形成することができる）。一実施形態では、チャンク・コンテナ識別子８０２およびチャンク・コンテナ生成指示８０４の双方が整数であってもよい。チャンク・コンテナ３０４は、固定サイズ（または固定数のエントリ）を有してもよく、または可変サイズを有してもよい。例えば、一実施形態例では、チャンク・コンテナ３０４を定める各チャンク・コンテナ・ファイルは、約１６，０００個のチャンクを格納する大きさにすることができ、平均的なチャンク・サイズは６４ＫＢであり、チャンク・コンテナ・ファイルのサイズは１ＧＢに設定される。他の実施形態では、チャンク・コンテナ・ファイルは代わりのサイズを有してもよい。

【0069】

[0092] チャンク・コンテナ３０４に格納されているデーター・チャンク３２２には、種々の方法で、メタデーター４００（図４）のデーター・チャンク識別子４０４にしたがって参照することができる。実施形態では、データー・チャンク識別子４０４は、このような参照を可能にする種々のタイプの情報を含むことができる。例えば、一実施形態では、データー・チャンク識別子４０４は、データー・チャンク・コンテナ識別子、ローカル識別子、チャンク・コンテナ生成値、およびチャンク・オフセット値の内１つ以上を含むことができる。チャンク・コンテナ識別子は、データー・チャンク３２２が格納されているチャンク・コンテナ３０４に対してチャンク・コンテナ識別子８０２の値を有する。ローカル識別子は、データー・チャンク３２２に割り当てられる識別子（例えば、数値）であり、データー・チャンク３２２が格納されているチャンク・コンテナ３０４内部において割り当てられたデーター・チャンク３２２に一意である（例えば、データー・チャンクに対して一意のコンテナ毎の識別子である）。チャンク・コンテナ生成値は、データー・チャンク３２２が格納されているチャンク・コンテナ３０４に対して、データー・チャンク３２２がチャンク・コンテナ３０４に格納された時点におけるチャンク・コンテナ生成指示８０４の値を有する。チャンク・オフセット値は、データー・チャンク３２２がチャンク・コンテナ３０４に追加された時点における、チャンク・コンテナ３０４内におけるデーター・チャンク３２２のオフセットである。

【0070】

[0093] 一実施形態では、チャンク・ストアは、移動したデーター・チャンクを追跡するために用いることができる、信頼性のあるチャンク・ロケータ(chunk locator)を実装(implement)することができる。従来の技法とは対照的に、この信頼性のあるチャンク・ロケータは、データー・チャンク識別子を物理的なチャンク位置にマッピングするためにインデックスを用いない。従来の技法は、チャンク識別子をチャンク・データーの物理位置にマッピングするインデックスを用いる。記憶システムの規模（例えば、数百テラバイト以上）および平均チャンク・サイズ（例えば、６４ＫＢ）のために、このようなインデックスは非常に大きくなる。このようなインデックスを全てメモリーにロードすると、大量の利用可能なメモリーおよびプロセッサー・リソースを消費することになる。インデックスをメモリーにロードしないと、インデックスをメモリーにページングする(page)必要があるので、データー・アクセスは遅くなる。

【0071】

[0094] 一実施形態では、信頼性のあるチャンク・ロケータは、図３におけるチャンク・コンテナ３０４のリダイレクション・テーブル３２０のような、リダイレクション・テーブルの形態で実装される。このリダイレクション・テーブルは、チャンク・コンテナ３０４内において移動させられたデーター・チャンク３２２に対して１つ以上のエントリを格納することができる。各エントリは、移動させられたデーター・チャンク３２２を特定し、その新たな位置におけるチャンク・コンテナ３０４内でのデーター・チャンク３２２の位置を示すデーター・チャンク・オフセット値を有する。移動したデーター・ストリームのデーター・チャンクの位置を検出するために、データー・ストリームのリハイドレーションの間リダイレクション・テーブルを参照することもできる。

【0072】

[0095] 例えば、図９は、一実施形態例によるリダイレクション・テーブル９００のブロック図を示す。リダイレクション・テーブル９００は、データー・チャンク３２２がチャンク・コンテナ３０４内部で移動させられた場合に、データー・チャンク３２２（データー・チャンクとして格納されたストリーム・マップを含む）の位置を検出するために用いられる。例えば、リダイレクション・テーブル９００は、ガベージ・コレクションおよびコンパクション・プロセスの一部として空間再利用のために、チャンク・コンテナ３０４内部でデーター・チャンク３２２を移動させることができ、それでもなおデーター・チャンク３２２の元のチャンク識別子に基づいて信頼性高くデーター・チャンク３２２の位置を検出可能にすることができる。図９に示すように、リダイレクション・テーブル９００は、第１エントリ９０２ａおよび第２エントリ９０２ｂのような、複数のエントリ９０２を含む。数百、数千、およびそれ以上の数のエントリ９０２も含む、いずれの数のエントリ９０２でも、リダイレクション・テーブル９００に含ませることができる。各エントリ９０２は、ローカル識別子９０４と変更チャンク・オフセット値９０６とを含む。例えば、第１エントリ９０２ａは、第１ローカル識別子９０４ａと第１変更チャンク・オフセット値９０６ａとを含み、第２エントリ９０２ｂは、第２ローカル識別子９０４ｂと第２変更チャンク・オフセット値９０６ｂとを含む。

【0073】

[0096] ローカル識別子９０４は、最初にチャンク・コンテナ３０４に格納されたときにデーター・チャンク３２２に割り当てられる一意のローカル識別子である。変更チャンク・オフセット値９０６は、移動させられたデーター・チャンク３２２に対して、対応するローカル識別子９０４を有する新たなチャンク・オフセット値である。したがって、リダイレクション・テーブル９００には、データー・チャンクに対する位置関係インディケーターを用いてアクセスし、そのデーター・チャンクに対する変更チャンク・オフセット値を判定することができる。

【0074】

[0097] 例えば、図９におけるローカル識別子９０４ａは、データー・チャンク６１４ｂに割り当てられたローカル識別子とすることができる。データー・チャンク６１４ｂに割り当てられたローカル識別子を用いて、リダイレクション・テーブル９００のエントリ９０２ａにアクセスし、チャンク・コンテナ３０４内におけるデーター・チャンク６１４ｂの新たな位置を示す、変更チャンク・オフセット値９０６ａを決定することができる。

【0075】

[0098] 尚、リダイレクション・テーブル９００はいずれのサイズを有してもよいことを注記しておく。例えば、一実施形態では、リダイレクション・テーブル９００にサイズは、（所定の最大数のデーター・チャンク−コンパクションのために削除された所定の最小数のデーター・チャンク）×（リダイレクション・テーブル・エントリのサイズ）によって制限するとよい。場合によっては、データー・チャンクの配置換え(relocation)が希にしか起こらないこともある。一実施形態では、データー・チャンクに対して変更チャンク・オフセット値を決定した後、ストリーム・マップからこのデーター・チャンクへのいずれのポインタも、ストリーム・マップにおいて変更チャンク・オフセット値に修正し、エントリ９０２をリダイレクション・テーブル９００から除去することができる。状況によっては、時間の経過に連れてこのようにリダイレクション・テーブル９００からエントリ９０２がなくなる場合もある。

【0076】

[0099] リダイレクション・テーブルには、種々の方法でエントリを追加することができる。例えば、図１０は一実施形態にしたがって、データー・ストリームを格納するフローチャート１０００を示す。フローチャート１０００に関する論述に基づいて、関連技術（１つまたは複数）の当業者には、更に他の構造および動作の実施形態も明白であろう。以下にフローチャート１０００について説明する。

【0077】

[0100] フローチャート１０００は、ステップ１００２から開始する。ステップ１００２において、チャンク・コンテナの内容を修正(modify)する。例えば、一実施形態では、図８のチャンク・コンテナ３０４における１つ以上のデーター・チャンク３２２を移動させることができる。このようなデーター・チャンク３２２は、断片化解消プロセス、ガベージ・コレクション後のコンパクション・プロセス、またはその他のプロセスというような、維持タスク（例えば、図１における維持モジュール１０６）によって移動させることができる。

【0078】

[0101] ステップ１００４において、ステップ１００２によるチャンク・コンテナの１つ以上のデーター・チャンクに対する変更チャンク・オフセット値を示した１つ以上のエントリを、リダイレクション・テーブルに追加する。例えば、１つ以上の移動させられたデーター・チャンク３２２に対応する１つ以上のエントリ９０２をリダイレクション・テーブル９００に追加することができる。例えば、移動させられたデーター・チャンク３２２毎に、移動させられたデーター・チャンク３２２のローカル識別子の値を示すエントリ９０２を、ローカル識別子９０４として生成することができ、このエントリ９０２は、移動させられたデーター・チャンク３２２の新たなオフセット値を、変更チャンク・オフセット値９０６として示す。

【0079】

[0102] ステップ１００６において、ステップ１００２に伴い、チャンク・コンテナ・ヘッダー内にある生成指示が増加する。例えば、一実施形態では、チャンク・コンテナ生成指示８０４は０の初期値を有することができ、データー・チャンク３２２がチャンク・コンテナ３０４内で移動させられる毎に、チャンク・コンテナ生成指示８０４を増加させて、更に高い生成値を示すことができる。他の実施形態では、チャンク・コンテナ生成指示８０４を他の方法で修正することもできる。

【0080】

[0103] したがって、参照元ストリーム・マップ３１０に格納されているデーター・チャンク識別子を用いて図８のチャンク・コンテナ３０４のデーター・チャンク３２２を調べるとき、チャンク・コンテナ３０４のチャンク・コンテナ生成指示８０４をチェックして、チャンク・コンテナ３０４の現在の生成が、データー・チャンク識別子のチャンク・コンテナ生成値と同じか否か確かめることができる。これらが同じである場合、データー・チャンク識別子内にあるチャンク・オフセット値によって示されるオフセットに、データー・チャンク３２２を配置することができる。同じでない場合、リダイレクション・テーブル９００を読み取って、チャンク・コンテナ３０４内におけるデーター・チャンク３２２の変更オフセット値を決定する。

【0081】

[0104] 例えば、図１１は、一実施形態例にしたがって、データー・ストリーム要求１１１０に応じてデーター・ストリームをリハイドレートするために、ストリーム・コンテナ３０２およびチャンク・コンテナ３０４と通信するリハイドレーション・モジュール１１３０のブロック図を示す。図１１に示すように、リハイドレーション・モジュール１１３０は、データー・ストリーム・アセンブラー１１０２と、生成チェッカー１１０６と、データー・チャンク・リトリバー１１０８とを含む。以下に、図１１について説明する。

【0082】

[0105] 図１１において、データー・ストリーム・アセンブラー１１０２は、データー・ストリーム要求１１１０を受ける。データー・ストリーム要求１１１０は、ストリーム・コンテナ３０２に格納されているストリーム・マップ１１０４のような、リハイドレートしようとしているデーター・ストリームに対応するストリーム・マップを示す。データー・ストリーム・アセンブラー１１０２は、ストリーム・マップ１１０４を処理して、ストリーム・マップ１１０４によって参照されているデーター・チャンク毎に、データー・チャンク要求１１１２を生成する。

【0083】

[0106] 一実施形態では、データー・ストリーム・アセンブラー１１０２が生成するデーター・チャンク要求１１１２は、要求されたデーター・チャンク３２２を特定するためのデーター・チャンク識別子を含むとよい。位置を突き止められたチャンク・コンテナには次のようにアクセスして、要求されたデーター・チャンクを引き出すことができる。

【0084】

[0107] 図１１に示すように、生成チェッカー１１０６は、要求されたデーター・チャンクに対するデーター・チャンク要求１１１２を受ける。生成チェッカー１１０６は、チャンク・コンテナ３０４（要求されたデーター・チャンク３２２のチャンク・コンテナ識別子と一致するチャンク・コンテナ識別子８０２を有することが以上で確認されたチャンク・コンテナ３０４）にアクセスする。生成チェッカー１１０６は、チャンク・コンテナ３０４に対するチャンク・コンテナ生成指示８０４を、要求されたデーター・チャック３２２に対するチャック・コンテナ生成値と比較し、生成一致指示１１１４を出力するように構成されている。これらの値が一致しない場合（例えば、チャンク・コンテナ生成指示８０４の値が、要求されたデーター・チャンク３２２に対するチャンク・コンテナ生成値よりも大きい場合）、生成一致指示１１１４は、一致が得られなかったことを示し、動作はステップ１８０６に進む。これらの値が一致した場合、生成一致指示１１１４は、一致が得られたことを示し、要求されたデーター・チャンクを引き出す標準的なＩ／Ｏ経路（または他の経路）に従うことができる。

【0085】

[0108] 図１１に示すように、データー・チャンク・リトリバー１１０８は、生成一致指示１１１４とデーター・チャンク要求１１１２とを受け取る。生成一致指示１１１４が、一致が得られなかったことを示す場合、データー・チャンク・リトリバー１１０８は、要求されたデーター・チャンク３２２のローカル識別子と一致するローカル識別子９０４を有するエントリ９０２内にある変更チャンク・オフセット値９０６（図９）を求めて、リダイレクション・テーブル９００にアクセスする。図１１に示すように、データー・チャンク・リトリバー１１０８は、第１チャンク・オフセット値とは異なる第２チャンク・オフセット値１１６を受け取る。

【0086】

[0109] 図１１に示すように、データー・チャンク・リトリバー１１０８は、第２チャンク・オフセット値１１１６に位置するデーター・チャンク３２２ｚを求めて、チャンク・コンテナ３０４にアクセスする。データー・チャンク３２２ｚは、要求されたデーター・チャンク３２２であり、チャンク・コンテナ３０４内において第２チャンク・オフセット値１１１６に移動させられている。

【0087】

[0110] 図１１に示すように、データー・チャンク・リトリバー１１０８は、現在の例ではデーター・チャンク３２２ｚである、データー・チャンク１１１８を出力する。データー・チャンク１１１８は、データー・ストリーム・アセンブラー１１０２によって受け取られる。このように、データー・ストリーム・アセンブラー１１０２は、ストリーム・マップ１１０４によって参照されている全てのデーター・チャンク３２２を、データー・チャンク・リトリバー１１０８から受け取る。これらのデーター・チャンク３２２は、対応するチャンク・オフセット値にしたがってチャンク・コンテナ３０４から直接引き出されるか、またはリダイレクション・テーブル９００によってリダイレクトされて、チャンク・コンテナ３０４から引き出される。図１１に示すように、データー・ストリーム・アセンブラー１１０２は、データー・ストリーム１１２０を生成する。データー・ストリーム１１２０は、データー・ストリーム要求１１１０において示された、要求されたデーター・ストリームが元に戻された形態である。データー・ストリーム・アセンブラー１１０２は、本明細書の他のところで説明したように、受け取ったデーター・チャンク３２２の全てを纏めて組み立て、データー・ストリーム１１２０を形成する。

【0088】

[0111] 尚、データー・ストリームのリパース・ポイント(reparse point)に存在するストリーム・マップ参照識別子（例えば、図６におけるストリーム・リンク６０８ａまたは６０８ｂ）は、データー・チャンク識別子と同じ構造を有するのでもよいことを注記しておく。先に説明したように、ストリーム・マップ３１０は、エンド・ユーザー・ファイル・データーの代わりに、ストリーム・マップ・メタデーターを収容するデーター・チャンク３２２の形態を有することもできる。したがって、ストリーム・マップ３１０にアドレスする手順は、データー・チャンク３２２にアドレスするのと同じでよい。双方の技法は、データー・チャンク識別子の構造を用いることができる。最適化データー・ストリームは、ストリーム・マップ３１０のデーター・チャンク識別子をファイル・リパース・ポイント（実際のデーター・ストリーム・ファイル・オブジェクトに添付される）に置くことによって、ストリーム・マップ３１０を参照する。ストリーム・マップ識別子は、［コンテナ識別子、ローカル識別子、生成値、オフセット値］情報を収容する。この情報は、ストリーム・コンテナ３０２の内部においてストリーム・マップ３１０のデーター・チャンクの位置を突き止めるために（直接、またはリダイレクション・テーブルを通じて）用いることができる。したがって、一実施形態では、ストリーム・コンテナ３０２のフォーマットおよびレイアウトは、チャンク・コンテナ３０４のそれと本質的に同一であってよい。

【0089】

Ｄ．データー最適化バックアップの実施形態例
[0112] データー最適化技法を装備するデーター・システムをバックアップし復元することは、チャンク・ストア内において多数のデーター・ストリーム間でデーターが共有されるので困難である。したがって、データーはファイル名称空間から分離される。しかしながら、データー・バックアップおよび復元能力は有用である。通例、エンティティは、有効なデーター・バックアップが一体になっていなければ、データー最適化の解決手段を装備することを躊躇するであろう。

【0090】

[0113] 実施形態では、データー最適化環境に合わせて種々のバックアップ技法が設けられ、最適化バックアップ、無最適化バックアップ(un-optimized backup)、項目レベル最適化バックアップ、および混成バックアップ技法が含まれる。更に、実施形態では、異なるバックアップ技法間で選択を行うために発見法を用いることができる。例えば、最適化バックアップと無最適化バックアップとの間で選択するために発見法を用いてもよい。実施形態は、データー最適化システムに最適化バックアップ技法を設けて、データーがその最適化された（例えば、重複排除した）形態でバックアップできるようにする。実施形態は、用いるバックアップ媒体空間を削減してデーター・バックアップを行うことを可能とし、バックアップ時間枠(time window)を短縮するために用いることができる。これは、年々増大するデーターを考慮すると重要である。更に、実施形態は、バックアップからのデーター復元の高速化を可能にする（例えば、ＲＴＯ（復元時間目標）を小さくする）。

【0091】

[0114] 実施形態では、データー最適化システムにおけるバックアップは、種々の方法で実行することができる。例えば、図１２は、一実施形態例にしたがって、データー最適化システムにおいてデーターのバックアップを実行するフローチャート１２００を示す。フローチャート１２００は、一実施形態では、図１のチャンク・ストア・インターフェース１１６によって実行することができる。例示の目的に限って、図１３に関してフローチャート１２００を説明する。図１３は、一実施形態例によるデーター・バックアップ・システム１３００のブロック図を示す。フローチャート１２００は、データー・バックアップ・システム１３００によって実行することができる。図１３に示すように、データー・バックアップ・システム１３００は、データー・バックアップ・モジュール１３０２と、バックアップ・ストレージ１３０４と、チャンク・ストア１３３４とを含む。チャンク・ストア１３３４は、ストリーム・コンテナ３０２と、１つ以上のチャンク・コンテナ３０４（例えば、チャンク・コンテナ３０４ａおよび３０４ｂ）とを含む。更に他の構造的および動作上の実施形態も、フローチャート１２００に関する論述に基づいて、関連技術（１つまたは複数）の当業者には明白であろう。フローチャート１２００について、以下のように説明する。

【0092】

[0115] フローチャート１２００のステップ１２０２において、チャンク・ストアに格納されている複数の最適化データー・ストリームを、バックアップのために特定する。例えば、図１３を参照すると、データー・バックアップ・モジュール１３０２は、チャンク・ストア１３３４に格納されている１つ以上の最適化データー・ストリームをバックアップ・ストレージ１３０４に格納する要求１３１８を受けることができる。要求１３１８は、最適化データー・ストリームに対応する最適化ストリーム構造（例えば、ファイル）の対応するファイル名称によって、これら１つ以上の最適化データー・ストリームを特定することができる。各最適化ストリーム構造は、前述のように、最適化データー・ストリームのチャンク・コンテナ３０４の１つ以上に格納されているデーター・チャンク３２２へのマッピングを記述するメタデーターを収容するストリーム・コンテナ３０２におけるストリーム・マップ・チャンク１３１６のストリーム・マップ・チャンクを参照する。

【0093】

[0116] ステップ１２０４において、先の複数の最適化データー・ストリームをバックアップするために、チャンク・ストアの少なくとも一部をバックアップ・ストレージに格納する。要求１３１８に応答して、データー・バックアップ・モジュール１３０２は、要求１３１８において特定された最適化データー・ストリームをバックアップ・ストレージに格納するように、チャンク・ストア１３３４の少なくとも一部をバックアップ・ストレージ１３０４に格納することができる。データー・バックアップ・モジュール１３０２は、チャンク・ストア１３３４の一部を種々の方法でバックアップ・ストレージ１３０４に格納することによって、最適化データー・ストリームを格納することができる。例えば、一実施形態では、最適化データー・ストリーム毎に、データー・バックアップ・モジュール１３０２は、ストリーム・マップ・チャンク１３１６の対応するストリーム・マップ・チャンク、およびストリーム・マップ・チャンクによって参照されているデーター・チャンク３２２を決定することができ、そして決定したストリーム・マップ・チャンクおよびデーター・チャンクをバックアップ・ストレージ１３０４に格納することができる。他の実施形態では、データー・バックアップ・モジュール１３０２は、最適化データー・ストリームをバックアップするために、最適化データー・ストリームの内決定したチャンクを含むチャンク・ストア１３３４のもっと大きな部分をバックアップ・ストレージ１３０４に格納することもできる。

【0094】

[0117] したがって、データー・バックアップ・モジュール１３０２は、ステップ１２０４にしたがって種々の方法で最適化データー・ストリームを格納するように構成することができる。例えば、図１３に示すように、データー・バックアップ・モジュール１３０２は、最適化ファイル・バックアップ・モジュール１３０６と、リハイドレーション・バックアップ・モジュール１３０８と、項目レベル・バックアップ・モジュール１３１０と、データー・チャンク識別子バックアップ・モジュール１３１２とを含むことができる。実施形態では、データー・バックアップ・モジュール１３０２は、モジュール１３０６、１３０８、１３１０、および１３１２の内いずれの１つ以上でも含むことができる。モジュール１３０６、１３０８、１３１０、および１３１２は、最適化データー・ストリームを種々の方法でバックアップ・ストレージ１３０４に格納することを可能にする。モジュール１３０６、１３０８、１３１０、および１３１２について、以下のように説明する。

【0095】

[0118] 一実施形態では、最適化バックアップ（「最適化データー・ストリーム・バックアップ」とも呼ぶ）は、最適化データー・ストリームを最適化した形態でバックアップするために実行することができる。例えば、最適化ファイル・バックアップ・モジュール１３０６は、最適化データー・ストリームをバックアップ・ストレージ１３０４に最適化した形態で格納することによって、最適化バックアップを実行するように構成することができる。最適化バックアップにしたがって、最適化データー・ストリームをバックアップするために、チャンク・ストア１３３４の１つ以上のチャンク・コンテナ全体を格納することができる。例えば、一実施形態では、最適化ファイル・バックアップ・モジュール１３０６は、図１４に示すフローチャート１４００を実行することができる。フローチャート１４００および最適化ファイル・バックアップ・モジュール１３０６について、以下のように説明する。

【0096】

[0119] ステップ１４０２において、チャンク・ストア全体をバックアップ・ストレージに格納する。一実施形態では、最適化ファイル・バックアップ・モジュール１３０６は、要求１３１８において示された最適化データー・ストリームがバックアップされるように、チャンク・ストア１３３４全体をバックアップ・ストレージ１３０４に格納することができる。あるいは、最適化ファイル・バックアップ・モジュール１３０６は、最適化データー・ストリームがバックアップされるように、チャンク・ストア１３３４の内、要求された最適化データー・ストリーム全体を含む１つ以上のチャンク・コンテナ全体（例えば、ストリーム・コンテナ３０２およびチャンク・コンテナ３０４の内１つ以上）を格納することができる。バックアップしようとするチャンク・コンテナは、チャンク識別子の内、最適化データー・ストリームの最適化ストリーム構造によって参照されているチャンクに対するチャンク・コンテナ識別子によって識別することができる。格納動作１３２０にしたがって、最適化ファイル・バックアップ・モジュール１３０６によって、チャンク・コンテナ／チャンク・ストア全体をバックアップ・ストレージ１３０４に格納することができる。

【0097】

[0120] ステップ１４０４において、チャンク・ストアにおける対応するデーターにリンクする複数の最適化データー・ストリームに対して、複数のストリーム・メタデーター・スタブをバックアップ・ストレージに格納する。ストリーム・メタデーター・スタブは、最適化ファイル・バックアップ・モジュール１３０６によって、バックアップ・ストレージ１３０４以外のストレージというような、他のストレージ（例えば、主ストレージ）から引き出すことができ、これらは最適化データー・ストリームに対するチャンク・ストア１３３４におけるデーター・ストアにリンクするファイルである。例えば、各ストリーム・メタデーター・スタブは、ストリーム・マップ・チャンクによって参照されているいずれのデーター・チャンク３２２でも組み合わせることによって、リハイドレーション・プロセスの間に対応するデーター・ストリームを非最適化形態に構築し直す／組み立て直すために用いることができる、ストリーム・マップ・チャンク１３１６のそれらの対応するストリーム・マップ・チャンクへの参照を収容することができる。一実施形態では、要求１３１８において特定された最適化データー・ストリームに対応するストリーム・メタデーター・スタブは、最適化ファイル・バックアップ・モジュール１３０６によって、格納動作１３２０を用いて、バックアップ・ストレージ１３０４に格納される。ストリーム・メタデーター・スタブは、それらの「ディスク上」フォーマットで、最適化ファイル・バックアップ・モジュール１３０６によってバックアップ・ストレージ１３０４に格納することができる。

【0098】

[0121] したがって、バックアップ・ストレージ１３０４上にある最適化データー・ストリームについてファイル状態を示す「ボリューム・イメージ」は、チャンク・ストア１３３４を忠実に表現する(mirror)。バックアップ・ストレージ１３０４に格納されたチャンク・コンテナおよび格納されたストリーム・メタデーター・スタブの組み合わせによって、最適化された（組み立て直されたのではない）形態で、最適化データー・ストリームの完全な格納が行われる。追加のメタデーターを格納する必要はない。

【0099】

[0122] 最適化バックアップ（例えば、フローチャート１４００および最適化ファイル・バックアップ・モジュール１３０６による）は、最適化データー・ストリームをバックアップするいずれの状況においても実行することができる。最適化バックアップは、バックアップされるボリューム（バックアップ・ストレージにおいてアクセス可能な記憶エリア）の殆どが範囲内にある場合に実行することが望まれると考えられる。要求１３１８において特定された最適化データー・ストリームによって参照されていないが他の最適化データー・ストリームによって参照されているデーター・チャンクは、チャンク・コンテナに含まれているかもしれないので、チャンク・コンテナ全体を格納するときには、何らかの「無駄」があり得る。したがって、必要とされるよりも多いデーター全体がバックアップされる可能性がある。範囲内においてバックアップされる量が比較的少ない場合（例えば、バックアップされたチャンク・コンテナに含まれている少数のデーター・チャンクが、要求１３１８において特定された最適化データー・ストリームと関連付けられている）、チャンク・コンテナ全体を格納するのではない他のバックアップ技法が望まれる場合もある（例えば、以下で説明する無最適化バックアップ技法）。

【0100】

[0123] 最適化バックアップにしたがってバックアップされた最適化データー・ストリームを復元するには、この復元が最適化された復元となるように、チャンク・ストア・コンテナ・ファイルおよびストリーム・メタデーター・スタブを復元する必要がある。このような最適化格納(optimized store)の方が相対的にサイズが小さく、したがって相対的に高速であり、消費するＩ／Ｏ資源が少ない。最適化バックアップからの最適化データー・ストリームの選択的復元のための技法については、次の副章において以下で更に詳しく説明する。

【0101】

[0124] したがって、最適化バックアップの実施形態は種々の便益を提供することができる。例えば、最適化バックアップの結果、バックアップの格納サイズを縮小することができ、バックアップ媒体空間（例えば、バックアップ・ストレージ１３０４における）を節約する。これは、ディスクに基づくバックアップの解決策には有用となるであろう。場合によっては、バックアップ・ストレージにおける記憶空間の節約が、主ストレージにおける節約よりも意味があり、価格効率的になる場合もある。最適化バックアップの結果、バックアップを実行する時間を短縮することができる。バックアップ実行時間を短縮することができ、年々増大しつつあるデーターの格納量を考慮すると、これは有意である。データー量の増大のために、ストレージ・ユーザーは、頻繁にバックアップを行う（例えば、毎日）ことに悪戦苦闘する場合もある。何故なら、バックアップ実行時間は、データー量と共に増大するからである。最適化バックアップ技法は、バックアップ実行時間を短縮するのに役立つことができる。更に、最適化バックアップはＲＴＯを短縮し、復元の高速化をもたらすことができる。ＲＴＯは、バックアップ／復元解決策の重要な尺度である。

【0102】

[0125] 他の実施形態では、最適化データー・ストリームを非最適化(non-optimized)または無最適化(un-optimized)形態で格納するために、非最適化バックアップ（「無最適化データー・ストリーム・バックアップ」とも呼ぶ）を実行することもできる。非最適化バックアップによれば、バックアップ・ストレージに合わせて設計された最適化データー・ストリームを、格納する前に、リハイドレートすることができる。例えば、一実施形態では、リハイドレーション・バックアップ・モジュール１３０８が、最適化データー・ストリームをリハイドレートし、リハイドレートしたデーター・ストリームをバックアップ・ストレージ１３０４に格納することによって、非最適化バックアップを実行するように構成することができる。一実施形態では、リハイドレーション・バックアップ・モジュール１３０８は、図１５に示すフローチャート１５００を実行することができる。フローチャート１５００およびリハイドレーション・バックアップ・モジュール１３０８について、以下のように説明する。

【0103】

[0126] フローチャート１５００のステップ１５０２において、各最適化データー・ストリームをリハイドレートして、対応する無最適化データー・ストリームにする。この無最適化データー・ストリームは、対応する最適化ストリーム・メタデーターによって参照されているあらゆるデーター・チャンクを含む。リハイドレーション・バックアップ・モジュール１３０８は、リハイドレーション・モジュール７０２（図７）について先に説明したようなことを含む、いずれのやり方でも最適化データー・ストリームをリハイドレートすることができる。例えば、図１３を参照すると、リハイドレーション・バックアップ・モジュール１３０８は、ストリーム・コンテナ１３０２にアクセスして、要求１３１８において特定された最適化データー・ストリームに対応するストリーム・マップ・チャンクの形態、または他の形態（例えば、グローバル・テーブル、データーベース等）の最適化ストリーム・メタデーターを求めることができる。図１３に示すように、リハイドレーション・バックアップ・モジュール１３０８は、所望のストリーム・マップ・チャンクに対する１つ以上のストリーム・コンテナ・アクセス１３２２を生成することができる。ストリーム・コンテナ・アクセス１３２２は、対応するストリーム・マップ識別子によって、所望のストリーム・マップ・チャンクを特定することができる。ストリーム・コンテナ・アクセス１３２２に応答して、リハイドレーション・バックアップ・モジュール１３０８は要求１３１８において特定された最適化データー・ストリームに対応するストリーム・マップ・チャンク１３２４をストリーム・コンテナ３０２から受け取る。リハイドレーション・バックアップ・モジュール１３０８は、対応する引き出されたストリーム・マップ・チャンクのストリーム・マップにしたがって、各最適化データー・ストリームを再生する、即ち、「リハイドレートする」ことができる。図１３の例では、各ストリーム・マップは、対応する最適化データー・ストリームに含まれるデーター・チャンクの各々へのポインタ（例えば、図４のデーター・チャンク識別子４０４）を含む。これらのデーター・チャンクは、チャンク・コンテナ３０４ａおよび／または３０４ｂに含まれているとよい。リハイドレーション・バックアップ・モジュール１３０８は、このポインタを用いて、参照されているデーター・チャンク３２２の各々を引き出す。例えば、リハイドレーション・バックアップ・モジュール１３０８は、チャンク・コンテナ・アクセス１３２６および／または１３３０の内１つ以上を生成して、第１および／または第２チャンク・コンテナ３０４ａおよび３０４ｂそれぞれからデーター・チャンク３２２を得ることができる。チャンク・コンテナ・アクセス１３２６および／または１３３０に応答して、リハイドレーション・バックアップ・モジュール１３０８は要求１３１８において特定された最適化データー・ストリームに対応するデーター・チャンク１３２８および／または１３３２をチャンク・コンテナ３０２ａおよび３０２ｂから受け取る。

【0104】

[0127] リハイドレーション・バックアップ・モジュール１３０８は、引き出されたストリーム・マップ（例えば、図３のストリーム・マップ３１０）に含まれるデーター・ストリーム・オフセット４０２を用いて、引き出されたデーター・チャンクを適正な順序に並べて各データー・ストリームを無最適化形態で（例えば、無最適化データー・ストリームとして）再生することができる。

【0105】

[0128] ステップ１５０４において、無最適化データー・ストリームの各々をバックアップ・ストレージに格納する。例えば、図１３に示すように、無最適化データー・ストリームは、格納動作１３２０にしたがって、リハイドレーション・バックアップ・モジュール１３０８によってバックアップ・ストレージ１３０４に格納することができる。したがって、データー・ストリームをバックアップ・ストレージ１３０４から復元することが望まれる場合、バックアップ・ストレージ１３０４に格納されている無最適化データー・ストリームを引き出すことができる。

【0106】

[0129] このように、無最適化バックアップ（フローチャート１５００およびリハイドレーション・バックアップ・モジュール１３０８による）は、最適化データー・ストリームをバックアップするいずれの状況においても実行することができる。無最適化バックアップを実行することが望まれると考えられるのは、最適化データー・ストリームのデーター・チャンクがチャンク・ストア１３３４の記憶空間の内比較的少ない部分を埋める場合である。つまり、チャンク・コンテナ全体をバックアップ・ストレージ１３０４に格納すると、要求１３１８において特定された最適化データー・ストリームに関係ない多数のデーター・チャンクを格納することも含む可能性があるが、そうするのはなく、特定の最適化データー・ストリームをリハイドレートしてバックアップ・ストレージ１３０４に格納することができる。したがって、バックアップ媒体は、データー・ストリームをそれらの最適化されていていない元の形態で格納することができ、関係ないデーター・チャンクを格納することを回避することによって、バックアップ記憶空間を節約することができる。

【0107】

[0130] 無最適化バックアップの実施形態は、種々の便益を提供することができる。例えば、無最適化バックアップは、選択的バックアップをより多く用い（そして選択的復元を可能にする）、実施するのが比較的容易である。バックアップしたデーター・ストリームの復元は、記憶システムが用いるデーター最適化技法に左右されない。何故なら、データー・ストリームは無最適化形態でバックアップされているからである。したがって、インストールされたデーター最適化解決策の機能に左右されることなく、データー・ストリームはどこでも復元およびアクセスすることができる。

【0108】

[0131] リハイドレーション・プロセスのために、無最適化バックアップは比較的遅くなる可能性があり、データー・バックアップ・モジュール１３０２の性能に影響を及ぼす可能性がある。最適化データーのハイドレーションは、最適化データーには解凍が行われるために、更に潜在的にデーター断片化のために、通常のデーター読み出しよりも遅い。更に、データー・ストリームが無最適化形態でバックアップされるので、バックアップされるデーターの総量が大きくなる可能性がある。これは、重複排除の利点がないからである。データーの総量は、潜在的に、バックアップされるボリュームよりも大きな量になることもある（何故なら、ボリュームは最適化されるが、バックアップ・データーは最適化されないからである）。場合によっては、バックアップ・ストレージのサイズ制限のために、データーの全てをバックアップすることができない場合もある。つまり、無最適化バックアップは、特定のバックアップ状況における使用のために選択されるとよい。無最適化バックアップまたは他のバックアップ技法を選択する例について、以下で更に説明する。

【0109】

[0132] 他の実施形態では、項目レベル最適化形態で最適化データー・ストリームを格納するために、項目レベル・バックアップを実行することもできる。項目レベル・バックアップによれば、バックアップ・ストレージに指定された最適化データー・ストリームが、最適化形態での格納のために準備される。例えば、特定の最適化データー・ストリームのために、最適化データー・ストリームのストリーム・マップ・チャンクによって参照されているデーター・チャンクを判定する。参照されているデーター・チャンクの内既にバックアップ・ストレージに格納されているものはいずれも、チャンク・ストアから引き出されない。参照されているデーター・チャンクの内未だバックアップ・ストレージに格納されていないものはいずれも、チャンク・ストアから引き出され、バックアップ・ストレージに格納される。例えば、一実施形態では、項目レベル・バックアップ・モジュール１３１０は、バックアップ・ストレージ１３０４に、ストリーム・マップ・チャンクと、参照されているデーター・チャンクの内未だバックアップ・ストレージ１３０４に格納されていないものを格納することによって、項目レベル・バックアップを実行するように構成することができる。例えば、項目レベル・バックアップ・モジュール１３１０は、一実施形態では、図１６に示すフローチャート１６００を実行することができる。フローチャート１６００は、要求１３１８において特定された最適化データー・ストリーム毎に実行することができる。フローチャート１６００および項目レベル・バックアップ・モジュール１３１０について、以下のように説明する。

【0110】

[0133] フローチャート１６００のステップ１６０２において、バックアップするために特定された第１最適化データー・ストリームを受け取る。例えば、要求１３１８は最適化データー・ストリームを特定することができる。この最適化データー・ストリームに対して、項目レベル・バックアップ・モジュール１３１０は、最適化ストリーム・メタデーター（例えば、ストリーム・コンテナ３０２からのストリーム・マップ・チャンク１３２４）を引き出すことができ、最適化ストリーム・メタデーターによって参照されているいずれのデーター・チャンク３２２もチャンク・コンテナ３０４から引き出すことができる。例えば、項目レベル・バックアップ・モジュール１３１０は、ストリーム・コンテナ３０２へのストリーム・コンテナ・アクセス１３２２を生成して所望のストリーム・マップ・チャンクをストリーム・マップ・チャンク１３２４として引き出すことができ、更にチャンク・コンテナ・アクセス１３２６および／または１３３０の内１つ以上を生成して、第１および／または第２チャンク・コンテナ３０４ａおよび３０４ｂから、参照されているデーター・チャンク３２２をデーター・チャンク１３２８および／または１３３２として入手することができる。

【0111】

[0134] ステップ１６０４において、第１最適化データー・ストリームの最適化ストリーム・メタデーターによって参照されている１つ以上のデーター・チャンクの内、バックアップ・ストレージに未だ格納されていないものを判定する。一実施形態では、項目レベル・バックアップ・モジュール１３１０は、ストリーム・マップ・チャンクのメタデーターによって参照されているデーター・チャンクを、既にバックアップ・ストレージ１３０４に格納されているあらゆるデーター・チャンクと比較して、参照されているデーター・チャンクの内いずれかが既にバックアップ・ストレージ１３０４に格納されているか否か判定することができる。項目レベル・バックアップ・モジュール１３１０は、参照されているデーター・チャンクのハッシュを、バックアップ・ストレージ１３０４に格納されているデーター・チャンクのハッシュと比較すること（例えば、ハッシュ・インデックス等を用いて）を含む、いずれの方法でもこの比較を実行することができ、参照されているデーター・チャンクのデーター・チャンク識別子をバックアップ・ストレージ１３０４に格納されているデーター・チャンクのデーター・チャンク識別子と比較することもでき、または他の技法にしたがってこの比較を行うこともできる。項目レベル・バックアップ・モジュール１３１０は、リストまたはその他のデーター構造を（例えば、メモリーに）保持することによってというようにして、参照されているデーター・チャンクの内バックアップ・ストレージに未だ格納されていないと判定されたものを追跡し続けることができる。

【0112】

[0135] ステップ１６０６において、第１最適化データー・ストリームの最適化ストリーム・メタデーターをバックアップ・ストレージに格納する。例えば、項目レベル・バックアップ・モジュール１３１０は、最適化データー・ストリームに対してストリーム・コンテナ３０２から引き出されたストリーム・マップ・チャンクを、バックアップ・ストレージ１３０４に格納することができる（例えば、格納動作１３２０を用いて）。

【0113】

[0136] ステップ１６０８において、判定された１つ以上のデーター・チャンクをバックアップ・ストレージに格納する。項目レベル・バックアップ・モジュール１３１０は、 最適化データー・ストリームに対してチャンク・コンテナ３０２ａおよび／または３０２ｂから引き出され、ステップ１６０４において未だバックアップ・ストレージ１３０４に格納されていないと判定されたデーター・チャンクを、バックアップ・ストレージ１３０４に格納することができる（例えば、格納動作１３２０を用いて）。したがって、データー・ストリームをバックアップ・ストレージ１３０４から復元することが望まれるとき、最適化データー・ストリームに対してバックアップ・ストレージ１３０４に格納されているストリーム・マップ・チャンクおよびデーター・チャンクをバックアップ・ストレージ１３０４から引き出し、リハイドレートしてデーター・ストリームを形成することができる。一実施形態では、最適化ストリーム構造（例えば、フローチャート１４００（図１４）のステップ１４０４に関して先に説明したストリーム・メタデーター・スタブ）をバックアップ・ストレージ１３０４にバックアップすることもでき、そしてデーター・ストリームをリハイドレートするためのリパース・ポイントとして、バックアップ・ストレージ１３０４から引き出すことができる。

【0114】

[0137] このように、項目レベル・バックアップ（例えば、フローチャート１６００および項目レベル・バックアップ・モジュール１３１０による）は、最適化データー・ストリームをバックアップするいずれの状況においても実行することができる。項目レベル・バックアップによれば、重複排除データー・チャンクを、バックアップされるあらゆるデーター・ストリームと関連付けつつ、バックアップを最適化形態に維持する（例えば、リハイドレーションなしで、あらゆるデーター・チャンクを１回バックアップする）。チャンク・ストア・コンテナ全体をバックアップすることはしない。

【0115】

[0138] 一実施形態では、バックアップ（および任意に復元）ＡＰＩ（アプリケーション・プログラミング・インターフェース）を、項目レベル・バックアップ・モジュール１３１０によって実装することができる。例えば、バックアップ・セッションを、チャンク・ストア１３３４に格納されている第１ファイルおよび第２ファイルを最適化形態でバックアップするために定めることもできる。この例では、第１ファイルはチャンク・コンテナ３０２ａのデーター・チャンク３２２ａおよび３２２ｂならびにチャンク・コンテナ３０４ｂのデーター・チャンク３２２ｄを含み、第２ファイルは、チャンク・コンテナ３０２ａのデーター・チャンク３２２ａ〜３２２ｃ、ならびにチャンク・コンテナ３０４ｂのデーター・チャンク３２２ｄおよび３２２ｅを含むと仮定する。第１ファイルをバックアップするために、バックアップＡＰＩをコールすることができる。応答して、ＡＰＩは第１ファイルに対するストリーム・マップ・チャンク、ならびにデーター・チャンク３２２ａ、３２２ｂ、および３２２ｄを戻す。戻されたストリーム・マップ・チャンクならびにデーター・チャンク３２２ａ、３２２ｂ、および３２２ｄは、第１ファイルのためにバックアップ・ストレージ１３０４に格納される。続いて、第２ファイルをバックアップするためにバックアップＡＰＩをコールすることができる。応答して、ＡＰＩは第２ファイルに対するストリーム・マップ・チャンク、ならびにデーター・チャンク３２２ｃおよび３２２ｅを戻す。これは、ＡＰＩが、第２ファイルのデーター・チャンク３２２ａ、３２２ｂ、および３２２ｄが既にバックアップ・ストレージ１３０４に格納されていると判定したからである（第１ファイルがバックアップ・ストレージ１３０４にバックアップされることによる）。したがって、戻されたストリーム・マップ・チャンクならびにデーター・チャンク３２２ｃおよび３２２ｅは、第２ファイルのためにバックアップ・ストレージ１３０４に格納される。

【0116】

[0139] 項目レベル・バックアップにしたがってバックアップされたデーター・ストリームを復元するための復元モジュールは、同様のＡＰＩを用いることができ、最適化ストリーム・メタデーターは、復元モジュールＡＰＩが、参照されているデーター・チャンクを指し示すのを補助する。項目レベル・バックアップは、全体バックアップおよび選択的バックアップの双方に対して最適化バックアップ（サイズについて）を可能にする（何故なら、バックアップの粒度がデーター・ストリーム／ファイルの粒度になるからである）。しかしながら、項目レベル・バックアップは比較的遅く複雑である場合があり、しかもブロック・レベルのバックアップ技法とではうまく動作しないこともある。

【0117】

[0140] 更に他の実施形態では、最適化データー・ストリームを他の形式の最適化形態で格納するために、データー・チャンク識別子バックアップを実行することもできる。データー・チャンク識別子バックアップによれば、バックアップしようとする最適化データー・ストリームに対して、データー・チャンク識別子を決定する。データー・チャンク識別子をバックアップ・ストレージに格納し、参照されているデーター・チャンクを格納するチャンク・コンテナをバックアップ・ストレージに格納する。例えば、一実施形態では、データー・チャンク識別子バックアップ・モジュール１３１２は、バックアップ・ストレージ１３０４に、データー・ストリームの最適化ストリーム・メタデーターによって参照されているデーター・チャンク識別子、および関連するデーター・チャンク識別子によって特定されるチャンクを格納するチャンク・コンテナを格納することによって、データー・チャンク識別子バックアップを実行するように構成することができる。例えば、データー・チャンク識別子バックアップ・モジュール１３１２は、一実施形態では、図１７に示すフローチャート１７００を実行することができる。フローチャート１７００およびデーター・チャンク識別子バックアップ・モジュール１３１２について、以下のように説明する。

【0118】

[0141] フローチャート１７００のステップ１７０２において、各最適化データー・ストリームの最適化ストリーム・メタデーターを分析して、最適化ストリーム・メタデーターによって参照されている少なくとも１つのデーター・チャンクに対して、対応する少なくとも１つのデーター・チャンク識別子を決定する。例えば、一実施形態では、要求１３１８において特定された最適化データー・ストリーム毎に、データー・チャンク識別子バックアップ・モジュール１３１２は、ストリーム・コンテナ３０２から、対応する最適化ストリーム・メタデーターをストリーム・マップ・チャンクの形態で引き出すことができる。更に、データー・チャンク識別子バックアップ・モジュール１３１２は、引き出したストリーム・マップ・チャンクのメタデーターを分析して、チャンク・コンテナ３０４からのストリーム・マップ・チャンクのメタデーターによって参照されている全ての(any)データー・チャンク３２２に対してデーター・チャンク識別子を決定する。データー・チャンク識別子は、メタデーター（例えば、図４に示したメタデーター４００に含まれているデーター・チャンク識別子４０４）に含まれている。データー・チャンク識別子バックアップ・モジュール１３１２は、リダイレクション・テーブル（例えば、図９のリダイレクション・テーブル９００）を参照して、データー・チャンク識別子の内１つ以上のチャンク・オフセット値をマッピングし、１つ以上の参照されているデーター・チャンクがチャンク・コンテナ３０４内で移動させられた場合、チャンク・オフセット値を更新する。

【0119】

[0142] ステップ１７０４において、最適化データー・ストリーム毎の最適化ストリーム構造を、対応する少なくとも１つのデーター・チャンク識別子と共に、バックアップ・ストレージに格納する。例えば、データー・チャンク識別子バックアップ・モジュール１３１２は、最適化データー・ストリームの各々の最適化ストリーム構造を、ステップ１７０２において決定した、対応するデーター・チャンク識別子と共に、バックアップ・ストレージ１３０４に格納することができる（例えば、格納動作１３２０を用いて）。チャンク識別子は、いかようにでも、最適化ストリーム構造と関連付けて格納することができ、バックアップ・ストレージ１３０４内において対応する最適化ストリーム構造の外部または内部に格納することを含む。

【0120】

[0143] ステップ１７０６において、最適化データー・ストリームを収容する、チャンク・ストアの１つ以上のチャンク・コンテナを、バックアップ・ストレージに格納する。一実施形態では、データー・チャンク識別子バックアップ・モジュール１３１２は、最適化データー・ストリームのストリーム・マップ・チャンクがバックアップされるように、ストリーム・コンテナ３０２をバックアップ・ストレージ１３０４に格納することができる（例えば、格納動作１３２０を用いて）。更に、データー・チャンク識別子バックアップ・モジュール１３１２は、参照されているデーター・チャンクがバックアップされるように、最適化データー・ストリームのストリーム・マップ・チャンクによって参照されているいずれのデーター・チャンク３２２を格納するチャンク・コンテナ３０４でも、その１つ以上を格納することができる（例えば、格納動作１３２０を用いて）。一実施形態では、データー・チャンク識別子バックアップ・モジュール１３１２は、最適化データー・ストリームの全てのチャンクがバックアップされるように、チャンク・ストア１３３４全体をバックアップ・ストレージ１３０４に格納することができる。

【0121】

[0144] したがって、データー・チャンク識別子バックアップは、前述の最適化バックアップに似ているが、バックアップ時に「復元計画」(restore plan)を付与するために、全てのデーター・チャンク（データー・チャンク）のそれぞれのコンテナ・ファイル内における位置も格納する（データー・チャンク識別子によって）。データー・チャンク識別子バックアップの利点は、バックアップ・アプリケーション（例えば、データー・バックアップ・モジュール１３０２）がそのカタログに「復元計画」を格納し、選択的復元を含む、復元の状況毎にどの他のファイル（したがって、どのバックアップ媒体）が必要とされるのか前もって知ることができることである。前述の無最適化バックアップと同様、データー・チャンク識別子バックアップも比較的遅く複雑である可能性があり、データー・チャンク識別子バックアップ・モジュール１３１２によって実装されるバックアップＡＰＩを用いる場合もある。更に、データー・チャンク識別子バックアップは、チャンク・ストアのモジュール性(modularity)を破壊し、内部チャンク・ストアの実施態様(implementation)を露出する。

【0122】

[0145] したがって、最適化バックアップ、無最適化バックアップ、項目レベル・バックアップ、およびデーター・チャンク識別子バックアップは、各々、図１３のデーター・バックアップ・モジュール１３０２によって実現することができるバックアップの実施形態である。更に、データー・バックアップ・モジュール１３０２は、最適化バックアップ、無最適化バックアップ、項目レベル・バックアップ、およびデーター・チャンク識別子バックアップの内１つ以上の組み合わせであるバックアップの実施形態を実現することもできる。

【0123】

[0146] 例えば、一実施形態では、データー・バックアップ・モジュール１３０２は、最適化バックアップおよび無最適化バックアップの組み合わせを実現することができる。一実施形態では、ボリューム全体のバックアップを実行するときに、最適化バックアップを実行することを選択するとよい。１つの最適化データー・ストリームをバックアップしようとする場合、無最適化バックアップを実行するとよい。１つと全ての最適化データー・ストリームとの間の数の最適化データー・ストリームについては、最適化バックアップまたは無最適化バックアップを選択することができる。例えば、発見法に基づいて、最適化バックアップまたは無最適化バックアップを切り替えても良い。

【0124】

[0147] 例えば、一実施形態では、データー・バックアップ・モジュール１３０２は、図１８に示すプロセスにしたがって最適化データー・ストリームのバックアップを実行するように構成することができる。図１８は、一実施形態例にしたがって、発見法に基づいてバックアップ技法を選択し実行するプロセスを表すフローチャート１８００を示す。図１８について、以下のように説明する。

【0125】

[0148] フローチャート１８００のステップ１８０２において、発見法に基づいてバックアップ技法を選択する。例えば、図１３に示したように、データー・バックアップ・モジュール１３０２は任意に発見法モジュール１３１４を含むことができる。発見法モジュール１３１４は、最適化データー・ストリームをバックアップするために用いるバックアップ技法を選択するために用いられる発見法を決定するように構成されている。

【0126】

[0149] ステップ１８０４において、バックアップ技法を実行して、複数の最適化データー・ストリームをバックアップ・ストレージにバックアップする。発見法モジュール１３１４によって決定された発見法に基づいて、最適化ファイル・バックアップ・モジュール１３０６またはリハイドレーション・バックアップ・モジュール１３０８から１つを選択して、最適化データー・ストリームをバックアップすることができる（例えば、先に図１４および図１５に関してそれぞれ説明したように）。例えば、一実施形態では、発見法モジュール１３１４は、最適化データー・ストリームをバックアップするために選択された最適化ファイル・バックアップ・モジュール１３０６またはリハイドレーション・バックアップ・モジュール１３０８の内１つに、イネーブル信号を供給することができる。このイネーブル信号は、最適化ファイル・バックアップ・モジュール１３０６またはリハイドレーション・バックアップ・モジュール１３０８の内１つが、その対応するバックアップ技法にしたがって最適化データー・ストリームをバックアップすることを可能にする。

【0127】

[0150] 例えば、一実施形態では、発見法モジュール１３１４は、「除外モード」(exclude mode)および「含有モード」(include mode)に基づく比較的単純な発見法を実装することができる。「除外モード」によれば、ユーザーはチャンク・ストア・ボリュームを選択することができ、一部のフォルダー／ファイルをバックアップから除外することができる。したがって、発見法モジュール１３１４は、除外モードにしたがって最適データー・ストリームがバックアップのために選択されたと判断することができる。このような場合、除外モードが決定された結果、最適化データー・ストリーム・バックアップ技法が発見法モジュール１３１４によって選択される。これは、「除外モード」が通例範囲内のチャンク・ストア・ボリュームの殆どを有するからである。したがって、コンテナ・ファイルが、ユーザーによって選択されたもの以外の最適化データー・ストリームによって参照されているチャンクを含むことがあっても、選択されたデーター・ストリーム（その最適化形態で）に加えて全てのチャンク・ストア・コンテナ・ファイルをバックアップすることが、より良いトレードオフとなる。

【0128】

[0151] 「含有モード」によれば、ユーザーは比較的少ないフォルダー／ファイルをバックアップのために選択することができる。したがって、発見法モジュール１３１４は、含有モードにしたがって最適化データー・ストリームがバックアップのために選択されたと判断することができる。このような場合、含有モードが決定された結果、無最適化データー・ストリーム・バックアップ技法が発見法モジュール１３１４によって選択される。これは、「含有モード」が通例範囲内のチャンク・ストア・ボリュームの比較的小さな部分を有するからである。したがって、選択されたファイルだけをその無最適化形態でバックアップすることが、より良いトレードオフとなる。このような場合、チャンク・ストア・コンテナ・ファイルをバックアップする必要はない。

【0129】

[0152] 他の実施形態では、発見法モジュール１３１４が比較的高度な発見法を実装することもできる。バックアップ技法におけるトレードオフは、バックアップ範囲内のファイルの最適化サイズと論理サイズとの間の差(delta)に基づくとよい。記憶空間の無駄は、バックアップ範囲に含まれない最適化データー・ストリームのみによって参照されているチャンクによって消費されるチャンク・ストア・コンテナ・ファイル内における記憶空間であると判断することができる。したがって、発見法モジュール１３１４は、チャンク・ストア・ボリュームにおけるファイル・サイズに基づいて、更にチャンク・ストア統計に基づいて、無駄な記憶空間の量を決定（例えば、計算）することができる。一実施形態では、どの位のチャンクが所与の１群のデーター・ストリームによって参照されているか精度高く報告するようにチャンク・ストアが構成されていない場合、何らかの仮定を行うとよい。チャンク・ストアが、指定された１群の最適化データー・ストリームによって参照されているチャンク数を報告することができる場合、発見法モジュール１３１４は、全てのチャンクによって埋められた空間から、バックアップのために指定された最適化データー・ストリームによって参照されているチャンクによって埋められた空間を差し引いた量として、無駄な記憶空間量を決定することができる。無駄な記憶空間量（例えば、全記憶空間に対する）に基づいて、発見法モジュール１３１４は、最適バックアップまたは無最適バックアップを選択することができる。

【0130】

[0153] 例えば、図１３を参照すると、一実施形態では、発見法モジュール１３１４は、報告１３１８において特定された複数の最適化データー・ストリームのいずれのストリーム・マップ・チャンク・メタデーターによっても参照されていないデーター・チャンク３２２によって消費されたチャンク・ストア１３３４における空間量を判定することができる。発見法モジュール１３１４は、チャンク・ストア１３３４において参照されていないデーター・チャンクによって消費されたと判定された空間量が所定の閾値（例えば、チャンク・ストア１３３４の総記憶空間の５０％またはその他のパーセント）未満である場合、バックアップ技法を最適化データー・ストリーム・バックアップ技法にする選択を行うことができる。発見法モジュール１３１４は、参照されていないデーター・チャンクによって消費されたと判定されたチャンク・ストア１３３４の量が所定の閾値よりも大きい場合、バックアップ技法を無最適化データー・ストリーム・バックアップ技法にする選択を行うことができる。

【0131】

[0154] 一例では、発見法モジュール１３１４は、以下の分析を実行してバックアップ技法を設定することができる。バックアップ範囲が１つ以上の名称空間ルート(namespace roots)を含み、名称空間ルートがサブフォルダーを反復的に含むフォルダーである場合、以下の発見法パラメータを定義することができる。

【0132】

範囲＝バックアップ範囲における全てのファイルであり、バックアップのために選択されたフォルダーの下にある全てのファイルを意味する。
Ａ＝その範囲にある全てのファイルの論理サイズであり、ファイルの論理サイズとは、そのファイルが重複排除される前におけるファイルのサイズである（Ａは、範囲内にあるファイルの全ての論理サイズの総和である）。

【0133】

Ｂ＝その範囲内にある全てのファイルのディスク上のサイズであり、ファイルのディスク上のサイズとは、そのファイルの重複排除の後に最適化ファイルがディスク上で埋める実際のサイズである。

【0134】

Ｃ＝チャンク・ストアのサイズであり、全てのチャンク・ストア・コンテナ・ファイルのサイズの総和である。
これらの定義を検討し、バックアップ・アプリケーションが最適化バックアップを用いる場合、バックアップ媒体上における総バックアップ・サイズはＢ＋Ｃとなる。バックアップ・アプリケーションが無最適化バックアップを用いる場合、バックアップ・メディア上における総バックアップ・サイズはＡとなる。

【0135】

[0155] したがって、発見法モジュール１３１４は、バックアップ・ファイル範囲を決定した後、最適または無最適バックアップ間の選択において決定する際に役立てるために、ＡおよびＢ＋Ｃの値を計算することができる。Ａ＞Ｂ＋Ｃである場合、最適化バックアップの方が占める空間が少ないので、選択するとよい。そうでなければ、Ａ≦Ｂ＋Ｃである場合、無最適化バックアップの方が占める空間が少ないので、選択するとよい。

【0136】

Ｅ．データー最適化復元の実施形態例
[0156] 図１３を参照すると、最適化データー・ストリームが何らかの原因で転化(corrupt)したときというような、何らかの時点において、バックアップ・ストレージ１３０４にバックアップした最適化データー・ストリームを主ストレージに復元する(restore)ことが望まれる場合がある。例えば、最適化データー・ストリームの１つ以上のチャンク（例えば、ストリーム・マップ・チャンクおよび／またはデーター・チャンク）がチャンク・ストア１３３４において転化していたということがあり得る。このような場合、最適化データー・ストリームのバックアップ・バージョンを、バックアップ・ストレージ１３０４から非最適化形態で復元することが望まれる場合がある。現在使用中のバックアップ技法は、ファイル・システムの名称空間全体をバックアップする可能性が高く、最適化ファイルおよびチャンク・ストア・コンテナ・ファイルを含む。更に、多くの現在使用中のバックアップ技法は、テープ媒体のようなシーケンシャル・バックアップ媒体を、バックアップ・ストレージのために未だに用いている。したがって、データー・ストリームを復元する技法が、異なるバックアップ媒体の種類およびバックアップ・フォーマットを考慮に入れることができることが望ましい。

【0137】

[0157] この副章では、最適化データー・ストリームをバックアップ・ストレージから復元する実施形態について説明する。実施形態は、レイテンシーおよびディスクＩ／Ｏ動作を低減するように、最適化データー・ストリーム（例えば、ファイル）を復元することを可能にする。一実施形態によれば、バックアップしたチャンク・コンテナの別の不要な部分を復元するのではなく、特定のデーター・ストリームに対するチャンクを、バックアップ・ストレージから復元することが可能になる。実施形態は、最適化バックアップ全体からのデーター・ストリームの選択的復元を可能にし、データー最適化メタデーターを理解する必要がなく、更にバックアップ媒体の種類やバックアップ・フォーマットについて仮定を行う必要もない。

【0138】

[0158] 実施形態では、データー最適化システムにおけるデーター・ストリームの復元は、種々の方法で実行することができる。例えば、図１９は、一実施形態例にしたがって、データー最適化システムにおいてバックアップ・データーの復元を実行するフローチャート１９００を示す。フローチャート１９００は、一実施形態では、図１のチャンク・ストア・インターフェース１１６によって実行することができる。例示の目的に限って、図２０に関してフローチャート１９００を説明する。図２０は、一実施形態例によるデーター復元システム２０００のブロック図を示す。尚、一実施形態では、図１３のデーター・バックアップ・システム１３００およびデーター復元システム２０００を共通のシステムにおいて（例えば、共通のバックアップ／復元アプリケーション等）実装してもよく、または別々に実装してもよいことを注記しておく。図２０に示すように、データー復元システム２０００は、データー復元モジュール２００２とバックアップ・ストレージ２０３４とを含む。バックアップ・ストレージ２０３４は、ストリーム・コンテナ３０２と１つ以上のチャンク・コンテナ３０４（例えば、チャンク・コンテナ３０４ａおよび３０４ｂ）を格納する。更に、データー復元モジュール２００２は、ファイル・リコンストラクター(file reconstructor)２００４と、復元アプリケーション２００６とを含む。フローチャート１９００は、一実施形態では、ファイル・リコンストラクター２００４によって実行することができる。フローチャート１９００に関する論述に基づいて、関連技術（１つまたは複数）の当業者には更に他の構造的および動作的実施形態も明白であろう。フローチャート１９００およびデーター復元モジュール２００２について、以下のように説明する。

【0139】

[0159] 図２０を参照すると、復元アプリケーション２００６は、カタログ（またはその他の何らかのメカニズム）を用いてバックアップ・ストレージにおいてファイルの位置を突き止め、突き止めたファイルをストレージに書き込むことによって、ファイルをバックアップ・ストレージから復元するように構成されている従来の復元アプリケーションであってよい。復元アプリケーション２００６は、復元機能のみを含むのでもよく、またはバックアップ機能も含んでもよい（例えば、バックアップ／復元アプリケーションであってもよい）。データー最適化システムの場合、ファイル復元要求に応答して復元アプリケーション２００６によってストレージに書き込まれるファイルは、最適ストリーム構造であり、ストリーム・マップ・チャンクへの参照を収容している。

【0140】

[0160] 例えば、復元アプリケーション２００６は、データー・ストリームをバックアップ・ストレージ２０３４から引き出す要求２０１０を受けることができる。要求２０１０は、ファイル名称によってデーター・ストリームを特定することができる。図２０に示すように、復元アプリケーション２００６は、最適化ストリーム構造２０３８（例えば、ストリーム・メタデーター・スタブ）をバックアップ・ストレージ２０３４から引き出すことができる。最適化ストリーム構造２０３８は、要求２０１０の要求されたファイル・ストリームに対応する。しかしながら、最適化ストリーム構造２０３８は要求２０１０において要求されたデーター・ストリームに対するリパース・ポイントであるので（例えば、最適化ストリーム構造２０３８はファイル・データーを含まない）、復元アプリケーション２００６は、最適化ストリーム構造２０３８に対応するデーター・ストリームを再現するために、ファイル・リコンストラクター２００４にアクセスするように構成されている。例えば、ファイル・リコンストラクター２００４は、図１９におけるフローチャート１９００にしたがって、次のようにデーター・ストリームを再現するように構成することができる。

【0141】

[0161] フローチャート１９００のステップ１９０２において、ストレージ内にあるチャンク・ストアからデーター・ストリームを引き出す要求を受ける。この要求は、このデーター・ストリームに対応する最適化ストリーム・メタデーターの識別子を含む。例えば、図２０に示すように、ファイル・リコンストラクター２００４は、要求２０３６を復元アプリケーション２００６から受けるのでもよい。要求２０３６は、ファイル・リコンストラクター２００４が最適化データー構造２０３８に対応するデーター・ストリームを再現する要求である。要求２０３６は、最適化ストリーム構造２０３８を含む。最適化ストリーム構造２０３８は、ストリーム・マップ・インディケーターのような、最適化ストリーム・メタデーター・インディケーターを含み、対応する最適化データー・ストリームに対応する最適化ストリーム・メタデーター（例えば、ストリーム・マップ・チャンク）の位置を突き止めるために用いることができる。本明細書のいずれかの場所で説明したように、最適化ストリーム・メタデーターは、ファイル・リコンストラクター２００４がデーター・ストリームを組み立て直すために用いることができるデーター・チャンクへの参照を含む。

【0142】

[0162] ファイル・リコンストラクター２００４は、ハードウェア、ソフトウェア、またはこれらのあらゆる組み合わせで実現することができる。例えば、一実施形態では、ファイル・リコンストラクター２００４は、バックアップ・ストレージから復元された最適化データー構造に基づいてデーター・ストリームをリハイドレートするように構成されているアプリケーション・プログラミング・インターフェース（ＡＰＩ）とすることができる。一実施形態では、ファイル・リコンストラクター２００４のＡＰＩは、以下の形態で要求２０３６を受けるように構成することができる。

【0143】

再現ファイル（復元−状態／コンテキスト［内］、ファイル−名称［内］、コールバック−インターフェース［内］）
ここで、要求パラメータを次のように定義する。

【0144】

「復元−状態／コンテキスト」は、多数のコール間で内部状態を維持するために用いられるラベルである。
「ファイル−名称」は、最適化ストリーム構造２０３８のファイル名称である。

【0145】

「コールバック−インターフェース」は、ファイル・リコンストラクター２００４が復元アプリケーション２００６に対してコールバックを行うために用いる識別子である。
他の実施形態では、ファイル・リコンストラクター２００４は、ＡＰＩ以外の方法で構成することもできる。例示の目的に限って、ファイル・リコンストラクター２００４のＡＰＩの実施形態について以下で引用することがあるが、この実施形態は限定することを意図するのではない。

【0146】

[0163] ステップ１９０４において、復元アプリケーションに対する第１のコールを、最適化ストリーム・メタデーター識別子に基づいて生成する。この第１のコールは、最適化ストリーム・メタデーター識別子によって特定された最適化ストリーム・メタデーターを格納するストレージにおける第１チャンク・コンテナにファイル名称を指定し、更に第１チャンク・コンテナにおける最適ストリーム・メタデーターにオフセットを指定する。図２０に示すように、一実施形態では、ファイル・リコンストラクター２００４は、コールバック・モジュール２００８を含むことができる。コールバック・モジュール２００８は、コールを生成するように構成されており、復元アプリケーション２００６にコールバックするためにファイル・リコンストラクター２００４によって用いられる（例えば、ファイル・リコンストラクター２００４のＡＰＩによって用いられる）。コールバック・モジュール２００８は、復元アプリケーション２００６に対してコールバックを行い（例えば、復元アプリケーション２００６によって供給される「コールバック・インターフェース」にしたがって）、コールにおいて特定されたチャンクをバックアップ・ストレージ２０３４から復元することができる。ファイル・リコンストラクター２００４は、復元されたチャンクを受け取り、これらを用いて、特定されたデーター・ストリームを組み立て直す。例えば、一実施形態では、コールバック・モジュール２００８は、以下のコールバック構造にしたがってコールを実施することができる。

【0147】

リード（[in]復元−状態／コンテキスト、[in]ファイル名称、[in]オフセット、[in]サイズ、[out]バッファー）
ここで、コール・パラメータを次のように定義する。
「復元−状態／コンテキスト」は、多数のコール間で内部状態を維持するために用いられるラベルである。
「ファイル名称」は、バックアップ・ストレージ２０３４において、要求されたチャンクを格納するコンテナのファイル名称である。
「オフセット」は、要求されたチャンクに対するコンテナにおけるオフセットである。
「サイズ」は、要求されたチャンクのコンテナ内におけるサイズである。
「バッファー」は、ファイル・リコンストラクター２００４が、復元されたチャンクにアクセスするために、復元されたチャンクを復元アプリケーション２００６が格納することができる場所（例えば、メモリーまたは他のストレージにおけるバッファー）である。

【0148】

他の実施形態では、コールは他のフォーマットまたは構造を有することもできる。復元アプリケーション２００６は、特定のバックアップされたファイルにおいて与えられるオフセットから、バックアップ・ストレージ２３０４からチャンクを復元することができることによって、選択的復元が行えるように構成されている。例えば、復元アプリケーション２００６は、バックアップ・カタログを用いて、受けたコールの｛ファイル−名称、ファイル−オフセット｝を｛バックアップ−媒体、メディアにおけるオフセット｝にマッピングする（ファイルからバックアップ媒体にマッピングする）ことができる。

【0149】

[0164] 最適化ストリーム・メタデーターをストリーム・マップ・チャンクの形態で格納する実施形態では、コールバック・モジュール２００８によって生成された最初のコール（ステップ１０９４にしたがって）は、最適化ストリーム構造２０３８内におけるストリーム・マップ・チャンク識別子によって特定されるストリーム・マップ・チャンクを求める、復元アプリケーション２００６に対する要求である。一実施形態では、コールバック・モジュール２００８は、前述のコールバック構造にしたがって最初のコールを生成することができる。コールバック・モジュール２００８は、チャンク・コンテナ識別子の値を「ファイル名称」パラメータとして含むように、そしてチャンク・オフセット値の値を「オフセット」パラメータとして含むように、最初のコールを生成することができる。「サイズ」パラメータは任意である。何故なら、復元アプリケーション２００６は、バックアップ・ストレージ２０３４内において、要求されたチャンクのサイズを独立して決定することができる場合もあるからである（例えば、デフォルトのサイズで作られたチャンクのため、バックアップ・カタログに格納されているチャンク・サイズ情報にアクセスすることによって等）。図２０の例に関して、コールバック・モジュール２００８は、ストリーム・コンテナ３０２のファイル名称を「ファイル名称」パラメータとして含み、更にストリーム・コンテナ３０２内におけるストリーム・マップのオフセットの値を「オフセット」パラメータとして含むように、最初のコールを生成することができる。図２０に示すように、ファイル・リコンストラクター２００４は、コールバック・モジュール２００８によって生成された第１のコール２０１４を復元アプリケーション２００６に送信する。

【0150】

[0165] ステップ１９０６において、第１のコールに応答して最適化ストリーム・メタデーターを受け取る。一実施形態では、復元アプリケーション２００６は第１のコール２１０４を受け取り、バックアップ・ストレージ２０３４にアクセスして、第１のコール２０１４において特定されたストリーム・マップ・チャンクを入手する。復元アプリケーション２００６は、バックアップ・ストレージ２０３４内にあるストリーム・コンテナ３０２へのアクセス２０１６を生成し、ストリーム・コンテナ３０２において、第１のコール２１０４において示されているストリーム・マップ・チャンク２０１８を引き出す。復元アプリケーション２００６は、ストリーム・マップ・チャンク２０１８を、応答２０２０においてファイル・リコンストラクター２００４に送信する。

【0151】

[0166] ステップ１９０８において、最適化ストリーム・メタデーター内において参照されている少なくとも１つのデーター・チャンク識別子を判定する。一実施形態では、ファイル・リコンストラクター２００４は、応答２０２０において受け取ったストリーム・マップ・チャンク２０１８によって定められたストリーム・マップのメタデーター（例えば、図３のストリーム・マップ３１０のメタデーター３１４）を分析して、参照されているデーター・チャンクに対する１つ以上のデーター・チャンク識別子を求める。ストリーム・マップのメタデーターは、データー・チャンク識別子の形態で（例えば、図４のデーター・チャンク識別子４０４）、処理対象のデーター・ストリームに含まれるチャンク・コンテナ３０４ａおよび３０４ｂ内にあるデーター・チャンク３２２の各々へのポインタを含む。このように、ストリーム・マップ・チャンク２０１８に含まれる１つ以上のデーター・チャンク識別子を判定する。

【0152】

[0167] ステップ１９１０において、ストレージ内における少なくとも１つのチャンク・コンテナから少なくとも１つのデーター・チャンクを得るために、復元アプリケーションに対する少なくとも１つの追加のコールを、少なくとも１つのデーター・チャンク識別子に対応して生成する。一実施形態では、コールバック・モジュール２００８は、復元アプリケーション２００６に対して１つ以上の追加のコールを生成する。各コールは、ステップ１９０８において判定されたデーター・チャンク識別子に対応する、バックアップ・ストレージ２０３４における、データー・チャンク３２２を求める要求である。例えば、コールバック・モジュール２００８は、判定されたデーター・チャンク識別子（１つまたは複数）の内対応するデーター・チャンク識別子に基づいて、復元アプリケーション２００６に第２のコールを生成することができる。この第２のコールは、前述のコール構造を有することができ、または他の構造を有しても良い。第２のコールは、バックアップ・ストレージ２０３４内において、データー・チャンク識別子によって特定されたデーター・チャンク３２２を格納するチャンク・コンテナ３０４ａおよび３０４ｂの内１つのファイル名称（「ファイル名称」パラメータとして）を指定することができる。第２のコールは、ファイル名称によって特定された第１および第チャンク・コンテナ３０４ａおよび３０４ｂの内１つの中で特定されたデーター・チャンク３２２に対してオフセットを指定することができる（「オフセット」パラメータとして）。「サイズ」パラメータは任意である。何故なら、復元アプリケーション２００６は、特定されたデーター・チャンク３２２のサイズを独立して決定することができる場合もあるからである。図２０に示すように、ファイル・リコンストラクター２００４は、コールバック・モジュール２００８によって生成された第２のコール２０２２を復元アプリケーション２００６に送信する。

【0153】

[0168] ステップ１９１２において、少なくとも１つの追加のコールに応答して、少なくとも１つのデーター・チャンクを受け取る。一実施形態では、復元アプリケーション２００６は第２のコール２０２２を受け、バックアップ・ストレージ２０３４にアクセスして、第２のコール２０２２において特定されたデーター・チャンク３２２を得る。例えば、特定されたデーター・チャンクが第１チャンク・コンテナ３０４ａに格納されている場合、復元アプリケーション２００６はバックアップ・ストレージ２０３４における第１チャンク・コンテナ３０２ａへのアクセス２０２４を生成することができ、第１チャンク・コンテナ３０２ａにおいて、第２のコール２０２２において指示されているオフセットにおけるデーター・チャンク２０２６を引き出すことができる。復元アプリケーション２００６は、データー・チャンク２０２６を応答２０２８においてファイル・リコンストラクター２００４に送信する。

【0154】

[0169] 尚、ステップ１９０８において判定された追加のデーター・チャンク識別子毎に、ファイル・リコンストラクター２００４は、第２のコール２０２２と同様にして、対応するデーター・チャンク３２２をバックアップ・ストレージ２０３４から引き出すために、復元アプリケーション２００６への追加のコールを生成することができる。例えば、ファイル・リコンストラクター２００４から受けた第３のコールに応答して、復元アプリケーション２００６は、第３のコールにおいて特定されたデーター・チャンク３２２を得るために、バックアップ・ストレージ２０３４にアクセスすることができる。例えば、識別されたデーター・チャンクが第２チャンク・コンテナ３０４ｂに格納されている場合、復元アプリケーション２００６は、バックアップ・ストレージ２３０４における第２チャンク・コンテナ３０２ｂへのアクセス２０３０を生成することができ、そして第３のコールにおいて示されている、第２チャンク・コンテナ３０２ｂにおけるオフセットにおいて、データー・チャンク２０３２を引き出すことができる。復元アプリケーション２００６は、データー・チャンク２０３２を他の応答において、ファイル・リコンストラクター２００４に送信することができる。追加のデーター・チャンク識別子に対応する追加のコールも同様に処理して、ファイル・リコンストラクター２００４ために、バックアップ・ストレージ２０３４から追加のデーター・チャンクを引き出すことができる。

【0155】

[0170] ステップ１９１４において、最適化ストリーム・メタデーターおよび少なくとも１つのデーター・チャンクを組み合わせて、データー・ストリームを復元する。一実施形態では、ストリーム・マップ・チャンク２０１８、およびバックアップ・ストレージ２０３４から引き出された１つ以上のデーター・チャンク３２２（例えば、データー・チャンク２０２６および２０３２）は、データー・ストリームを復元するために組み合わせることができる。リハイドレーション・モジュール７０２について先に説明したのと同様に、ファイル・リコンストラクター２００４は、ストリーム・マップ・チャンク２０１８のストリーム・マップに含まれるデーター・ストリーム・オフセット４０２（図４）を用いて、引き出されたデーター・チャンク３２２を適正な順序に並べて、データー・ストリームを再生することができる。このデーター・ストリームは、ファイル・リコンストラクター２００４によってデーター・ストリーム２０１２として出力される。データー・ストリーム２０１２は、主ストレージに格納することができ、または主ストレージに格納するために復元アプリケーション２００６に出力することができ、あるいは特定のアプリケーションに合わせて所望通りに、それ以外で処理または配信することもできる。

【0156】

[0171] 例示の目的のために、図１９のフローチャート１９００および図２０のシステム２０００を参照して、最適化ファイルの復元例について説明する。最適化ファイルに対するストリーム・マップ・チャンクをストリーム・コンテナ３０２に格納し、この最適化ファイルは、チャンク・コンテナ３０４ａのデーター・チャンク３２２ａおよび３２２ｂと、チャンク・コンテナ３０４ｂのデーター・チャンク３２２ｅとを含む。この例では、ストリーム・コンテナ３０２はファイル名称ＳＣ５を有し、チャンク・コンテナ３０４ａはファイル名称ＣＣ３を有し、そしてチャンク・コンテナ３０４ｂはファイル名称ＣＣ７を有する。先に説明したように、復元アプリケーション２００６は、バックアップ・ストレージ２０３４からの最適化ファイルに合わせて、最適化ストリーム構造２０３８（例えば、ファイル名称「ＯＦＮ」を有する）を復元することができる。ステップ１９０２において、復元アプリケーション２００６は、最適化ファイルに対してファイル再構築プロセスを開始する要求２０３６をファイル・リコンストラクター２００４に対して生成することができる（例えば、ファイル再現（ＯＦＮ、コールバック）を用いて）。ステップ１９０４において、コールバック・モジュール２００８は第１コールを復元アプリケーション２００６に生成し、最適化フィアルに対して最適化ストリーム構造２０３８において特定されたストリーム・マップ・チャンクを要求する（例えば、コールバック−＞リード（内部状態、ＳＣ５、streammapchunkoffset、６４Ｋ、バッファー）。ここで、ストリーム・マップ・チャンクのサイズは６４Ｋである）。ステップ１９０６において、復元アプリケーション２００６は、ストリーム・マップ・チャンクをストリーム・コンテナ３０４から引き出し、このストリーム・マップ・チャンクを応答においてファイル・リコンストラクター２００４に供給する。ステップ１９０８において、ファイル・リコンストラクター２００４はこのストリーム・マップ・チャンクを分析して、所望のファイルに含まれるデーター・チャンク３２２ａ、３２２ｂ、および３２２ｅの３つのデーター・チャンク識別子を判定する。ステップ１９１０において、コールバック・モジュール２００８は、３つのコールを復元アプリケーション２００６に対して生成し、それぞれ、データー・チャンク３２２ａ、３２２ｂ、および３２２ｅを要求する（例えば、コールバック−＞リード（内部状態、ＣＣ３、datachunk322aoffset、６４K、バッファー）の第１のコール、コールバック−＞リード（内部状態、ＣＣ３、datachunk322boffset、６４Ｋ、バッファー）の第２のコール、およびコールバック−＞リード（内部状態、ＣＣ７、datachunk322coffset、６４Ｋ、バッファー）の第３のコール）。ステップ１９１２において、ファイル・リコンストラクター２００４は、３つのコールに応答して、復元アプリケーション２００６からデーター・チャンク３２２ａ、３２２ｂ、および３２２ｅを受け取る。ステップ１９１４において、ファイル・リコンストラクター２００４は、ストリーム・マップ・チャンクのストリーム・マップにしたがって、最適化ファイルを無最適化形態に組み立て直し、組み立てたファイルを格納する（例えば、組み立て直されたファイルをディスク上の最適化ストリーム構造２０３８に書き込む）。

【0157】

[0172] 尚、フローチャート１９００の例では、データー・ストリームを組み立て直す（ステップ１９１４において）ことを注記しておく。他の実施形態では、データー・ストリームを組み立て直す代わりに、最適化ストリーム構造２０３８をストレージ（主またはバックアップ）に最適化ファイルとして維持してもよく、データー・ストリームに含まれると判定されたデーター・チャンクを、チャンク・ストア（バックアップ・ストレージ２０３４におけるのではない）に格納してもよい。このように、最適化データー・ストリームは最適化された状態であり続け、チャンク・ストアにおけるデーター・チャンクを参照する。このような実施形態では、ストリーム・マップ・チャンク（ステップ１９０６において受け取られた）および１つ以上のデーター・チャンク（ステップ１９１２において受け取られた）をチャンク・ストアに格納する。

【0158】

[0173] 更に先に説明したように、チャンクは、断片化解消およびコンパクションのような、種々の機能のために、コンテナ内部で移動させられる場合がある。したがって、チャンクのこのような移動を追跡するリダイレクション・テーブルを維持するとよい。一実施形態では、ファイル・リコンストラクター２００４は、リダイレクション・テーブルにアクセスして、コンテナにおいて調節されたオフセットから引き出されたチャンクを有するようにコールを調節するように構成することもできる。例えば、図２１は、一実施形態による、再分配テーブル(redistribution table)９００にアクセスするコールバック・モジュールのブロック図を示す。コールバック・モジュール２００８は、バックアップ・ストレージにおけるコンテナ毎（例えば、図２０の例におけるストリーム・コンテナ３０２ならびにチャンク・コンテナ３０４ａおよび３０４ｂの各々）に、再分配テーブル９００にアクセスすることができる。このように、コールバック・モジュール２００８は、オフセットを古いままにしておくのではなく、コンテナにおいてオフセットを調節し、これに対してコールを生成することができる。

【0159】

[0174] 例えば、一実施形態では、コールバック・モジュール２００８は、図２２に示すフローチャート２２００を実行することができる。図２２は、一実施形態例にしたがって、チャンクに対して更新されたオフセットを得るために再分配テーブル(redistribution table)にアクセスするプロセスを表すフローチャート２２００を示す。フローチャート２２００について、以下のように説明する。

【0160】

[0175] フローチャート２２００のステップ２２０２において、データー・チャンクに対するデーター・チャンク識別子に含まれる第１オフセットを第２オフセットにマッピングするために、リダイレクション・テーブルにアクセスする。例えば、コールバック・モジュール２００８は、ストリーム・コンテナの再分配テーブルにアクセスし、ここからストリーム・マップ・チャンクを引き出す（例えば、図３のストリーム・コンテナ３０２におけるリダイレクション・テーブル３０８）。または、コールバック・モジュール２００８は、チャンク・コンテナの再分配にアクセスし、ここから、データー・チャンクを引き出す（例えば、図３のチャンク・コンテナ３０４における再分配テーブル３２０）。コールバック・モジュール２００８は、再分配テーブルにはいかようにもアクセスすることができ、この再分配テーブルを引き出すためのコールを生成することによることを含む。たとえば、コールを生成し、復元アプリケーション２００６に送信することができる。復元アプリケーション２００６は、再分配テーブルを収容するコンテナのファイル名称、およびコンテナにおける再分配テーブルに対するオフセットを定める。復元アプリケーション２００６は、再分配テーブルをバックアップ・ストレージ２０３４から引き出すことができ、そしてこの再分配テーブルをファイル・リコンストラクター２００４に供給することができる。このように、コールバック・モジュール２００８は、再分配テーブルにアクセスして、更新チャンク・オフセットを判定することができる。

【0161】

[0176] ステップ２２０４において、データー・チャンク識別子に基づいて、第２のコールを復元アプリケーションに対して生成する。この第２のコールは、データー・チャンク識別子に対応するデーター・チャンクを格納するストレージにおける第２チャンク・コンテナのファイル名称を指定し、更に第２チャンク・コンテナにおけるデーター・チャンクに対して第２のオフセットを指定する。例えば、データー・チャンクに対するコールに先立って、コールバック・モジュール２００８はこのデーター・チャンクに対する再分配テーブルにアクセスし、このデーター・チャンクに対して更新された第２のオフセットを判定することができる（再分配テーブルにおいて新たなオフセットがある場合）。コールバック・モジュール２００８は、復元アプリケーション２００６へのコールにおいて、この更新オフセット値を用いて、データー・チャンクを引き出すことができる。このコールは、バックアップ・ストレージ２０３４におけるチャンク・コンテナ３０４のファイル名称を指定することができ、そして再分配テーブルから得られる更新オフセット値を指定することができる。復元アプリケーション２００６は、このコールを受け、指示されたチャンク・コンテナおよび更新オフセットからデーター・チャンクを引き出し、引き出したデーター・チャンクを応答においてファイル・リコンストラクター２００４に供給することができる。

【0162】

[0177] 尚、フローチャート２２００の例では、データー・チャンク・オフセットを第１オフセットから第２オフセットにマッピングするために、チャンク・コンテナの再分配テーブルにアクセスすることを注記しておく。代わりに、ストリーム・マップ・チャンクを第１オフセットから第２オフセットにマッピングするためにストリーム・コンテナの再分配テーブルにアクセスするように、フローチャート２２００を修正してもよい。一実施形態では、コンテナのリダイレクション・テーブルは、チャンクに対するコールを生成するのに先立って、コールバック・モジュール２００８によって予め引き出すこともできる。

【0163】

[0178] 一実施形態では、バックアップ・ストレージ２３０４から引き出されるチャンクのサイズを、これらのチャンクを引き出す前に、判定する。例えば、一実施形態では、チャンク毎に、コールバック・モジュール２００８によって復元アプリケーション２００６に第１のコールを行って、引き出そうとするチャンクのサイズを判定することができ、コールバック・モジュール２００８によって復元アプリケーション２００６に第２のコールを行って、判定したサイズを有するチャンクをバックアップ・ストレージ２０３４から引き出すことができる。

【0164】

[0179] 例えば、一実施形態では、コールバック・モジュール２００８は、バックアップ・ストレージ２０３４において当該チャンクを格納しているコンテナのファイル名称、そのコンテナにおけるチャンクに対するオフセット、およびそのチャンクのヘッダー・サイズ（そして、任意に、そのチャンクを出力するバッファー）を指定する第１コールを生成することができる。例えば、チャンク・ヘッダー・サイズは、コールバック・モジュール２００８が知っている標準的なヘッダー・サイズにするとよい。第１のコールは、復元アプリケーション２００６に送信され、この第１のコールによって指示されるように、バックアップ・ストレージ２０３４からチャンク・ヘッダーを引き出すことができる。復元モジュール２００６は、チャンク・ヘッダー（例えば、ストリーム・マップ・チャンク・ヘッダーまたはデーター・チャンク・ヘッダー）を引き出すことができ、このチャンク・ヘッダーをコールバック・モジュール２００８に第１の応答において供給することができる。チャンク・ヘッダーは、チャンクのサイズを指示することができる。例えば、ストリーム・マップ・チャンク・ヘッダーは、ストリーム・マップ・チャンクのサイズを指示することができ、データー・チャンク・ヘッダーはデーター・チャンクのサイズを指示することができる。次いで、コールバック・モジュール２００８は、バックアップ・ストレージ２０３４内において当該チャンクを格納するコンテナのファイル名称、そのコンテナにおけるチャンクに対するオフセット、およびチャンク・ヘッダーから判定されたチャンクのサイズ（そして、任意に、そのチャンクを出力するバッファー）を指定する第２のコールを生成することができる。復元アプリケーション２００６は、指定されたオフセットにおいて、そして指示されたサイズを有するこのチャンク（例えば、ストリーム・マップ・チャンクまたはデーター・チャンク）を引き出すことができる。復元アプリケーション２００６は、引き出したチャンクをコールバック・モジュール２００８に第２の応答において供給することができる。このように、コールバック・モジュール２００８は復元アプリケーション２００６を用いてチャンク・サイズを判定することができ、２つのコールを用いてチャンクを引き出すことができる。第１のコールは、チャンク・サイズを判定するために用いることができ、第２のコールは、この判定されたサイズを有するチャンクを引き出すために用いることができる。

【0165】

[0180] 一実施形態では、コールバック・モジュール２００８は、ストリーム・マップ・チャンクにデーター・チャンク識別子が含まれている順序を含む、いずれの順序でもデーター・チャンクを引き出すためにコールを生成することができる。他の実施形態では、ファイル・リコンストラクター２００４は、コールバック・モジュール２００８がデーター・チャンクを一層効率的な順序で引き出すように、データー・チャンク識別子をソートする(sort)ように構成することができる。例えば、図２３は、一実施形態例によるファイル・リコンストラクター２００４のブロック図を示す。図２３に示すように、ファイル・リコンストラクター２００４は、識別子ソーター２３０２を含む。識別子ソーター２３０２は、チャンクを復元する順序をソートすることができる。例えば、一実施形態では、識別子ソーター２３０２は、図２４に示すフローチャート２４００を実行することができる。図２４は、一実施形態例にしたがってデーター・チャンク復元順序をソートするプロセスを表すフローチャートを示す。フローチャート２４００について、以下のように説明する。

【0166】

[0181] フローチャート２４００のステップ２４０２において、第１ソート・キーとして決定されたチャンク・コンテナと、第２キーとしてのチャンク・オフセットとに基づいて、複数のデーター・チャンク識別子をソートする。一実施形態では、識別子ソーター２３０２は、対応するデーター・チャンクを一層効率的に引き出すことを可能にするように、１つ以上のソート・キーにしたがって、ストリーム・マップ・チャンクに含まれるデーター・チャンク識別子をソートすることができる。例えば、データー・チャンク識別子は、第１ソートキーとしてコンテナ・ファイルに基づいて、そして第２ソート・キーとしてこのコンテナ・ファイル内部にあるチャンクに基づいてソートすることができる。他の実施形態では、データー・チャンク識別子は、追加のおよび／または代わりの判断基準あるいはキーを用いてソートすることもできる。

【0167】

[0182] ステップ２４０４において、ステップ２４０２によって定められた順序で、複数のデーター・チャンクに対応して、複数の追加のコールを復元アプリケーションに対して生成する。例えば、フローチャート１９００（図１９）のステップ１９１０の追加のコールを、ステップ２４０２の並び替えによって定められた順序で生成することができる。このように、バックアップ・ストレージ２０３４から一層効率的にデーター・チャンクを引き出すことができる。例えば、テープのような連続媒体にデーター・チャンクが格納されているシーケンスと一致する連続順序でデーター・チャンクを引き出すように、そして共通のバックアップ媒体（例えば、同じテープ、同じディスク等）に格納されているデーター・チャンクを、他のデーター・チャンクを復元する前に、順次復元するように、コールをソートすることができる。このような順序付けによって、バックアップ媒体の切り替え回数、およびバックアップ媒体内におけるシークの回数を減らすことができ、これは特にテープからの復元には望ましい。

【0168】

[0183] 復元アプリケーションが復元の順序に影響を及ぼすことができると、および／またはどのファイル範囲(file extents)を各コンテナ・ファイルから復元しようとしているのかについて予め通知を受けることができると、復元の実施形態の遂行(performance)を改善することができる。例えば、実施形態では、以下のコールバック関数の内１つ以上をファイル・リコンストラクターによって用いて、復元を改善することができる。

【0169】

[0184] 「ContainersRestoreOrder」は、全てのデーター・チャンク・コンテナのファイル名称を含むアレイを入力として受け取る復元順序コールバックである。ファイル名称は、ファイル再現に必要とされるコンテナ（少なくともファイル再現に必要なデーター・チャンクを格納するコンテナ）のファイル名称である。このコールバック関数の出力は、同じコンテナ・ファイル名称のリストを含むが、このリストがソートされている（例えば、並び替え直されている）アレイである。

【0170】

[0185] この復元順序コールバックを用いて、テープ・バックアップの場合、復元アプリケーションは、テープの順序に基づいて、バックアップ・テープおよびコンテナ・ファイルが格納されているテープ上のオフセットにしたがって、コンテナ・ファイル名称を並び替えることができる。このソート順序にしたがって復元プロセスを実行すると、テープ媒体の交換（例えば、ユーザーによる）およびテープ・シーク機能を削減する、または最小限に抑えることができる。テープ媒体の交換およびテープ・シークの回数を最小限に抑えることによって、テープ媒体の寿命が長くなり復元プロセスが高速化する。これらのコンテナ・ファイルを収容するテープが物理的にオフサイトに配置されており、そのテープをオフサイト現場から要求し輸送する必要がある場合、この能力は、データーの復元を完了するためにオフサイト現場から引き出す必要があるテープのリストを、復元アプリケーションが提供することを可能にする。この能力は、オフサイトからのテープ引き出しは何時間もまたは何日もかかる可能性があるのでデーター復元(data recovery)を著しく高速化することができ、媒体引き出しに伴うコストを削減することができる。

【0171】

[0186] 例えば、復元アプリケーションは、最初に、コンテナ・ファイルがどのバックアップ・テープに配置されているかに基づいて、コンテナ・ファイルを分類し、各テープ内において、コンテナ・ファイルをテープ上のそれらの位置（開始オフセット）に基づいてソートすることができる。次いで、ファイル・リコンストラクターは、バックアップ・アプリケーションによって指定されたコンテナの順序に基づいてデーター・チャンクを復元することができる。バックアップ・アプリケーションは、ソートされたリストにある最初のデーター・チャンク・コンテナ・ファイルに格納されているデーター・チャンクに対してリード・コールバック関数をコールし、次に、ソートされたリストにある２番目のデーター・チャンク・コンテナに格納されているデーター・チャンクに対してリード・コールバックをコールすることができ、以下同様に続けることができる。

【0172】

[0187] 復元を順序付けることから効果が得られないファイル・バックアップまたは他のバックアップ技法の場合、復元アプリケーションは、データー・チャンク・コンテナ・リストをソートすることを避け、コンテナの復元順序を任意のままにしておくことを選択してもよい。

【0173】

[0188] 「ContainerRestorePlan」は、１つのデーター・チャンク・コンテナ・ファイル名称と、データー・チャンクのオフセットおよびサイズのアレイとを入力として受け取るコンテナ復元計画コールバックである。このアレイは、その名前が付けられたコンテナに格納されておりファイルの再現に必要とされる全てのデーター・チャンクを含む。

【0174】

[0189] ファイル・リコンストラクターは、データー・チャンク・コンテナ毎に１回このコールバックをコールし、その後に、そのデーター・チャンク・コンテナに格納されているデーター・チャンクに対してリード・コールバックをコールする。ContainerRestorePlanコールバックは、復元アプリケーションによる使用のために、復元計画を作成する。復元アプリケーションは、このコールバックによって出力される復元計画を用いることができる。復元計画は、バックアップ媒体から読み出す必要があるデーター・チャンク・コンテナ・ファイルのファイル範囲を示す。復元アプリケーションは、バックアップ媒体からデーター・チャンクを読み出し、バッチ処理、キャッシュ処理、および先読みというような技法を利用するそれ自体の最適化のために、この復元計画を用いることができる。

【0175】

[0190] このコールバックを処理することは任意である。復元アプリケーションがバックアップ媒体からの読み取りを最適化することができない場合またはその必要がない場合、復元アプリケーションはこの計画を無視し、最適化せずにリード・コールバックを処理することができる。

【0176】

[0191] 「CreateChunksRestorePlan」は、構造のアレイを入力として受け取るデーター・チャンク復元計画コールバックである。このアレイにおける各構造は、ファイルを再現するために必要とされる１つのデーター・チャンクに対応する。各構造は、以下のメンバーを含むことができる。コンテナ・ファイル名称（どこにデーター・チャンクが格納されているかを示す）、コンテナ・ファイルにおけるチャンク・オフセット、およびチャンク・サイズ。このコールバックの出力は、同じ構造のアレイであるが、復元を実行すべき順序にソートされている。

【0177】

[0192] データー・チャンク復元計画コールバックは、復元順序コールバックおよびコンテナ復元計画コールバックの代わりである。データー・チャンク復元計画コールバックは、少なくとも２つの目的を果たす。第１に、このコールバックは、復元アプリケーションに、どのデーター・チャンクを復元すべきかを示す。コールバックへの入力に基づいて、復元アプリケーションは、どのバックアップ媒体が各チャンクを有するか判断することができ、そして対応する媒体上のどこに各チャンクが配置されているか判断することができる。バックアップ媒体からデーターを読み出すための同じ最適化技法を用いることもできる。第２に、コールバックの出力に基づいて、復元アプリケーションは、どの順序でチャンクを復元するか、ファイル・リコンストラクターに命令することができる。

【0178】

[0193] 例えば、テープ・バックアップの場合、特定のデーター・チャンク・コンテナ・ファイルが多数のテープ上に格納されている可能性がある。１つのファイルを再現するために、同じコンテナ・ファイル上に位置するが２つの異なるテープ上にバックアップされている２つのデーター・チャンクを必要とする場合もある。何故なら、コンテナ・ファイルがテープ間で分割されているからである。復元アプリケーションがチャンク・データーの粒度で復元順序を指令する機会を有する場合、復元アプリケーションはコンテナ・ファイルが多数のテープ間で分割されている場合であっても、データー・チャンクをテープ順に分類しソートすることができる。

【0179】

[0194] ファイル・リコンストラクターは、ファイルの復元プロセス毎に１回データー・チャンク復元計画コールバックをコールすることができる。ファイル・リコンストラクターは、どのデーター・チャンクが必要とされるか、そしてデーター・チャンク・コンテナ・ファイルのどこにそのデーター・チャンクが位置するか分かった時点で、コールバックをコールするのでもよい。ファイル・リコンストラクターは、このコールバックの出力を用いて、データー・チャンク復元の順序を規定することができる。ファイル・リコンストラクターは、出力構造リストによって指令されるデーター・チャンクの順序に基づいて、リード・コールバック関数をコールすることができる。

【0180】

[0195] データー・チャンク復元計画コールバックの処理は任意である。復元アプリケーションがバックアップ媒体からの読み取りを最適化し復元の順序を指令することができない場合、またはその必要がない場合、このコールバックを無視する、または実行しないことができる。次いで、ファイル・リコンストラクターは、先に説明したそれ自体のロジックを用いて、または何らかの任意の順序で、データー・チャンクを復元することができる。

【0181】

ＩＩＩ．計算デバイスの実施形態例
[0196] データー重複解除モジュール１０４、維持モジュール１０６、データー・ストリームＡＰＩ１１０、チャンク維持ＡＰＩ１１２、データー・アクセスＡＰＩ１１４、チャンク・ストア・インターフェース１１６、データー・ストリーム・パーザー４０２、データー・チャンク記憶マネージャー４０４、メタデーター生成器４０６、ストリーム・マップ生成器４０８、リハイドレーション・モジュール７０２、データー・ストリーム・アセンブラー１１０２、生成チェッカー１１０６、データー・チャンク・リトリバー１１０８、データー・バックアップ・モジュール１３０２、最適化ファイル・バックアップ・モジュール１３０６、リハイドレーション・バックアップ・モジュール１３０８、項目レベル・バックアップ・モジュール１３１０、データー・チャンク識別子バックアップ・モジュール１３１２、発見法モジュール１３１４、データー復元モジュール２００２、ファイル・リコンストラクター２００４、復元アプリケーション２００６、コールバック・モジュール２００８、および識別子ソーター２３０２は、ハードウェア、ソフトウェア、ファームウェア、またはそのいずれの組み合わせでも実現することができる。例えば、 データー重複解除モジュール１０４、維持モジュール１０６、データー・ストリームＡＰＩ１１０、チャンク維持ＡＰＩ１１２、データー・アクセスＡＰＩ１１４、チャンク・ストア・インターフェース１１６、データー・ストリーム・パーザー４０２、データー・チャンク記憶マネージャー４０４、メタデーター生成器４０６、ストリーム・マップ生成器４０８、リハイドレーション・モジュール７０２、データー・ストリーム・アセンブラー１１０２、生成チェッカー１１０６、データー・チャンク・リトリバー１１０８、データー・バックアップ・モジュール１３０２、最適化ファイル・バックアップ・モジュール１３０６、リハイドレーション・バックアップ・モジュール１３０８、項目レベル・バックアップ・モジュール１３１０、データー・チャンク識別子バックアップ・モジュール１３１２、発見法モジュール１３１４、データー復元モジュール２００２、ファイル・リコンストラクター２００４、復元アプリケーション２００６、コールバック・モジュール２００８、および／または識別子ソーター２３０２は、１つ以上のプロセッサーにおいて実行するように構成されたコンピューター・プログラムとして実現することができる。あるいは、 データー重複解除モジュール１０４、維持モジュール１０６、データー・ストリームＡＰＩ１１０、チャンク維持ＡＰＩ１１２、データー・アクセスＡＰＩ１１４、チャンク・ストア・インターフェース１１６、データー・ストリーム・パーザー４０２、データー・チャンク記憶マネージャー４０４、メタデーター生成器４０６、ストリーム・マップ生成器４０８、リハイドレーション・モジュール７０２、データー・ストリーム・アセンブラー１１０２、生成チェッカー１１０６、データー・チャンク・リトリバー１１０８、データー・バックアップ・モジュール１３０２、最適化ファイル・バックアップ・モジュール１３０６、リハイドレーション・バックアップ・モジュール１３０８、項目レベル・バックアップ・モジュール１３１０、データー・チャンク識別子バックアップ・モジュール１３１２、発見法モジュール１３１４、データー復元モジュール２００２、ファイル・リコンストラクター２００４、復元アプリケーション２００６、コールバック・モジュール２００８、および／または識別子ソーター２３０２は、ハードウェア・ロジック／電気回路として実現することもできる。

【0182】

[0197] 図２５は、本発明の実施形態を実現することができるコンピューター２５００の一実施態様例を示す。例えば、記憶システム１０２、および／またはそのいずれの部分も、コンピューター２５００と同様であり、コンピューター２５００の１つ以上の特徴および／または代わりの特徴を有する１つ以上のコンピューター・システムにおいて実現することができる。コンピューター２５００は、従来のパーソナル・コンピューター、移動体コンピューター、またはワークステージョンの形態とした汎用計算デバイスとすることができ、例えば、コンピューター２５００が特殊目的計算デバイスであってもよい。本明細書において提示するコンピューター２５００の説明は、例示の目的に限って行われるのであり、限定することを意図するのではない。本発明の実施形態は、関連技術（１つまたは複数）の当業者には周知である、更に他のタイプのコンピューター・システムにおいても実現することができる。

【0183】

[0198] 図２５に示すように、コンピューター２５００は、演算装置２５０２、システム・メモリー２５０４、およびシステム・メモリー２５０４から演算装置２５０２までを含む種々のシステム・コンポーネントを結合するバス２５０６を含む。バス２５０６は、メモリー・バスまたはメモリー・コントローラー、周辺バス、加速グラフィクス・ポート、および種々のバス・アーキテクチャーの内いずれかを用いるプロセッサー・バスまたはローカル・バスを含む、様々なタイプのバス構造の内いずれかの１つ以上を表す。システム・メモリー２５０４は、リード・オンリ・メモリー（ＲＯＭ）２５０８およびランダム・アクセス・メモリー（ＲＡＭ）２５１０を含む。基本入力／出力システム２５１２（ＢＩＯＳ）はＲＯＭ２５０８に格納されている。

【0184】

[0199] また、コンピューター２５００は以下のドライブの内１つ以上も有する。ハード・ディスクから読み取るおよびハード・ディスクに書き込むためのハード・ディスク・ドライブ２５１４、リムーバブル磁気ディスク２５１８から読み取るまたはリムーバブル磁気ディスク２５１８に書き込むための磁気ディスク・ドライブ２５１６、ならびにＣＤ ＲＯＭ、ＤＶＤ ＲＯＭ、または他の光媒体のようなリムーバブル光ディスク２５２２から読み取るおよびリムーバブル光ディスク２５２２に書き込むための光ディスク・ドライブ２５２０。ハード・ディスク・ドライブ２５１４、磁気ディスク・ドライブ２５１６、および光ディスク・ドライブ２５２０は、それぞれ、ハード・ディスク・ドライブ・インターフェース２５２４、磁気ディスク・ドライブ・インターフェース２５２６、および光ドライブ・インターフェース２５２８によって、バス２５０６に接続されている。これらのドライブおよびこれらに付随するコンピューター読み取り可能媒体は、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、およびコンピューターのためのその他のデーターの不揮発性記憶を行う。ハード・ディスク、リムーバブル磁気ディスク、およびリムーバブル光ディスクについて説明したが、フラッシュ・メモリー・カード、ディジタル・ビデオ・ディスク、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリ・メモリー（ＲＯＭ）等のような、他のタイプのコンピューター読み取り可能記憶媒体も、データーを格納するために用いることができる。

【0185】

[0200] ハード・ディスク、磁気ディスク、光ディスク、ＲＯＭ、またはＲＡＭ上には多数のプログラム・モジュールを格納することができる。これらのプログラムは、オペレーティング・システム２５３０、１つ以上のアプリケーション・プログラム２５３２、その他のプログラム・モジュール２５３４、およびプログラム・データー２５３６を含む。アプリケーション・プログラム２５３２またはプログラム・モジュール２５３４は、例えば、データー重複解除モジュール１０４、維持モジュール１０６、データー・ストリームＡＰＩ１１０、チャンク維持ＡＰＩ１１２、データー・アクセスＡＰＩ１１４、チャンク・ストア・インターフェース１１６、データー・ストリーム・パーザー４０２、データー・チャンク記憶マネージャー４０４、メタデーター生成器４０６、ストリーム・マップ生成器４０８、リハイドレーション・モジュール７０２、データー・ストリーム・アセンブラー１１０２、生成チェッカー１１０６、データー・チャンク・リトリバー１１０８、データー・バックアップ・モジュール１３０２、最適化ファイル・バックアップ・モジュール１３０６、リハイドレーション・バックアップ・モジュール１３０８、項目レベル・バックアップ・モジュール１３１０、データー・チャンク識別子バックアップ・モジュール１３１２、発見法モジュール１３１４、データー復元モジュール２００２、ファイル・リコンストラクター２００４、復元アプリケーション２００６、コールバック・モジュール２００８、識別子ソーター２３０２、フローチャート５００、フローチャート１０００、フローチャート１２００、フローチャート１４００、フローチャート１５００、フローチャート１６００、フローチャート１７００、フローチャート１８００、フローチャート１９００、フローチャート２２００、フローチャート２４００（フローチャート５００、１０００、１２００、１４００、１５００、１６００、１７００、１８００、１９００、２２００、および２４００のいずれのステップも含む）、および／または本明細書において説明した更に他の実施形態を実現するためのコンピューター・プログラム・ロジックを含むことができる。

【0186】

[0201] ユーザーは、キーボード２５３８およびポインティング・デバイス２５４０のような入力デバイスを通じて、コマンドおよび情報をコンピューター２５００に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲーム・パッド、衛星ディッシュ、スキャナー等が含まれる。これらおよびその他の入力デバイスは、多くの場合、バス２５０６に結合されているシリアル・ポート・インターフェース２５４２を介して演算装置２５０２に接続されているが、パラレル・ポート、ゲーム・ポート、またはユニバーサル・シリアル・バス（ＵＳＢ）のような他のインターフェースによって接続してもよい。

【0187】

[0202] ディスプレイ・デバイス２５４４も、ビデオ・アダプター２５４６のような、インターフェースを介してバス２５０６に接続されている。モニターに加えて、コンピューター２５００は、スピーカーおよびプリンターのような、他の周辺出力デバイス（図示せず）も含むことができる。

【0188】

[0203] コンピューター２５００は、アダプターまたはネットワーク・インターフェース２５５０、モデム２５５２、あるいはネットワークを通じて通信を確立するその他の手段を介してネットワーク２５４８（例えば、インターネット）に接続されている。モデム２５５２は、内蔵型でも外付け型でもよいが、シリアル・ポート・インターフェース２５４２を介してバス２５０６に接続されている。

【0189】

[0204] 本明細書において用いる場合、「コンピューター・プログラム媒体」、「コンピューター読み取り可能媒体」、および「コンピューター読み取り可能記憶媒体」という用語は、一般に、ハード・ディスク・ドライブ２５１４に付随するハード・ディスク、リムーバブル磁気ディスク２５１８、リムーバブル光ディスク２５２２、更には、フラッシュ・メモリー・カード、ディジタル・ビデオ・ディスク、ランダム・アクセス・メモリー（ＲＡＭ）、リード・オンリ・メモリー（ＲＯＭ）等のような媒体を指す。このようなコンピューター読み取り可能記憶媒体は、通信媒体と区別され、通信媒体とは重複しない。通信媒体は、通例、搬送波のような変調データー信号内に、コンピューター読み取り可能命令、データー構造、プログラム・モジュール、またはその他のデーターを具体化する。「変調データー信号」という用語は、信号内に情報をエンコードするように、その特性の１つ以上が設定または変更された信号を意味する。一例として、そして限定ではなく、通信媒体は、音響、ＲＦ、赤外線、およびその他のワイヤレス媒体というような、ワイヤレス媒体を含む。また、実施形態はこのような通信媒体も対象とする。

【0190】

[0205] 先に注記したように、コンピューター・プログラムおよびモジュール（アプリケーション・プログラム２５３２および他のプログラム・モジュール２５３４を含む）は、ハード・ディスク、磁気ディスク、光ディスク、ＲＯＭ、またはＲＡＭに格納することができる。このようなコンピューター・プログラムは、ネットワーク・インターフェース２５５０またはシリアル・ポート・インターフェース２５４２を介して受信することもできる。このようなコンピューター・プログラムは、アプリケーションによって実行またはロードされると、コンピューター２５００が、本明細書において論じた本発明の実施形態の特徴を実現することを可能にする。したがって、このようなコンピューター・プログラムは、コンピューター２５００のコントローラーを表す。

【0191】

[0206] また、本発明は、いずれかのコンピューター使用可能媒体上に格納されているソフトウェアを備えているコンピューター・プログラム生産物も対象とする。このようなソフトウェアは、１つ以上のデーター処理デバイスにおいて実行すると、データー処理デバイス（１つまたは複数）に、本明細書で記載したように動作させる。本発明の実施形態は、現在知られているまたは今後知られることになる、いずれのコンピューター使用可能媒体またはコンピューター読み取り可能記憶でも採用する。コンピューター読み取り可能媒体の例には、ＲＡＭ、フラッシュ・ストレージ（例えば、フラッシュ・メモリー）、ソリッド・ステート・ドライブ（ＳＳＤ）、ハード・ドライブ、フロッピ・ディスク、ＣＤ ＲＯＭ、ＤＶＤ ＲＯＭ、ジップ・ディスク、テープ、磁気記憶デバイス、光記憶デバイス、ＭＥＭ、ナノテクノロジーに基づく記憶デバイス等のような記憶デバイスを含むが、これらに限定されるのではない。

【0192】

ＶＩ．結論
[0207] 以上、本発明の種々の実施形態について説明したが、これらは一例として紹介したに過ぎず、限定ではないことは言うまでもない。関連技術（１つまたは複数）の当業者には、添付する特許請求の範囲に定められる本発明の主旨および範囲から逸脱することなく、形態および詳細において種々の変更も可能であることは理解されよう。したがって、本発明の広さ(breadth)および範囲は、以上で説明した実施形態例のいずれによっても限定されはせず、以下の特許請求の範囲およびその均等物のみにしたがって定義されることとする。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】

【図15】

【図16】

【図17】

【図18】

【図19】

【図20】

【図21】

【図22】

【図23】

【図24】

【図25】