「Data Domain:Data Domainの圧縮について
Résumé: ここでは、Data Domainで使用される圧縮タイプ、用語、および圧縮のその他の側面を説明するために、用語、トレードオフ、および測定について説明します。
Instructions
Data Domainの圧縮技術では、最先端の技術を使用して、バックアップ データに必要な物理スペースを削減します。そのため、圧縮レベルに関するテクノロジーと測定は複雑なトピックです。
この記事では、使用される圧縮タイプとData Domain環境での圧縮のその他の側面をより適切に説明するための、いくつかの用語、トレードオフ、および方法について説明します。
適用先:すべてのData Domainモデル
概要:
最終更新日: 2024年1月
- 圧縮は、より少ない物理スペースを使用してデータセットを保存することを目的としたデータ削減テクノロジーです。
- Data Domainシステム(DDOS)では、重複排除とローカル圧縮によってユーザー データが圧縮されます。重複排除、つまり「重複排除」は、冗長データ セグメントを識別し、一意のデータ セグメントのみを保存するために使用されます。
- ローカル圧縮では、次のような特定の圧縮アルゴリズムを使用して一意のデータ セグメントがさらに圧縮されます。
lz, gzfast, gzといった具合です。 - DDOSでの全体的なユーザー データ圧縮は、重複排除とローカル圧縮を組み合わせた作業です。DDOSは、「圧縮比」を使用してデータ圧縮の有効性を測定します。
- 一般的には、圧縮データの合計サイズまたは使用されている物理領域のサイズに対するユーザー データの合計サイズの比率です。
- Data Domainファイル システムは、「ログ構造」の重複排除ファイル システムです。
- ログ構造ファイル システムは、データをシステムに追加するのみで、削除だけでは物理スペースを解放できません。
- このようなファイル システムは、不要になったスペースを再利用するためにガベージ コレクションに依存しています。
- ログ構造化ファイル システムの特性と重複排除テクノロジーを組み合わせることで、DDOSでの圧縮のすべての側面を明確に理解することは困難です。
圧縮については、測定できる多くの側面があります。
この記事では、DDOS圧縮を理解するために役立つ詳細について説明します。
- 最初に、システム全体の圧縮効果について説明します。これにより、Data Domainシステムで実現される現実的な圧縮、ユーザー データの量、消費される物理スペースの量、およびそれらの比率がわかります。
- この記事では、この比率を「システムの実効圧縮比」と呼びます。
- DDOSは、インラインで重複排除を実行し、元のユーザー データ セグメント、重複排除後の一意のデータ セグメント、一意のデータ セグメントに対するローカル圧縮効果の統計を追跡します。
- これらのインライン圧縮統計情報は、インライン圧縮効果を測定するために使用されます。インライン圧縮統計は、書き込みごとに測定できます。また、DDOSはさまざまなレベルで統計情報を追跡します。ファイル
MTrees、およびシステム全体。
今後のリリースでは、すべてのコンテンツが正確であるという保証はありません。
5.0より前のリリースでは、システム全体で1つのみ mtree と用語 mtree 明示的に呼び出されません。
圧縮:システム全体の影響:
システム全体の全体的な圧縮効果は、実効圧縮比によって測定されます。実効圧縮比は、使用されている物理領域のサイズに対するユーザー データ サイズの割合です。これは、「filesys show compression" (FSC) CLI コマンドを使用します (対応する情報は UI でも使用できます)。サンプル出力: FSC を以下に示します。
# filesys show compression
From: 2023-12-31 03:00 To: 2024-01-07 03:00
Active Tier:
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:* 6439.6 113.4 - - 56.8x (98.2)
Written:
Last 7 days 135421.3 1782.0 35.1x 2.2x 76.0x (98.7)
Last 24 hrs 532.5 1.5 334.3x 1.1x 356.5x (99.7)
---------------- -------- --------- ----------- ---------- -------------
* Does not include the effects of pre-comp file deletes/truncates
since the last cleaning on 2024/01/05 11:34:13.
-
- システムの実効圧縮比は、CLI出力の結果セクションの行1で報告されます。上の行はハイライト表示されています。
- ユーザー データの合計サイズは「Pre-Comp」とラベル付けされます。
- 消費された物理スペースの合計(データとメタデータの両方)は、「Post-Comp」とラベル付けされます。
- 「Pre-Comp」番号と「Post-Comp」番号はどちらも実行時に読み取られます。
FSCシステム全体を暗黙的に同期し、2 つの数値を照会します。- これら 2 つの数値は、「
filesys show space" コマンドを使用します。 - システムの実効圧縮比 = Pre-Comp/Post-Comp
- これら 2 つの数値は、「
システムの実効圧縮比に影響を与える可能性のある操作がいくつかあります。
-
高速コピー
-
このとき
fastcopyは、アクティブなネームスペース内のファイル(スナップショットではない)から実行されます。ターゲット ファイルに追加の物理スペースが必要ないため、完全な重複排除となります。の効果fastcopyこれは、追加の物理スペースを消費することなく、ユーザーデータサイズが増加することです。これにより、システムの実効圧縮比が向上します。多くの場合fastcopiesこれを行うと、システムの実効圧縮比が人為的に高くなる可能性があります。
-
-
仮想合成
-
仮想合成バックアップでは、システムの実効圧縮比が高くなる傾向があります。これは、仮想合成が論理フル バックアップを作成しますが、変更されたデータまたは新しいデータのみをData Domainシステムに転送するためです。仮想合成がシステムの実効圧縮比に与える影響は、
fastcopyの詳細を確認してください。
-
-
上書き
-
上書きはより多くの物理領域を消費しますが、データセットの論理サイズは増加しないため、上書きによってシステムの実効圧縮比が低下します
-
-
スパース ファイルの保存
-
スパース ファイルには、論理サイズにカウントされる大きな「穴」が含まれますが、圧縮により物理スペースを消費しません。その結果、システムの実効圧縮比が高く見えることがあります。
-
-
小容量ファイルの保存
-
DDOSは、特定の内部メタデータについて、各ファイルに約1 KBのオーバーヘッドを追加します。システムに大量の小容量ファイル(サイズが1 KB未満または1桁のキロバイト)が格納されている場合、メタデータのオーバーヘッドによって実効圧縮比が低下します。
-
-
圧縮前または暗号化済みファイルの保存
-
圧縮と暗号化により、データ変更のレベルが増大し、重複排除の可能性が低下する可能性があります。このようなファイルは通常、重複排除がうまくできず、システムの実効圧縮比が低くなります。
-
-
削除
-
削除により、システムの論理サイズは減少しますが、ガベージ コレクションが実行されるまで、システムは対応する未使用スペースを取得しません。多くの削除されたファイルでは、ガベージ コレクション(GC)が実行されるまで圧縮比が低くなります。
-
-
ガベージ コレクション(GC)またはクリーニング
-
GCは、どのファイルにも表示されなくなったデータ セグメントによって消費された領域を再利用します。最近多くのファイルが削除された場合、GCは物理スペースの消費フットプリントを減らすことで、システム圧縮比を高めることがあります。
-
-
積極的にスナップショットを作成する
-
のスナップショットが
Mtreeが取得された場合、データセットの論理サイズは変更されません。ただし、スナップショットによってキャプチャされたすべてのファイルがスナップショットの作成後に削除された場合でも、スナップショットによって参照されるすべてのデータ セグメントをロックダウンする必要があります。GCは、スナップショットに必要なスペースを再利用できません。スナップショットが多数あると、システムの実効圧縮比が低く見える場合があります。ただし、スナップショットは便利なクラッシュ リカバリー機能です。躊躇せずにスナップショットを作成したり、必要に応じて適切なスナップショット スケジュールを設定したりしてください。
-
圧縮:インライン統計:
DDOSは、データがシステムに書き込まれると、インラインで重複排除を実行します。書き込みごとにインライン重複排除とローカル圧縮の効果を追跡し、ファイル レベルで統計情報を蓄積します。ファイルごとのインライン圧縮統計は、 mtree レベルとシステムレベルで。圧縮は、インライン統計の次の3つの数値に基づいて測定されます。
- 各書き込みの長さ:
raw_bytes The length of all unique segments:pre_lc_size- ローカルで圧縮された一意のセグメントの長さ:
post_lc_size
-
-
グローバル圧縮 (
g_comp)を作成します。- 等しい (
raw_bytes/pre_lc_size)、重複排除率を反映します。
- 等しい (
-
ローカル圧縮 (
l_comp)を作成します。-
等しい (
pre_lc_size/post_lc_size)であり、ローカル圧縮アルゴリズムの効果を反映します
-
-
累積インライン圧縮統計は、DDOSのファイル メタデータの一部であり、ファイルに格納されます inodeの詳細を確認してください。DDOSには、3つのレベルすべてでインライン圧縮をチェックするためのツールが用意されています。ファイル MTree、およびシステム全体です。これらについては、以降のセクションで詳しく説明します。
ファイル圧縮:
-
- ファイルの圧縮は「
filesys show compression <path>" CLIコマンド。ファイルに格納されている累積圧縮統計をレポートします。inodeの詳細を確認してください。 - ディレクトリーを指定すると、そのディレクトリーの下にあるすべてのファイルのインライン圧縮統計が合計され、レポートされます。
- CLI出力で、
raw_bytesは「Original Bytes」とラベル付けされます。pre_lc_sizeは「グローバル圧縮」とラベル付けされます。post_lc_bytesは「ローカル圧縮」とマークされます。その他のオーバーヘッドは「メタデータ」として報告されます。この2つの例は、本番DDから取得したものです。
- ファイルの圧縮は「
例 1:ファイルのインライン圧縮統計
filesys show compression /data/col1/main/dir1/file_1
Total files: 1; bytes/storage_used: 7.1
Logical Bytes: 53,687,091,200
Original Bytes: 11,463,643,380
Globally Compressed: 4,373,117,751
Locally Compressed: 1,604,726,416
Meta-data: 18,118,232
例 2:ディレクトリーの下のすべてのファイル(すべてのサブディレクトリーを含む)のインライン圧縮統計
filesys show compression /data/col1/main/dir1
Total files: 13; bytes/storage_used: 7.1
Logical Bytes: 53,693,219,809
Original Bytes: 11,501,978,884
Globally Compressed: 4,387,212,404
Locally Compressed: 1,608,444,046
Meta-data: 18,241,880
-
-
- システムは、上記のCLI出力で全体的なインライン圧縮比を「bytes/
storage_used」の出力です。 - ただし、さまざまな理由で誤解を招く可能性があるため、上記の情報の解釈には注意が必要です。
- その理由の 1 つは、
pre_lc_sizeとpost_lc_sizeは、データ操作が処理された時点で記録されます。 - これらのセグメントを最初に追加したファイルが削除されると、残りのファイル内の一意のデータ セグメントの数を増やす必要があります。
- システムは、上記のCLI出力で全体的なインライン圧縮比を「bytes/
-
たとえば、ファイル サンプル ファイルがData Domainにバックアップされ、最初のバックアップでファイルの圧縮情報が pre_lc_size= 10 GiB、 post_lc_size= 5 Gib。
-
-
- 次に、このファイルのデータが一意であり、他のファイルとデータを共有していないと仮定します。
- ファイルの2回目のバックアップでは、さらに、ファイルが理想的に重複排除されると仮定します。
pre_lc_sizeとpost_lc_sizeファイルのすべてのセグメントがすでにシステムに存在しているため、ゼロである必要があります。 - 最初のバックアップが削除されると、ファイルの2番目のバックアップが、5 GiBのデータ セグメントを参照する唯一のファイルになります。
- この場合、理想的には、
pre_lc_sizeとpost_lc_size2番目のバックアップのファイルは、両方ともゼロからそれぞれ10 GiBと5 GiBに更新する必要があります。 - ただし、どのファイルに対して実行する必要があるかを検出する方法がないため、既存のファイルのインライン圧縮統計は変更されません。
-
-
- 上記の数値に影響を与える別の要因は、累積統計です。
- ファイルが大量の上書きを受けると、ライブ データを導入した書き込みが累積統計にどの程度反映されているかを追跡することは不可能です。
- したがって、長期間にわたってインライン圧縮統計は、特定のファイルの圧縮を大まかに推定するためのヒューリスティックとしてのみ扱うことができます。
- もう1つ注目すべき事実は、ファイルのインライン圧縮は任意の時間間隔で測定できないことです。
- ファイルのインライン圧縮統計は累積された結果であり、ファイルがこれまでに受信したすべての書き込みを含みます。
- ファイルが大量の上書きを受け取ると、
raw_bytesは、ファイルの論理サイズよりもはるかに大きくなる可能性があります。スパース ファイルの場合、ファイル サイズは「Original Bytes」よりも大きくなる可能性があります。
MTree圧縮:
-
- 特定の
mtreeで確認できます"mtree show compression"(MSC) CLI コマンドを使用します。 - インライン圧縮統計の絶対値は、
MTreeの詳細を確認してください。 - の有効期間が
MTree何年もかかる場合があり、これらの値は時間の経過とともに情報量が少なくなります。 - この問題に対処するために、インライン圧縮統計の変化量(デルタ)が使用され、特定の時間間隔についてのみ圧縮が報告されます。
- 根底にあるアプローチは、
MTreeインライン圧縮統計は、定期的にログにダンプされます。 - クライアントがMTree圧縮をクエリーすると、
MSCコマンドを実行すると、圧縮レポートの数値のデルタを計算するためにログが使用されます。 - デフォルトでは、
MSC過去7日間と過去24時間の圧縮がレポートされますが、対象となる任意の期間を指定できます。
- 特定の
これを示すために、次のログを想定して MTree A:
3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB
次に、 MTree この時間のAは次のとおりです。
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
上記の圧縮比の計算では、データセットのサイズには何も影響しません。たとえば、上記のMTreeには500 GBの論理データしか含まれていない場合があります。
-
MSC「Daily」および「Daily-detailed」オプションをサポートし、「filesys show compression" コマンドを使用します。- 「daily」を指定すると、コマンドはカレンダー方式で毎日の圧縮を報告します。
- これは、
raw_bytesとpost_lc_sizeをクリックして、毎日の圧縮率を計算します。 - "daily-detailed" が指定されている場合、コマンドは (
raw_bytes、pre_lc_sizeとpost_lc_size、それぞれ)を各日に取得します。また、g_compとl_comp合計圧縮率と並んで。
これらのシステムからの出力例は、以下の 付録 にあります。
システム圧縮:
-
- 圧縮が報告されると
MTreesこの概念をシステム全体に拡張することは簡単です。 - システム全体のインライン圧縮統計の収集とレポート作成は、とまったく同じです。
MTreesの詳細を確認してください。 - 唯一の違いはスコープです。
MTree一方、1 つはシステム全体です。 - 結果は、「
filesys show compression" コマンドを使用します。 - この例は、セクション2にあります。
- 「過去7日間」と「過去24時間」のシステム圧縮は、
FSCの出力に含まれる最も便利なコマンドです。
- 圧縮が報告されると
Data Domainの統合: Cloud Tier:
- クラウド階層が実装されたDDでは、ストレージは、2つの独立した重複排除ドメインであるアクティブ階層とクラウド階層に分離されます。
- ユーザーは、アクティブ階層にのみデータを挿入できます。
- その後、DDOSのデータ移動機能を使用して、アクティブ階層からクラウド階層にデータを移行できます。
- したがって、スペースと圧縮の測定とレポート作成は、各階層で個別に処理されます。
- ただし、ファイル レベルでは、階層による差別化は行われず、インライン圧縮統計が報告されます。これらは、セクション3.1で説明した内容とまったく同じです。
重複 排除:
最後に取り上げるトピックは、重複排除の特性です。これは、多くのData Domain記事で「グローバル圧縮」と呼ばれています。
「圧縮」という言葉が含まれていますが、DDOSが「ローカル圧縮」という名前で提供している従来の圧縮の概念とはまったく異なります。
- ローカル圧縮は、特定のアルゴリズムを使用してデータのサイズを縮小します(一部の種類のデータは圧縮可能ではなく、圧縮アルゴリズムを適用するとデータ サイズがわずかに大きくなる場合があります)。
- 通常、アルゴリズムが決定されると、圧縮率の唯一の要因はデータです。
- ただし、重複排除はローカルの概念ではなく、「グローバル」です。
- 受信データ セグメントは、重複排除されたドメイン内のすべての既存のデータ セグメントに対して重複排除されます。これには、クラウド以外のData Domainシステム上のすべてのデータが含まれます。
- 重複排除手順では、データ セグメント自体は重要ではありません。
- 実際には、データセットの初期バックアップで高い重複排除率が見られることはめったにありません。初期バックアップでは、多くの場合、主なデータ削減はローカル圧縮によって行われます。
- 後続のバックアップがData Domainに配置されると、重複排除がその強みを発揮し、圧縮の主要な要因になります。
- 重複排除の有効性は、バックアップ間のデータセットの変更率が低いという事実に依存します。このため、変更率の高いデータセットは適切に重複排除できません。
- バックアップ アプリケーションが独自のメタデータ チャンク(Data Domainではマーカーと呼ばれる)を高頻度でバックアップ イメージに挿入する場合も、重複排除率が高くならない可能性があります。私たちのマーカー処理技術は、常に役立つわけではありませんが、役立つ場合があります。
これらの所見を踏まえて、予想されること:
- 初期バックアップでは、低いシステムの実効圧縮比(多くの場合、2倍または3倍)しか達成できない場合があります。通常、重複排除は初期バックアップでその強みを発揮する機会はほとんどありません。
- 増分バックアップのグローバル圧縮比は、対応するフル バックアップの圧縮比よりも低くなります。これは、増分バックアップには、直前のバックアップと比較して、変更されたファイルまたは新しいファイルのみが含まれているためです。グローバル圧縮比は、増分バックアップ内の新しいデータの割合によって異なります。
- フル バックアップ(初期バックアップ以外)の重複排除率も、一部のシナリオでは低くなる可能性があります。よく見られるシナリオには、次のようなものがあります。
-
バックアップされるデータの変更率が高い
-
小容量ファイル(5 MiB未満)がデータセットの大部分を占めている
-
間隔の狭いマーカーを多数追加するバックアップ アプリケーション
-
増分バックアップまたは小ブロック長を使用するデータベース バックアップ
-
データ変更率が低いフル バックアップで圧縮率が低い場合は、上記のケースのいずれかに該当するか、またはさらに分析が必要かどうかを確認します。
-
- 後のバックアップイメージの圧縮は、必ずしも最初のイメージよりも優れているとは限りません。初期および以前のバックアップ イメージでは、ほとんどのデータがすでにシステムに追加されているため、連続したバックアップ イメージでは高い重複排除率を示すことができます。以前のすべてのバックアップ イメージが削除された場合、最も古い既存のバックアップ イメージのグローバル圧縮比とローカル圧縮比は依然として高い可能性があります。ただし、これは、バックアップ イメージがシステムに追加されたときに適切な重複排除が行われたことを意味するだけです。グローバルおよびローカル圧縮比が高く、特定のデータセットの最後のバックアップ イメージであるファイルが削除されると、圧縮比から得られるサイズよりも多くのスペースが解放される場合があります。
- 異なるシステム上の同じデータセットの圧縮比は、データセットがそれらのシステムに追加される方法に関係なく、比較できません。これは、各システムが独立した重複排除ドメインであるためです。データセットが同じであっても、2つの異なるDDの圧縮比が同じか、必ずしも類似しているとは期待できません。
[Summary]:
- 重複排除されたファイル システムでの圧縮の測定は困難ですが、ログ構造の重複排除されたファイル システムではさらに困難です。
- 重複排除の仕組みと圧縮統計の追跡方法を理解する必要があります。
- 圧縮比は、特定のシステムの動作を理解するのに役立つ情報です。
- システムの実効圧縮比は、最も重要で信頼性が高く、有益な尺度です。
- インライン圧縮の統計も役に立ちますが、状況によってはヒューリスティックに過ぎない場合があります。
付録:
サンプル出力: "mtree show compression" コマンド
- あると仮定します。
MTree254792.4 GiBのデータを保持しています。過去7日間で4379.3 GiB、過去24時間で78.4 GiBの新しいデータを受信しました(他の時間間隔を指定できます)。 - 「daily」オプションは、過去33日間のインライン圧縮統計をレポートします。
- 「daily-detailed」オプションを指定すると、グローバル圧縮比とローカル圧縮比に分けられ、合計圧縮比がさらに詳細になります。
「 mtree リスト出力:
mtree list /data/col1/main
Name Pre-Comp (GiB) Status --------------- -------------- ------ /data/col1/main 254792.4 RW --------------- -------------- ------ D : Deleted Q : Quota Defined RO : Read Only RW : Read Write RD : Replication Destination IRH : Retention-Lock Indefinite Retention Hold Enabled ARL : Automatic-Retention-Lock Enabled RLGE : Retention-Lock Governance Enabled RLGD : Retention-Lock Governance Disabled RLCE : Retention-Lock Compliance Enabled M : Mobile m : Migratable
MSC (オプションなし):
mtree show compression /data/col1/main
From: 2023-09-07 12:00 To: 2023-09-14 12:00
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
------------- -------- --------- ----------- ---------- -------------
Written:
Last 7 days 4379.3 883.2 3.4x 1.5x 5.0x (79.8)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
------------- -------- --------- ----------- ---------- -------------
「毎日」オプションの場合:
mtree show compression /data/col1/main daily
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100
「毎日の詳細」オプションの場合:
mtree show compression /data/col1/main daily-detailed
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
3.5x 4.1x 4.3x 3.6x 3.8x 3.3x 3.4x 3.7x Global-Comp Factor
1.4x 1.5x 1.5x 1.5x 1.5x 1.4x 1.5x 1.5x Local-Comp Factor
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
80.2 83.7 84.1 81.3 82.3 78.9 80.0 81.5 Reduction %
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
3.3x 3.3x 3.0x 3.0x 3.3x 4.1x 3.6x 3.3x
1.4x 1.5x 1.5x 1.5x 1.4x 1.5x 1.4x 1.5x
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
79.0 79.0 77.6 77.7 78.2 84.3 80.9 79.2
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
4.4x 3.7x 2.6x 3.8x 3.5x 3.9x 3.2x 3.5x
1.3x 1.5x 1.6x 1.5x 1.4x 1.5x 1.5x 1.5x
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
82.1 82.2 76.8 82.2 80.3 82.7 78.2 80.7
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
3.4x 3.1x 3.2x 3.4x 3.3x 3.4x 4.1x 3.3x
1.4x 1.5x 1.5x 1.4x 1.4x 1.5x 1.6x 1.5x
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
79.5 78.2 78.6 79.2 79.2 80.4 84.2 79.6
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
3.1x 3.4x 3.2x 3.7x 3.4x .3x
1.5x 1.4x 1.5x 1.4x 1.5x 1.5x
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
78.2 79.3 78.7 81.1 79.5 79.4
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100