私は、ユーザーが予期せずマシンの電源をオン/オフする小規模ネットワーク用の集中バックアップ ツールとして Bacula を評価しています。バックアップする必要のあるヘッドレス Linux ボックスの中には、ケースのオン/オフ ボタンを押して電源をオフにするようになっているものがあり、バックアップ ジョブが完了するまで待つようにユーザーに伝える方法はありません。
したがって、バックアップ ジョブがいつ実行されるかはわかりません (anacron がこれに役立つかもしれません)。また、バックアップ ジョブが完了できるかどうかもわかりません。
このような環境の場合、Bacula は適切な選択でしょうか?
答え1
bacula は、すべてのスケジュールを管理する中央の「ディレクター」に依存しています。システムがダウンしている場合、 ( ) がストレージ デーモン ( ) と通信しようとしてbacula-director、設定された時間が経過すると、bacula は諦めてジョブを失敗としてマークします。ジョブの実行中に電源がオフになると、ほぼ確実にジョブが失敗としてマークされます。bacula-fdbacula-sd
私の知る限り、ジョブが失敗すると、再試行または継続するメカニズムはなく、次回そのジョブがスケジュールされたときに bacula は最初からやり直します。
ボックスから中央サーバーにバックアップし、その中央サーバーをテープにバックアップすることをお勧めしますrsync。この場合、各ボックスの cron から、@reboot と同様に都合の良い時間に rsync をスケジュールできます。rsync の途中でシステムがシャットダウンした場合、起動時に完了します。このような「プッシュ」バックアップを使用する場合、破損したクライアントが破損したデータをサーバーにプッシュするため、中央サーバーのバックアップを維持することが重要です。
答え2
Bacula はサーバーでの使用に適しています。Areca をお試しください。
答え3
Bacula がこの状況をどのように処理するかはわかりませんが、私は「消えた」クライアントに関して Backuppc を評価しました。Backuppc はトランスポートとしてプレーン rsync を使用するため、ジョブの実行中にクライアントの電源がオフになった場合、バックアップを「部分的」としてマークできます。このような状況からの回復は問題なく機能します。