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