バックアップがあることと復旧できることの違い

システムが約束すること

バックアップは、役に立つサービスへ戻せたことを確認するまでは復旧候補です。直近の仕事をどこまで再入力できるか、どれほど停止を許容できるかを事業責任者と決めます。これは運用上の選択で、保存スケジュールだけから生まれる約束ではありません。

現実的な選択肢を比べる

データベース、添付ファイル、設定、秘密情報へのアクセス、互換性のあるアプリ版を列挙します。DBだけで製品が戻るとは限りません。書込中の動作に合う方法を使います。SQLiteは一貫したコピーのためのOnline Backup APIを説明しています。稼働中ファイルをジャーナルの状態を理解せずコピーするだけでは手順になりません。

一連の操作を試す

注文アプリを隔離環境に戻す例では、整合性、代表注文、添付の対応を確認します。外部連携を止めて起動し、訓練で本物の通知や課金を発生させないようにします。バックアップを取得してから通常の作業が終わるまでを測り、権限や設定不足も復旧の不具合として残します。DBが開くだけでは終わりません。

復旧を見えるようにする

唯一の本番を上書きして練習しません。現状を守り、復元先を明示し、置換には意図的な破壊操作を要求します。同じディスクのコピーではそのディスク自体の損失に備えられません。別のコピーと必要な鍵へのアクセスを試します。取り出せず解読もできないファイルは使える復旧手段ではありません。

障害前に復旧の順序を書く

手順の冒頭に目的と対象を置きます。隔離練習、失ったホストの復旧、壊れた本番の置換では影響が違います。選んだバックアップの出所、作成時刻、整合性、互換版を記録します。アクセス方法と秘密の値は分け、権限者へ手順を渡す際に認証情報を広めないようにします。

本番置換では書込を止める管理された時点が必要です。Webだけでなくワーカー、定期処理、他の書込元も扱います。可能で調査に有用なら現状を残し、予定先へ戻して所有者、権限、DB、関連ファイルを一般利用前に確認します。不完全なデータへキューを実行させない順序で再開します。停止中に思いつくコマンドでなく、実際の構成で練習する手順です。

技術的復旧後は注文、添付、支払参照を復元時点と照合し、それ以降の仕事に担当を付けます。ローカル記録が過去に戻ったからと、課金、配送、通知を自動反復しません。外の世界はDBと一緒に戻っていません。差分を解決まで見えるようにし、顧客対応へ影響を伝えます。訓練の実測時間、アクセス不足、依存漏れを手順へ反映します。別保管先と保存期間も試し、便利なローカルファイルでの成功だけでホスト喪失への備えを証明しないでください。

復旧の受入証拠

検討に持ち寄る例

いつもの担当者が不在なら誰が戻すか。失うデータをどう照合するか。修理継続ではなく切り戻す条件は何か。緑色の成功表示だけでなく、実際の復旧所要時間と未解決点を改善相談へ持ち寄ります。