最初の重複排除ストレージシステムは2000年代初頭に登場しました。 指数関数的に増加するデータをバックアップする問題を解決するために作成されました。 企業の生産システムでのデータの増加により、テープへのバックアップの期間が非常に長くなり、バックアップウィンドウにフルバックアップが「配置」されなくなり、その時点で存在したディスクストレージシステムをバックアップストレージとして使用することが困難になりました容量が不十分なためです。 その結果、時間の不足（テープの場合）またはスペースの不足（ディスクの場合）のいずれかにより、バックアップが「途切れる」可能性があります。 ディスク容量の問題は、大容量のストレージシステムを購入することで解決できますが、この場合、ストレージコストが高いという問題がありました。
バックアップソフトウェア製品は元々、バックアップストレージがテープドライブであり、バックアップアルゴリズムが父子孫アルゴリズムであるという前提で設計されました。
- 「父」（週に1回の完全バックアップ）、
- 「息子」（週6日の増分コピー）、
- 「Grandson」（古いフルバックアップ、通常はオフサイトストレージに送信）。
このアプローチにより、非常に多くのバックアップデータが生成され、テープを使用する企業にとっては比較的安価でしたが、ディスクを使用する場合、このアプローチのコストは大幅に増加しました。
当時、少数のバックアップソフトウェア製品のみが、バックアップデータの組み込み重複排除機能を提供していました。 重複排除機能が組み込まれたストレージシステムは、この問題を解決するために特別に登場しました-ディスクにデータを保存するコストを削減します（将来、テープレベルまで）。 これらの新しいデバイスが成功した主な要因は、ストレージの重複排除が透過的に機能し、既存のバックアップソフトウェアを変更する必要がないという事実でした。
ただし、過去数年間、ほとんどすべてのバックアップソフトウェア製品に組み込みの重複排除が導入され、ディスクのコスト（ディスクストレージシステムの元の問題）が大幅に減少しました。 さらに、現在では多くのバックアップ製品が元のデータの側で重複排除できます。つまり、バックアップデータは、ストレージのバックアップリポジトリに転送される前であっても重複排除されます。 これにより、チャネルの負荷を減らし、操作の速度を上げ、バックアップウィンドウを減らすことができます。 このため、多くのディスクストレージシステムの機能には、このようなソフトウェア製品との統合機能が含まれています。
現在、重複排除機能は多くの場合無料で含まれているため、バックアップリポジトリとして位置付けられているストレージシステムは、生産的なネットワークのプライマリサーバーとして動作するように設計されたストレージシステム（プライマリストレージ）からの競争圧力をさらに受けています。
論理的な疑問が生じます。なぜ特別なバックアップターゲットストレージシステムが必要なのか、それらを正しく使用する方法は何ですか このようなストレージシステムのさまざまなメーカーからの情報を要約する場合、次の3つの戦略を使用します。
- （特定の条件下で）バックアップターゲットストレージシステムでの重複排除には、バックアップ製品に組み込まれた重複排除よりも利点があると言われています。
- ストレージシステムをバックアップリポジトリの保管場所としてだけでなく、組織の電子ドキュメントアーカイブの保管場所としても位置付けています。
- ストレージシステムのサプライパッケージにバックアップソフトウェアを含めるか、ストレージシステムをバックアップソフトウェア製品（他のメーカーの製品を含む）と統合するだけです。
最初の点を考慮してください（重複排除の方が良いでしょうか？）
比較すると、製造業者の主張は、重複排除係数、バックアップウィンドウの期間、総等価ストレージ容量、レプリケーション効率の比較分析に帰着します。 ただし、実際には、この分析は「環境要因」に強く依存します（つまり、実験条件、およびクライアントの実際の条件が実験条件と異なる場合、係数の測定結果は異なります）。
たとえば、重複排除係数を考えます。 ここで、何をどのように測定するかを正しく決定する必要があります。 一部のメーカーは、自社製品の重複排除係数が30対1であることを示しています。 もちろん印象的です。 ただし、同時に、他のメーカーは、自社製品の重複排除係数が1桁小さい、たとえば「3対1」であることを示しています。 これは、最初のメーカーの製品が2番目のメーカーよりも優れているということですか？ いいえ、計算では異なるデータセットが評価されたため、そのような異なる重複排除係数が得られました。 つまり、定数として示される「重複排除係数」は、マーケティング用語です。異なるメーカーの異なるデータの重複排除を示しており、異なる製品を意図的に実践しようとしない限り、その基準で製品を比較することはできません同じテストデータセットを準備しました。 ただし、現時点では、重複排除係数を推定するための業界（または少なくとも事実上の）標準はありません。 アンチウイルス業界には、いわゆる EICAR標準参照テストウイルス。ウイルス対策ソフトウェアによって検出される必要があります。 ここでも、さまざまなソフトウェア製品とストレージシステムの重複排除係数が計算されるテスト参照データセットを作成できますが、実際にはそのような参照はありません。
重複排除係数の比較の違いは、異なる製品を使用する場合のバックアッププロセス自体のアルゴリズムにも違いがあるために観察できます。 バックアップソフトウェア製品が使用され、スキームが週に1回フルコピーで適用され、他の日には増分コピーで適用されるとします。 製品は、バックアップを重複排除して圧縮します。 次に、これをバックアップターゲットストレージの使用と比較します。たとえば、ストレージのディスクボリュームの完全なコピーを毎回受け取り、データをディスクに保存する前に重複排除を実行します。 2番目の場合、重複排除係数ははるかに大きくなり、バックアップリポジトリのディスクスペースの実際の節約は、逆にはるかに小さくなります。
同時に、最終的に重複排除ツールを比較するための最も適切な基準となるのは、特定の期間にわたって保存されたバックアップリポジトリのディスク容量です（重複排除係数ではありません）。 ただし、（購入前に）事前に見つけることは通常不可能です。
「 同等のストレージ容量 」（または重複排除なしでデータを保存するために必要なストレージサイズ）は、同じ重複排除係数に基づいて計算されるため、純粋にマーケティング基準でもあります（メーカーは実際の使用可能容量を単純に乗算します）重複排除係数のストレージ）。 その結果、1つの係争係数を使用して、別の係争係数が取得されます。
同等のバックアップパフォーマンス比が使用される場合があります。 この係数の考え方は、ユーザーがソースデータ側で一次重複排除を実行する特別なソフトウェアクライアントを使用して（ネットワークトラフィックを最小限に抑える）、バックアップ対象ストレージにデータを送信し、このデータがグローバルに重複排除される（占有ディスクスペースを最小限に抑える）ことを意味します。 これらのクライアントは通常、データベースサーバー、アプリケーションサーバー、およびバックアップサーバーにインストールされます。 1時間あたりのテラバイト単位で測定される同等のバックアップパフォーマンスは、ストレージに1時間実際に保存されるデータの量として定義され、...重複排除係数で乗算されます。 明らかに、この場合、この係数を使用した異なるストレージシステムの比較は、製品の材料に示されている場合、正しくありません。 同時に、2種類の重複排除（ソースデータ側とストレージ側）を組み合わせるというアイデアは非常に優れており、ITプロバイダーが異なるクライアントを使用する場合や、企業内で分散サーバーの集中バックアップを使用する場合に使用できます。
元のデータの転送速度のみが客観的なメトリックと見なされます。
戦略＃2（ターゲットSHDを電子アーカイブとしてバックアップする）
バックアップターゲットストレージをストレージとして再配置します。これは、バックアップリポジトリの保存だけでなく、組織の電子アーカイブの保存にも使用できます。 ただし、これら2つの場合のストレージの要件は大きく異なります。 アーカイブは、バックアップとは異なり、その性質上、重複した情報を含むことはめったにありません。 アーカイブは、個々のアイテムをすばやく検索する機能を提供する必要がありますが、バックアップにアクセスすることは比較的まれです。 これらの要件の違いは、これらのタスクを実行するためにストレージシステムに異なるアーキテクチャが必要であることを示しています。 製造業者はこの方向で措置を講じます。たとえば、ストレージシステムのファイルシステムのアーキテクチャを変更しますが、そうすることで、本質的にユニバーサルファイルシステムとユニバーサルストレージシステムに向かって動いています（そして、ユニバーサルストレージシステムとの競争については既に述べています）。
戦略3（ストレージシステムとバックアップソフトウェア製品の統合）
バックアップソフトウェア製品とストレージを統合するという考え方については、統合がマーケティング資料だけでなく、技術レベルでの統合を含む場合、 非常に合理的に見えます。 たとえば、ストレージシステムは、ディスクのハードウェアスナップショットを可能な限り効率的に作成します（サードパーティベンダーからのソフトウェアの実装はおそらく遅くなるため、実際には最小限のRPOを取得します）。 同時に、ソフトウェアバックアップ製品は他の重要なバックアップ機能も実行します：リポジトリの構築と長期バックアップストレージの整理、バックアップテスト手順の実行、障害発生時の迅速なデータ回復（ RTOの最小化）。 バックアップソフトウェア製品とハードウェアストレージシステムのメーカー間のこのような技術的な「共生」により、ユーザーにとって最も効果的なソリューションを得ることができます。
結論として
- 10年以上にわたって、重複排除機能を備えた製品とデバイスの市場は技術的に進化しました。機能面で互いに補完することで利益を上げています。 バックアップリポジトリでの重複排除から、ソースデータ側での重複排除、またはアプローチの組み合わせへの移行がありました。
- ソースデータ、日々の変化の性質、ネットワーク帯域幅およびその他の「環境」要因に大きく依存しているため、「重複排除係数」とそれらから導出されるメトリックによって重複排除の有効性を比較する必要はありません。
- 現時点では、バックアップインフラストラクチャのアーキテクチャを作成する際に、「 重複排除機能を備えたハードウェアストレージ 」と「 ソフトウェアバックアップ製品 」を個別に見るのではなく、ソフトウェアとストレージの統合補完バンドルを別々に見ることが最適です