バックアップは何時間ごと?許容するデータ損失から間隔を決める
バックアップ頻度は、失ってよいデータの期間から決めます。設定が「毎日」でも、最後に成功したコピーが古ければ条件を満たしません。成功時刻の古さを基準に、追加保存か処理停止を判断します。
公式資料確認日:。
失ってよい時間を業務側で決める
RPOは復元先の速さではなく、どこまでの変更を失えるかという条件です。再取得できるinput、再生成できる成果、外部への確定済み書込みを分けます。全てに一律の時間を置かず、再生成不能な変更を基準にします。
予定と成功を分けて記録する
| 確認対象 | 判断に使う記録 | 次の選択 |
|---|---|---|
| 許容損失 | 再生成できない変更は何時間分までか | 業務の受入条件 |
| 予定間隔 | copy開始の間隔と所要時間 | 完了まで古いcopyしかない |
| 最後の成功 | copy時刻・対象版・照合結果 | 予定時刻を成功にしない |
| 失敗時 | 成功copyが許容年齢を超えた状態 | 通知・入力停止等を決める |
架空例:4時間間隔でも4時間の保証ではない
4時間おきにbackupを始め、完了に1時間かかる仮定なら、次のcopyが完了する直前は前回の取得点が約5時間前です。取得点と完了時刻が同じという前提は置きません。さらに一回失敗すれば古さが増えるので、予定頻度だけでRPO達成としません。
頻度を増やす前に対象を小さくする
全diskのcopyが遅い場合、必要な変更の保存方式を見直す案もあります。差分取得が成立するかを実際の入力で確認し、容量・転送・費用を別に見積ります。短い間隔で壊れたcopyを増やすより、成功を検査して復元できることが必要です。
公式資料と、判断例の境界
仕様の根拠は以下の公式資料です。本文の記入例は実測値ではありません。購入・設定変更時は、対象の型番・版・契約条件を照合します。
- restic restore
復元先を指定したrestoreで保存内容を確認します。復元コマンドの終了だけで業務の再開を保証しません。