復元前に決める三つのこと
正常だった時点、復元対象、書込み停止期間を決めます。現状のDB・ファイル・ログも退避し、間違った時点へ戻した場合にやり直せるようにします。侵害がある場合は、復元データ自体が汚染されていないか確認が必要です。
検証環境で復元を試す
- 対応するDBとファイルの世代を選ぶ。
- 外部メールや決済が動かない隔離先へ展開する。
- DB接続情報、配置場所、必要なURLを確認する。
- PHP・拡張機能・ファイル所有者の差を調整する。
- 投稿、画像、管理画面、フォーム、独自機能を確認する。
URLを変える場合は、シリアライズされた値に対応する方法を選びます。SQLファイルの一括文字置換は設定を壊す原因になります。
本番へ戻すときの確認
DNSや公開先を切り替える前に、証明書、リダイレクト、検索への公開設定、定期処理を点検します。受注・会員登録などの差分をどう回収するか決め、関係者に作業完了を伝えます。
復元後も同じ原因を残さない
更新失敗なら互換性、侵害なら侵入経路や認証情報を対処します。正常に表示されたことだけで復旧完了にせず、監視再開と再発防止の記録まで行います。
復元の完了を判定するチェック
現在の復元先、選んだ日時、DBとファイルの対応を記録し、元の症状が解消したか確認します。投稿の件数だけでなく、非公開データ、画像、メール、外部サービスの接続、権限、定期処理まで点検します。検索への公開設定や管理画面のメールアドレスが検証先のまま残っていないかも確認します。
差分データを扱うとき
復元中に入った注文や会員登録を、何を正としてどう戻すかを決めます。DBの一部テーブルを単純に混ぜるとIDや関連データの整合性を壊す場合があります。独自テーブルのあるサイトは、製品仕様を確認できる担当者と進めます。
よくある質問
ファイルだけ戻してもよいですか？
変更がファイルだけで、DBとの互換性が確認できる場合は選択肢になります。更新時にDB移行が入ったなら同じ判断はできません。作業履歴と製品仕様を確認します。
復元したら古い脆弱性も戻りますか？
戻る場合があります。復元後に修正や公開制限を適用する手順を用意し、未修正の構成をそのまま再公開しないようにします。