WordPress復元計画の作り方｜保存時点・新規データ・復旧判定

データベース全体を戻す前に判断が分かれる例

例として、9時のバックアップ後、10時にテーマのCSSを変更して表示が崩れ、10時30分に問い合わせを受け付けた状況を考えます。障害がCSSだけなら、11時に9時のデータベースへ丸ごと戻すと、問い合わせを失う危険を増やします。「保存があるから全部戻す」ではなく、変更した範囲から判断します。

表は横にスクロールできます。

この表は判断の練習用です。ECや会員サイトでは、注文・決済・在庫・外部サービスの状態が関係します。バックアップの取得時点だけでは整合性を決められないため、管理者と復旧範囲を決めるまで本番へ上書きしないでください。

復旧メモには実データそのものを貼らず、保管場所・件数・対象時刻・確認担当を残します。

1. 何を、どの時点へ戻すか決める

WordPressのファイル、画像、テーマ、プラグインと、投稿・設定等を保持するデータベースの対象を確認します。二つを異なる時点から無条件に組み合わせると整合しない場合があります。保存時刻・取得方法・対応バージョンを組にして記録します。

基本の保存対象はWordPress公式のバックアップ解説で確認できます。保存先の選び方は保存場所を分ける判断表に分け、ここでは戻す手順へ集中します。

2. 停止時間より先に、失う可能性のある変更を確認する

スマホでは表を横にスクロールできます。

件数は説明用の例です。メール側に通知が残っていても、データベースや添付ファイルまで完全に復元できない場合があります。戻す前に、新しいデータの保管方法を具体的に決めます。

3. 練習は本番を上書きしない場所で行う

本番と接続先を分け、検証用のデータベース、URL、ファイル保存先を確認します。メール、決済、外部サービスへの自動処理は、検証環境から実行されない構成にします。コピーした顧客情報が公開検索や第三者に見えないようアクセスも制限します。

保存データを取り込み、ログイン、主要ページ、画像、設定、フォームの表示を確認します。対象を戻せたか、想定のバージョンと保存時点か、操作に必要な権限があるかを、一つずつ確かめて書き込みます。準備はステージング環境の確認表を参照してください。

4. 本番復旧は合意した対象だけを戻す

原因と復元範囲を整理し、担当者と反映時間を決めます。ファイルの変更だけで直るのか、データベースの復元も必要かは変更内容によって異なります。管理画面が開かない状況でも使える復旧経路を先に確保してください。

• 直前の状態も退避し、新しいデータを保全する。
• 対象サーバー・URL・データベース名を照合する。
• 手順に沿って復元し、作業結果やエラーを記録する。
• 確認が終わるまで受付や自動処理を再開する条件を管理する。

5. 「戻った」ではなく、利用者の操作で完了を判断する

トップが表示されるだけでなく、主要記事、添付画像、管理画面、必要なフォームや購入機能を確認します。テスト送信や購入は関係者と条件を決め、実際の営業成果に混ぜないようにします。キャッシュが古い内容を見せている可能性も切り分けます。

完了記録は「復元元／開始・終了時刻／戻した範囲／保全した新規データ／確認結果／未確認事項」。更新が原因の場合は更新作業の手順へ戻り、安全に更新を再適用する条件を決めます。古い状態に戻したまま保守を終えないでください。

資料の確認日：2026-09-19。作業表と記入例は当サイトが作成した整理用のものです。

復元計画の記入例

表は横にスクロールできます。

表の数字は記入の例です。自分のサーバーのバックアップの保存期間や方法は、契約しているサービスの案内で確認してください。

復元の練習で確かめること

1. バックアップのファイルを、本番とは別の場所に戻せるか。
2. 戻したサイトで、トップページと記事、画像が表示されるか。
3. 管理画面にログインできるか。
4. 戻すのにかかった時間。
5. 戻した時点より新しい投稿や問い合わせが、どこに残っているか。

練習は半年に1回など、日を決めて行います。年間の作業の予定はホームページ公開後の年間運用カレンダーでまとめています。