WordPressの更新後に画面が真っ白になった、テーマを編集したら表示が崩れた、記事や画像を誤って消した。バックアップが残っていても、すぐにサイト全体を戻すのは危険です。古いデータベースを復元すると、障害後に届いた問い合わせ、注文、コメント、会員登録まで消えることがあります。
安全な復元で大切なのは、復元ボタンの場所よりも、いつの状態へ、ファイルとデータベースのどちらを戻すかを先に決めることです。現在の状態を保存し、失われる差分を確認してから、サーバー、バックアッププラグイン、手動復元の順に扱える方法を選びます。
EC、予約、会員、問い合わせフォームがあるサイトは、古いデータベースを丸ごと戻す前に、障害後に増えたデータを必ず保全してください。差分の取り出し方が分からない場合は、自分で全面復元せず、サーバー会社または保守担当へ相談する方が安全です。
先に結論｜現在を保存してから必要な範囲だけ戻す
- 新しい更新・編集・投稿を止める
- 障害に気づいた日時と、最後に正常だった日時を記録する
- 現在のファイル、データベース、ログを別名で保存する
- 壊れた範囲がファイル、データベース、両方のどこかを切り分ける
- 戻すと失われる注文、問い合わせ、コメント、会員データを確認する
- 復元元と同じサーバー機能・プラグインを優先する
- テスト環境で試せるなら、本番より先に復元テストを行う
- 復元後に表示、管理画面、データ、フォーム、メール、計測を確認する
WordPress公式のバックアップ資料では、一般的なWordPressサイトを完全に戻すにはファイルとデータベースの両方が必要と説明されています。ファイルにはテーマ、プラグイン、画像、設定ファイルなどがあり、データベースには投稿、固定ページ、コメント、各種設定などが入ります。
ただし、毎回両方を戻す必要はありません。復元範囲を広げるほど、正常な部分や新しく追加されたデータまで巻き戻す可能性が高くなります。
復元前に8項目を記録する
- 異常に気づいた日時とタイムゾーン
- 最後に正常だった日時
- 直前に行ったWordPress、テーマ、プラグイン、PHP、DNSの変更
- 影響するURL、管理画面、フォーム、ログインなどの範囲
- 表示されたエラー文、HTTP状態、スクリーンショット
- 利用できるバックアップの取得日時と保存先
- バックアップにファイルとデータベースの両方があるか
- 障害後に増えた注文、予約、問い合わせ、コメント、会員、投稿
「昨日までは正常だった」だけでは、どの世代を戻すべきか判断しにくくなります。たとえば午前10時にプラグインを更新し、11時に異常へ気づいたなら、10時より前のバックアップを候補にします。ただし、その後に受け付けたデータがあれば、全面復元前に別途保存が必要です。
現在の状態にも、原因を調べるログや復元後に必要な新規データが残っています。壊れているように見えても、上書き前にファイルとデータベースを別名で保存してください。バックアップ自体の作り方は、WordPressバックアップの取り方で確認できます。
最初に決めるのは復元方法ではなく復元範囲
| 症状・直前変更 | 最初に検討する範囲 | 戻す前の注意 |
|---|---|---|
| テーマや子テーマの編集後に崩れた | 変更したテーマファイル | 親テーマまで戻さない |
| プラグイン更新後にエラー | 原因候補のプラグイン | 設定やDB変更の有無を確認 |
| 画像を誤削除した | uploads内の対象画像と添付情報 | 同名ファイルの上書きに注意 |
| 投稿・固定ページだけを戻したい | リビジョン、エクスポート、対象DBデータ | サイト全体のDB復元は最後 |
| DB破損・接続先の誤変更 | DBまたは接続設定 | 現行DBと接続情報を保存 |
| 複数のファイル・設定が壊れた | ファイルとDBの同時点セット | 取得時刻のずれを確認 |
| 乗っ取り・マルウェアが疑われる | 正常時点のセットを候補にする | 侵入経路を塞がず復元だけで終えない |
投稿本文を数行消しただけなら、バックアップよりWordPressのリビジョンで戻せる可能性があります。PHP変更ならPHPを元の版へ戻す、コード追加なら追加箇所だけを外すなど、原因と復元対象が一対一で分かる場合は最小範囲の切り戻しを優先します。
一方、ファイルとデータベースが同時に変わる更新や移行では、片方だけ古い状態へ戻すと整合が崩れることがあります。セットで取得した同時点のバックアップを使い、復元後にWordPressの更新要求やプラグインのDB更新が出ていないか確認します。
3つの復元方法から安全に扱えるものを選ぶ
| 方法 | 向いている状況 | 長所 | 主な注意 |
|---|---|---|---|
| サーバー提供の復元 | サーバー側に正常な自動・手動バックアップがある | 管理画面に入れなくても使える場合がある | 保存期間、復元単位、料金、メール範囲がサービスごとに違う |
| バックアッププラグイン | 同じプラグインで完全なセットを保存している | WordPress管理画面から扱いやすい | 管理画面へ入れること、容量、形式、保存先への接続が必要 |
| 手動復元 | ファイル一式とDBのダンプがあり、構成を理解している | 対象や手順を細かく制御できる | 上書き、DB選択、接続情報、権限の誤りが大きな事故になる |
初心者は、利用中サーバーの復元機能があれば最初に確認します。次に、バックアップを作成したプラグイン自身の現行公式手順を使います。別のプラグインへ無理に読み込ませたり、仕組みを理解しないままFTPとphpMyAdminで全面上書きしたりしないでください。
どの方法でも、復元を実行する前に「復元対象」「取得日時」「現在データの保存」「所要時間」「作業中の公開状態」を確認します。容量が大きいサイトは処理中にタイムアウトしても、裏で復元が続いている場合があります。途中で同じ操作を繰り返さず、サーバーの処理状況や公式ガイドを確認します。
サーバーの自動バックアップから戻す手順
- サーバー管理画面で対象サーバー、ドメイン、サイトを確認する
- 自動バックアップの一覧と取得日時を確認する
- Web、データベース、メールなど復元単位を読む
- 障害前で最も新しい候補を選ぶ
- 現在状態の別バックアップがあることを確認する
- 必要な範囲だけ復元する
- 処理完了の表示やメールを待つ
- キャッシュを削除し、後述の復元後チェックを行う
たとえばConoHa WINGは、2026年8月24日時点の公式サポートで、過去14日間分を自動取得し、Web・Mail・DBを項目ごとにリストアできると案内しています。保存期間や対象は変更される可能性があるため、実行前に現在の管理画面と公式情報を確認してください。
サーバーを選ぶ段階から復元性を重視したい場合は、レンタルサーバーを見直すべきタイミングと、ConoHa WINGを申し込み前に確認するポイントも判断材料になります。バックアップがあることだけでなく、管理画面に入れないときも戻せるか、DBだけ戻せるか、サポート範囲はどこまでかを確認します。
バックアッププラグインから戻す手順
- バックアップを作成したプラグイン名と版を確認する
- 公式ページで現在の復元条件、対応形式、容量制限を確認する
- バックアップ一式が揃っているか確認する
- 外部ストレージを使う場合は接続先と権限を確認する
- 本番サイトの現在状態を別に保存する
- 復元対象を選び、処理中は編集や更新を止める
- 完了メッセージとログを保存する
- 同じバックアップを連続実行せず、表示と管理画面を確認する
プラグインの無料版・有料版で復元機能や保存先が変わることがあります。古い解説記事の画面や「無料版では必ず手動」という説明が、現在も正しいとは限りません。必ずプラグイン公式の最新版資料を基準にしてください。
手動でファイルとデータベースを戻す前の判断
WordPress公式の一般的な復元順は、ファイルを先に戻し、その後でデータベースをインポートする形です。移行などでDB名、ユーザー名、パスワード、ホスト名が変わった場合は、wp-config.phpの接続情報も一致させます。
- ファイル一式にテーマ、プラグイン、uploads、設定ファイルが含まれているか
- DBダンプの取得日時がファイルと大きくずれていないか
- インポート先が本当に対象サイトのDBか
- 現在DBを上書き前にエクスポートしたか
- URLやパスが変わる移行を同時に行っていないか
- 作業後にファイル権限と所有者を元へ戻せるか
phpMyAdminのインポートは、選んだデータベースをバックアップ時点へ戻す操作です。対象DBを取り違えたり、現行DBの保存なしに実行したりすると、別サイトや新規データを失うおそれがあります。少しでも構成が不明なら、手動復元ではなくサーバー会社へ相談してください。
復元後は7領域を確認する
| 領域 | 確認する内容 |
|---|---|
| 公開表示 | トップ、主要記事、固定ページ、404、PC・スマホ、HTTPS |
| 管理画面 | ログイン、更新通知、サイトヘルス、ユーザー、パーマリンク |
| コンテンツ | 投稿、固定ページ、メニュー、ウィジェット、カテゴリ、最新更新 |
| 画像・ファイル | アイキャッチ、本文画像、PDF、ダウンロード、リンク切れ |
| 入力・送信 | 問い合わせ、メール、コメント、注文、予約、会員登録 |
| 速度・キャッシュ | キャッシュ削除、CDN、表示崩れ、異常なリダイレクト |
| 計測・検索 | GA4、Search Console、広告タグ、robots、サイトマップ |
トップページが開いただけで復元完了にしないでください。投稿は戻っていても画像が欠ける、管理画面は開いてもフォームメールが送れない、公開表示は正常でも計測タグが古い状態へ戻る、といった差が起こり得ます。
復元前に作ったチェック表と照らし、正常・未確認・異常を分けます。異常が残る場合は、さらに古い世代をすぐ重ねて復元せず、復元ログ、サーバーログ、エラーの変化から原因を確認します。
復元しても直らないときの切り分け
| 復元後の症状 | 確認する場所 | 次の判断 |
|---|---|---|
| 同じエラーが出る | バックアップ取得時点、サーバー・PHP・DNSなど対象外の変更 | 復元範囲外の原因を調べる |
| DB接続エラー | DB名、ユーザー、パスワード、ホスト、DB稼働 | 接続情報を推測変更せず確認する |
| 画像だけ欠ける | uploads、URL、ファイル権限、CDN | 対象ファイルと参照先を照合する |
| 古い内容が表示される | ブラウザー、WordPress、サーバー、CDNキャッシュ | 一層ずつキャッシュを削除する |
| ログインできない | URL、Cookie、ユーザー、メール、復元DBの時点 | 公式のパスワード再設定へ進む |
| 不審な転送が再発 | 改ざん、管理者、テーマ・プラグイン、端末、アクセス情報 | 侵害対応へ切り替える |
重大なエラーが続く場合は、WordPressの重大なエラーの直し方、DB接続の問題はデータベース接続確立エラーの確認順へ進みます。乗っ取りや改ざんが疑われる場合は、次のWordPress乗っ取り・改ざん時の対処法に切り替えてください。
よくある質問
バックアップがあれば必ず元に戻せますか？
必ずとは言えません。ファイルかDBの片方しかない、取得途中で壊れている、保存時点が古い、暗号鍵や外部サービス設定がない場合があります。バックアップの存在だけでなく、範囲、日時、サイズ、復元方法、テスト結果まで確認します。
最新のバックアップを戻せばよいですか？
最新が正常とは限りません。不具合や改ざんがバックアップ取得前から始まっていれば、その状態も保存されています。最後に正常だった時刻と、異常へ気づいた時刻の間を確認して候補を選びます。
データベースだけ復元してもよいですか？
DBだけに原因があり、ファイルとの整合を確認できる場合は候補になります。ただし、更新でファイルとDBの両方が変わった場合や、DB復元後に新しい注文・問い合わせが消える場合は慎重な判断が必要です。
管理画面に入れないと復元できませんか？
サーバー側の自動バックアップやファイル・DB管理機能は、WordPress管理画面に入れなくても使える場合があります。利用中サーバーの公式サポートと管理画面を確認してください。
まとめ｜復元前後の確認までを一つの作業にする
WordPressの復元は、バックアップを選んでボタンを押すだけの作業ではありません。現在を保存し、正常だった時点と失われる差分を確認し、必要な範囲だけを戻します。
- 現在の状態とログを保存する
- ファイル、DB、両方のどこを戻すか決める
- 新しい注文・問い合わせなどの消失を防ぐ
- サーバー、同じプラグイン、手動の順に安全な方法を選ぶ
- 復元後は表示、管理、データ、送信、計測まで確認する
まだバックアップの範囲や保存先が曖昧なら、まず更新前に戻せるバックアップを作る基本手順を整えてください。復元機能、サポート、テスト環境が不足して毎回の復旧に不安が残る場合は、サーバー見直しも運用改善の一部です。