増分バックアップ

増分バックアップとは、データの連続コピーに、前回のバックアップコピーが作成されてから変更された部分のみが含まれるバックアップです。^{[1] [2] [3] [4]} 完全な回復が必要な場合、復元プロセスには、最後の完全バックアップに加えて、復元ポイントまでのすべての増分バックアップが必要になります。^{[5]増分バックアップは、ストレージスペースの使用量を削減し、}差分バックアップよりも実行が速いため、多くの場合望ましいものです。^[6]

増分バックアップの最も基本的な形式は、前回のバックアップ以降に変更されたファイルのみを識別、記録、保存することです。変更は通常少ないため、増分バックアップは完全バックアップよりもはるかに小さく、高速です。たとえば、金曜日の完全バックアップの後、月曜日のバックアップには金曜日以降に変更されたファイルのみが含まれます。火曜日のバックアップには月曜日以降に変更されたファイルのみが含まれます。データの完全復元は、すべての増分を復元する必要があるため、当然遅くなります。最初の（完全）コピーを含む作成されたコピーのいずれかが失敗すると、復元は不完全になります。^[7]

Unix の例は次のようになります。

rsync  -e  ssh  -va  --link-dest = $dst /hourly.0 $remoteserver : $remotepath $dst /hourly.1
  

rsyncの--link-destオプションを使用することで、このコマンドは増分バックアップの例になります。

より洗練された増分バックアップ方式では、複数の番号付きバックアップ レベルが使用されます。完全バックアップはレベル 0 です。レベルnバックアップでは、最新のレベルn-1バックアップ以降に変更されたすべての内容がバックアップされます。たとえば、レベル 0 バックアップが日曜日に作成されたとします。月曜日に作成されたレベル 1 バックアップには、日曜日以降に行われた変更のみが含まれます。火曜日に作成されたレベル 2 バックアップには、月曜日以降に行われた変更のみが含まれます。水曜日に作成されたレベル 3 バックアップには、火曜日以降に行われた変更のみが含まれます。木曜日に作成されたレベル 2バックアップには、月曜日が最新のレベル n-1 バックアップであるため、月曜日以降 に行われたすべての変更が含まれます。

ミラーの 2 つのインスタンス間で行われた変更の増分バックアップは、順方向または逆方向に行うことができます。

ミラーの最も古いバージョンがベースとして扱われ、最新バージョンが修正バージョンとして扱われる場合、生成される増分は前方増分になります。

ミラーの最新バージョンをベースとして扱い、最も古いバージョンを改訂/変更されたバージョンとして扱う場合、生成される増分は逆増分になります。

逆増分バックアップを使用してバックアップを作成する場合、逆増分バックアップが作成されるたびに、前回の完全 (合成) バックアップに (逆に) 適用されるため、現在の完全 (合成) バックアップは常にシステムの最新の状態のバックアップになります。これは、現在の完全バックアップがシステムの最も古いバージョンのバックアップである順方向増分バックアップとは対照的であり、システムの最新の状態のバックアップを取得するには、すべての順方向増分バックアップをその最も古いバージョンに連続して適用する必要があります。

ミラーに逆増分を適用すると、結果はミラーの以前のバージョンになります。これにより、ミラーの任意の以前のバージョンに戻す手段が提供されます。

つまり、最初の完全バックアップの後、後続の増分バックアップでは、前回の完全バックアップへの変更が適用され、毎回新しい合成完全バックアップが作成され、以前のバージョンに戻す機能が維持されます。

このタイプのバックアップの主な利点は、データの最新バージョン (最も頻繁に復元されるバージョン) が (合成) 完全バックアップであり、復元中に増分を適用する必要がないため、復元プロセスがより効率的になることです。逆増分バックアップはテープとディスクの両方で機能しますが、実際にはディスクの方がうまく機能する傾向があります。

逆増分バックアップ方式を使用している企業としては、IntronisやZetta.net などがあります。

このスタイルは、合成バックアップの概念に似ています。最初の完全バックアップの後、増分バックアップのみが集中バックアップ システムに送信されます。このサーバーはすべての増分を追跡し、復元時に適切なデータをクライアントに送り返します。これは、増分が取得されるたびに各増分を直接テープに送信し、必要に応じてテープをリファクタリングすることで実装できます。十分なディスク領域が利用できる場合は、以前の増分変更とともにオンライン ミラーを維持して、バックアップされているシステムの現在のバージョンまたは古いバージョンを復元できます。これは、銀行システムの場合に適した方法です。^{[引用が必要]}

最新のクラウド アーキテクチャ、またはディスクからディスクへのバックアップ シナリオでは、これははるかに簡単です。データはチャンクに分割され、クラウド ストレージシステムに配置されます。チャンクに関するメタデータは永続的なシステムに保存されるため、システムは復元時にこれらのチャンクからポイント イン タイム バックアップを組み立てることができます。テープをリファクタリングする必要はありません。

この方法では、ファイル内の変更されたブロックのみをバックアップします。送信者と受信者の間でより高度な統合が必要です。

これらのバックアップ技術は、「ブロックレベルの増分」バックアップ方法に似ていますが、バイト（またはバイナリ）増分バックアップ方法は、前回のバックアップと比較したファイルのバイナリバリエーションに基づいています。ブロックベースの技術は変更の大きい単位（8K、4K、または1Kのブロック）で動作しますが、バイトベースの技術は最小単位で動作し、ファイルの変更を反映するときにスペースを節約します。^[8]もう1つの重要な違いは、ファイルシステム上で独立して動作することです。現時点では、これらはデータの相対的な圧縮が最も高い技術であり、インターネットを介して実行されるセキュリティコピーに大きな利点をもたらします。^{[引用が必要]}

合成バックアップは、フルバックアップを作成するための代替方法です。ディスクから直接データを読み取ってバックアップする代わりに、前回のフルバックアップ (最初のバックアップの通常のフルバックアップ、または前回の合成フルバックアップ) と定期的な増分バックアップのデータを合成します。増分バックアップのみがディスクからデータを読み取るため、オフサイトレプリケーション中に転送する必要があるファイルは増分バックアップのみです。これにより、オフサイトレプリケーションに必要な帯域幅が大幅に削減されます。合成バックアップは常に同じ効率で動作するわけではありません。ターゲットマシンからストレージに同期されたデータにアップロードされるデータの速度は、ディスクの断片化によって異なります。^[9]

差分バックアップは、最後の完全バックアップまたは通常バックアップ以降に行われたすべての変更、つまり最後の完全バックアップ以降の差分の累積バックアップです。これの利点は、システムを復元するのに完全バックアップと最後の差分バックアップのみが必要なため、回復時間が短いことです。欠点は、最後の完全バックアップから経過した日数ごとに、特にデータの大部分が変更された場合、より多くのデータをバックアップする必要があることです。

永久増分バックアップ^[10]では、合成操作によって新しいフルバックアップを作成できます。このバックアップは、「合成フルを使用したフォワードモード」で行われるフルバックアップファイルの完全なサイズではなく、増分ファイルのサイズに制限されます。消費される全体的な I/O はリバース増分と同じですが、バックアップアクティビティの期間中は 1 回の書き込み I/O のみが使用され、VM のスナップショットが開かれる時間はリバース増分よりも短くなります。残りの 2 回の I/O は、フルバックアップファイルを更新するために使用されます。

• バックアップローテーションスキーム
• 継続的なデータ保護
• デルタエンコーディング
• Dump (Unix) - マルチレベルの増分ファイル システム バックアップ用の UNIX ユーティリティ。
• インクリメンタルコンピューティング
• rsync - ファイル同期アルゴリズムとプロトコル。