重複性の完全バックアップの寿命と効率
一部のクライアントのバックアップ戦略を練り上げようとしていますが、リモートバックアップの重複性に傾いています（内部/場所のバックアップには既にrdiff-backupを使用しています）。
頻繁にフルバックアップを行うのは理にかなっていますか？重複が増加するため、各増分バックアップは前の増分に依存しており、すべてが最後の完全バックアップに大きく依存しています。それが腐敗すると、悪いことが起こります。関連質問：重複は増分バックアップの一貫性をテストしますか？
私がdoフルバックアップを頻繁に行うと仮定すると、duplicityはそのフルバックアップをどのくらい効率的に作成しますか？ファイルの署名をチェックして、以前のフルバックアップから変更されていないデータをコピーできます/増分？基本的に、新しい/変更されたデータを転送し、既存の変更されていないデータをマージする新しい「フル」アーカイブを作成しますか？
現在、私の懸念は完全バックアップの実行が必要であるということですが、完全バックアップの一貫した広い帯域幅の使用は、これを一部のクライアントにとって不合理にします。
たまにフルバックアップが必要になるのは理にかなっていると思います。ほとんどのマシンは、数か月に1回実行するように構成されています。その数に魔法はありません。適切な値は、データの量、データの変化の速さ、最新のスナップショット以外から復元する可能性、トラフィックとストレージのコストに依存します。 、そしてあなたがどれほど妄想的か。他の人は毎週完全バックアップをしたいと思うかもしれません。
時々フルバックアップを行わない限り、アーカイブサイズとリカバリ時間は増え続けます。
重複には特に「チェック」コマンドがあるとは思いません http://pad.lv/660895 ですが、もしそうならそれは素晴らしいでしょう。頻繁にテスト復元を行うことは非常に賢明です。
関連する質問は、複数のバックアップチェーンを保持する必要があるかどうかです。繰り返しますが、それはコストに依存します。 1つ保持する理由の1つは、現在のチェーンが破損している場合、ハードウェア障害、OS障害、または重複バグのためにそこから復元できることです。もちろん、古いチェーンが非常に古い場合、そこからの復元は限られた価値しかありません。
完全バックアップを作成すると、常にデータの完全コピーがアップロードされます。
クライアントの懸念が、トラフィック料金ではなく使用された帯域幅の割合である場合は、たとえばtrickleの下で実行することをお勧めします。
あなたが求めているものは、合成完全バックアップと呼ばれ、これは、マージによって完全バックアップを取得するプロセスを指します宛先側（つまり、バックアップサーバー）で以前の完全バックアップを使用した増分バックアップ。
私はDuplicityに詳しくありませんが、 their website から、完全バックアップを合成しないようです。すべての増分を基にしたフルに戻す必要があります。これがの場合の場合は、次の理由により、フルバックアップを頻繁に強制することをお勧めします。
- 100万の増分を実行すると、おそらく復元が遅くなります
- あなたはおそらく増分を時間の初めに戻したままにしたくないでしょう
合成フルを実現する興味深い方法の1つは、 rsyncに--link-dest = DIR オプションを使用するか、または rsnapshot を使用することです。各増分バックアップ間の違いのみが保存されますが、それぞれがいっぱいに見えます。それらのanyを削除すると、自動的に増分が適切にマージされます。これはハードリンクの魔法を通じて行われるため、差分はファイルベースになります（ファイルが変更され、差分に含まれるかどうか）。