3つの要点
先に把握しておきたい論点だけを短くまとめています。忙しいときはここだけでも全体像をつかめます。
何を守るか先に決める
ファイルだけでなく、データベース、設定、環境変数、DNS、デプロイ手順や仕様書まで、復旧に必要な対象を洗い出します。
同じ場所だけに置かない
運用環境とは別の場所にもコピーを持ち、保存先・頻度・保存期限・暗号化の有無を決めておきます。
復元テストは小さくてよい
小さなファイルを戻す、ダンプをローカルで開くだけでも、障害時に焦って危険な操作をする可能性を下げられます。
ファイルだけでなく、データベース、設定、環境変数、DNS、デプロイ手順や仕様書まで、復旧に必要な対象を洗い出します。
何を守りたいのかを先に決める
サイト運営で守るべきものは、ファイルだけではありません。データベース、アップロード画像、設定ファイル、環境変数、メール設定、DNS設定、デプロイ手順、仕様書、TODOも復旧に必要な情報です。
すべてを同じ頻度で保存する必要はありません。記事や設定が頻繁に変わるなら高頻度に、ほとんど変わらない仕様書は変更時に保存するなど、重要度と変化の速さで分けて考えます。
何をどれくらいの頻度で守るか
すべてを同じ頻度で保存する必要はありません。重要度と変化の速さで分けて考えます。
| 対象 | 変化の速さ | 保存頻度の目安 |
|---|---|---|
| 記事・データベース | 速い | 高頻度（日次など） |
| 設定・環境変数 | ときどき | 変更のたびと定期の両方 |
| 仕様書・手順書 | 遅い | 変更したときに保存 |
同じ場所だけに置かない
サーバー内にバックアップを置くだけでは、サーバー障害や誤削除に弱いです。逆に、手元だけに置くと端末故障に弱くなります。最低限、運用環境とは別の場所にもコピーを置くことを考えます。
ただし、むやみに保存先を増やすと管理が難しくなります。保存先、保存頻度、保存期限、暗号化の有無を決め、古いバックアップに秘密情報が残り続けないようにします。
今日からできること
- 守る対象（DB・画像・設定・環境変数・DNS・手順書）を洗い出し、変化の速さで頻度を分ける
- 運用環境とは別の場所にもコピーを置き、暗号化と保存期限を決める
- 小さなファイルの復元やダンプの読み込みを一度試し、手順をメモする
- 日次・週次・月次で世代を分け、期限を過ぎたものを整理できる設計にする
復元テストは小さくてもよい
本番環境を丸ごと復元するテストは重い作業です。最初は、小さなファイルを戻す、データベースのダンプをローカルで読めるか確認する、設定ファイルの必要項目を一覧化するだけでも前進です。
復元テストで見つかる問題は、バックアップの失敗ではなく、改善の材料です。戻し方を一度経験しておくと、障害時に焦って危険な操作をする可能性が下がります。
実際にやってみると、「ファイルは戻せたがデータベースの文字コードが崩れた」「バックアップは取れていたが復元手順を誰も知らなかった」といった、保存しているだけでは見えない穴が先に見つかります。本番が動いているうちに一度試しておけば、これらを落ち着いて直せます。
保存期限も品質の一部
バックアップは多ければ多いほどよいわけではありません。古いバックアップが無制限に残ると、容量、秘密情報、個人情報、誤復元のリスクが増えます。
日次、週次、月次のように世代を分け、いつまで残すかを決めます。ログと同じく、バックアップも運用の記憶です。必要な期間を過ぎたものは整理できる設計にしておく方が、長く続けやすくなります。
