重複排除されたバックアップは、なぜ復元時の容量より小さく見えるのですか？

エヴァ・ウォン

IceWhale author

エヴァ・ウォン は テクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

Why Do Deduplicated Backups Look Smaller Than Their Restore Footprint? - Zima Store Online

重複排除されたバックアップが小さく見えるのは、繰り返し現れるチャンクが一度だけ保存される一方、復元時には各論理ファイルと独立したコピーが再構成されるためです。

バックアップリポジトリ内では、10個の仮想マシンイメージが、同一のオペレーティングシステムブロックを数ギガバイト分共有している場合があります。これらを通常のファイルシステムに復元すると、復元先も互換性のある共有、スパース化、または圧縮に対応していない限り、10個のアドレス空間が再作成されます。したがって、リポジトリのサイズと復元に必要な容量は、選択した対象ファイルシステム上で、異なる割り当てルールとオーバーヘッドを持つ別々の表現を示しています。

重複排除はデータを一度だけ保存し、何度も参照する

バックアップソフトウェアはデータをチャンクに分割してフィンガープリントを作成し、まだ存在しないチャンクだけを保存します。マニフェストには、各ファイルと復元ポイントがどのチャンクで構成されるかが保持されます。リポジトリでは、1つの物理ペイロードと複数の参照によって、多数の論理コピーを表現できます。

バックアップの重複排除についての概要では、バックアップストレージから冗長なコピーを排除する仕組みが説明されています。節約量は、単純なファイル数ではなく、繰り返されるコンテンツによって決まります。

復元では、この対応関係が逆に処理されます。各ファイルのバイト列が、指定された復元先に順番どおり書き込まれます。対象がブロック共有に対応していない場合、繰り返しチャンクは再び別々のエクステントを消費します。データ削減はリポジトリの特性であり、すべての復元先で同じようにコンパクトな状態が維持される保証ではありません。

圧縮、スパース化、メタデータによって差は広がる

圧縮によって、コンテンツのエントロピーに応じて保存バイト数が削減されます。スパースファイルは長いゼロ領域を省略しますが、復元オプションによってはそのホールが実体化される場合があります。割り当て単位、チェックサム、拡張属性、ファイルシステムのメタデータによって、リポジトリの概要には含まれない復元先のオーバーヘッドが追加されます。

ストレージに関する説明では、スパースファイルと割り当てサイズが区別されています。ファイルは論理的には大きな長さを示しながら、物理ブロックの消費を少なくできるためです。この節約を維持するには、復元ツールがホールを明示的に保持する必要があります。

逆のケースもあります。圧縮に対応した復元先やコピーオンライトクローンでは、復元されたデータの論理サイズよりも実際のサイズが小さくなる場合があります。表現方法、保持対象、対象ファイルシステムのすべてが関係するため、リポジトリのバイト数から復元後のバイト数を導く普遍的な倍率は存在しません。

重複排除が主な原因ではない場合

重複していない単一ファイルが予想外に膨張する場合、この説明は当てはまりません。暗号化、圧縮済みメディア、データベースのエクスポート形式、またはシンプロビジョニングの変更が、別の主な原因になっている可能性があります。また、バックアップカタログが1つの範囲について固有データだけを表示している一方で、復元には選択した複数のスナップショットが含まれている場合もあります。

重複排除率に関する技術的な議論では、重複排除率を報告する際に論理サイズと物理サイズを区別する必要性が強調されています。範囲を示さない比率は、容量計画を誤らせる可能性があります。

復元されたファイルのハッシュや数が、選択したバックアップと異なる場合も、この仕組みは適用されません。その場合、問題は想定される膨張ではなく、選択内容または整合性にあります。バックアップのバイト数が小さいからといって、検証前の一時領域を過小評価してはいけません。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

比率を信頼せず、復元を測定する

代表的な復元対象を選び、論理的なソースバイト数、リポジトリ内の固有バイト数、圧縮後のバイト数、スパースエクステント、ファイル数、対象の割り当て単位を記録します。分離された復元先に、スパース保持オプションとデフォルトオプションの両方を使用して復元し、その後ハッシュと割り当て済み容量を検証します。

共有モデルストレージのストレージプランを使用し、テスト用の復元先が稼働中のサービスを圧迫しないようにします。実行結果を比較する間は、リポジトリの保持設定と対象の圧縮設定を固定します。

復旧容量は、重複排除されたリポジトリの数値ではなく、測定した割り当て済み出力と、論理データセットサイズに作業用の余裕を加えた値のうち、大きい方を基準に見積もります。スパース保持によって結果が変わる場合は、その依存関係を記録します。ファイルの識別情報や数が変わる場合は、容量の調整より先に復元の正確性を確認して問題を解決します。