二重化された完全バックアップの寿命と効率

私はいくつかのクライアントのバックアップ戦略を立てようとしていますが、リモートバックアップの重複に傾いています（すでに内部/オンロケーションバックアップにはrdiff-backupを使用しています）。

完全なバックアップを頻繁に行うことは妥当ですか？重複は順方向に増分するため、各増分バックアップは前の増分に依存しており、すべてが最後の完全バックアップに大きく依存しています。それが破損すると、悪いことが起こります。関連する質問：Duplicityは増分バックアップの一貫性をテストしますか？

頻繁に完全バックアップが必要だと仮定すると、複製によってその完全バックアップがどの程度効率的に作成されますか？ファイルの署名をチェックし、以前の完全バックアップ/増分から変更されていないデータをコピーできますか？基本的に、新しい/変更されたデータを転送し、既存の変更されていないデータをマージする新しい「フル」アーカイブを作成しますか？

現時点では、フルバックアップを実行する必要があるのではないかと心配していますが、フルバックアップを一貫して大帯域幅で使用するため、一部のクライアントではこれが不合理になります。

頻繁にフルバックアップを実行するのが合理的だと思います。ほとんどのマシンは、数か月に1回実行するように構成されています。その数に魔法はありません。正しい値は、持っているデータの量、変化の速さ、最新のスナップショット以外から復元する可能性、トラフィックとストレージのコストに依存します、そしてあなたがどれほど妄想的か。他の人は毎週完全バックアップを必要とするかもしれません。

時々フルバックアップを行わない限り、アーカイブのサイズとリカバリ時間は増え続けます。

重複性には特に「チェック」コマンドhttp://pad.lv/660895があるとは思わないが、もしあればそれはいいだろう。テストの復元を頻繁に行うことは非常に賢明です。

関連する質問は、複数のバックアップチェーンを保持する必要があるかどうかです。繰り返しますが、それはコストに依存します。1つ保持する理由の1つは、ハードウェア障害、OS障害、または重複バグのために現在のチェーンが破損している場合、そこから復元できることです。もちろん、古いチェーンが非常に古い場合、そのチェーンからの復元は限られた価値しかありません。

完全バックアップを作成すると、常にデータの完全コピーがアップロードされます。

クライアントの懸念が、トラフィック料金ではなく、使用される帯域幅の割合である場合、たとえばで実行することができますtrickle。

求めているのは、合成完全バックアップと呼ばれます。これは、宛先側（つまり、バックアップサーバー）で増分バックアップを以前の完全バックアップとマージして、完全バックアップを取得するプロセスを指します。

私はDuplicityに精通していませんが、彼らのWebサイトからは、合成完全バックアップを実行していないようです。すべてのインクリメンタルを、それらが基づいているフルに戻す必要があります。それが場合である場合、あなたはおそらくしょっちゅうフルバックアップを強制することになるでしょう、理由は次のとおりです。

• 100万の増分を実行すると、おそらく復元が遅くなります
• おそらく、増分を時間の始まりに戻したくないでしょう。

合成フルを達成するための興味深い方法の1つは、--link-dest = DIRオプションを指定してrsyncを使用するか、rsnapshotを使用することです。各増分バックアップの差分のみが保存されますが、それぞれが完全に表示されます。それらのいずれかを削除すると、増分が適切に自動的にマージされます。これはハードリンクの魔法によって行われるため、差分はファイルベースになります（ファイルが変更され、差分に含まれるかどうか）。