WordPressの「バックアップはあるけど、本当に戻せる？」見直したい5つのポイント

「バックアップは自動で取っています」。
そう聞いていても、最後に成功した日時や、どこまで戻せるかをすぐに答えられるでしょうか。

サイトが止まってから保存先を探し始めると、復旧までに時間がかかります。
今回はWordPressの運営担当者が、管理画面や保守の報告書で見直しておきたい5つのポイントをまとめました。

画面名はサーバーやサービスによって異なります。
まずは設定と記録を読むところから始め、不明な点は管理会社へ確認しましょう。
本番サイトで復元ボタンを押す必要はありません。

1. ファイルとデータベースがセットで残っているか

最初に見るのは、バックアップ設定の「対象」「除外項目」と、保存済みデータの一覧です。

一般的なWordPressでは、記事や設定はデータベース、画像・テーマ・プラグインなどはファイル側にあります。
サイト全体を戻すには両方が必要です。WordPress公式のバックアップ解説でも、両者を一つのセットとして扱うことが案内されています。

確認したいのは、「データベースだけ」「画像フォルダだけ」になっていないか。
同じ復元時点に対応するファイルとDBがそろい、必要な対象が除外されていない状態が目安です。
外部ストレージに画像を置いている場合は、その保存分も別途確認してください。

判断できなければ、「このバックアップで、記事・画像・設定・追加機能のデータまで戻せますか」と聞くと具体的です。

2. 最後に成功した日時と、実際の保存データは一致しているか

次に見るのは「実行履歴」「ログ」「通知」です。
自動実行が有効でも、毎回成功しているとは限りません。

直近の完了日時、失敗や警告の有無、保存先への転送結果を確認しましょう。
可能なら保存先の一覧も開き、対応する日時のデータが存在するか照合します。
容量が以前と比べて急に小さくなっていたら、対象漏れなどがないか確認が必要です。
ただし、容量だけで正常とは判断できません。

目安は、予定した間隔で処理が完了し、対応する保存データが見つかること。
成功表示も復元成功の保証ではないため、後述のテストと組み合わせます。

失敗通知の宛先が退職者のままになっていないかも、忘れずに見直しましょう。

3. サイトとバックアップが一緒に失われないか

見る場所は「保存先」「連携先」と、その保存先のアクセス権限です。

本番サーバー内にしかコピーがないと、サーバー障害や侵害時に両方を失うおそれがあります。
本番とは別の場所にもコピーを置き、本番側のアカウントが侵害された場合に、保存分まで削除される構成になっていないか確認することをおすすめします。

別フォルダに移すだけでは、同じ障害への備えにならない場合があります。
保存先の分離に加え、閲覧・削除できる担当者や権限も確認しましょう。

バックアップには個人情報や接続情報が含まれる可能性があります。
公開URLや誰でも開ける共有リンクで保管せず、復旧担当者が必要なときに取り出せる状態を整えることが大切です。

4. 保存する間隔と、残す期間が運用に合っているか

確認するのは「実行スケジュール」「保持期間」「保存世代数」です。
世代とは、過去の異なる時点のバックアップを指します。

たとえば1日1回の取得なら、障害のタイミングによっては、ほぼ1日分の更新が保存されていない可能性があります。
ブログと、注文が随時入るECサイトでは、許容できるデータの損失量が違います。

「何時間前まで戻っても業務を立て直せるか」を決め、その範囲に合う間隔を検討しましょう。
保持期間は、不具合や侵害の発見が遅れる可能性も考えて設定します。
最新の1件だけでは、異常が起きる前の状態が残らないおそれがあります。

古い世代があっても安全とは限りません。
侵害が疑われる場合は、健全な復元点の調査と原因への対処を管理会社に相談してください。

5. 本番から隔離した環境で、戻せることを確認したか

最後に見るのは、復元手順書とテスト記録です。
「誰が対応するか」「どのバックアップを使うか」「どこまで動けば復旧完了か」が分かる状態を目指します。

復元テストは、管理会社と相談し、次の順で進めることをおすすめします。

1. 本番と別のDB・保存領域を使う検証環境を用意し、閲覧者を制限する
2. サイトを動かす前に、顧客宛てメール、実決済、定期処理、外部サービスへの送信を停止またはテスト用に切り替える
3. 使用サービスの手順に従い、選んだ世代のファイルとDBを復元する
4. ログイン、主要ページ、画像、フォーム等をテスト用データで確認し、所要時間と問題点を記録する

検証環境でも、コピーされた個人情報の扱いには注意が必要です。
必要に応じてマスキングし、確認後の保管・削除方法も決めておきましょう。
また、検証環境にしただけで全通知が止まるとは限りません。WooCommerceの公式資料にも、拡張機能のステージングモードとは別にメールが送られる場合の注意があります。

本番のDBを過去の状態で上書きすると、その後の記事や新規注文などを失う可能性があります。
ECサイトは特に、最新の注文・在庫・決済記録をどう保全し、照合するかを復元前に決めてください。WordPress公式のDB復元説明でも、現在のDBをバックアップ時点へ戻す操作であることが示されています。

まずは「最終成功日時」と「保存対象」の2つを開いてみてください。
そこから保存先、保持期間、復元記録まで確認できれば、管理会社への質問も整理しやすくなります。

保守担当者と復旧の範囲を話すときは、戻したいデータの名前があると具体的になります。
「記事・画像・設定・追加機能のデータまで戻せるか」と、手元のバックアップについて聞けます。

※本記事は公式資料を踏まえた一般的な確認ポイントと運用上の提案です。
個別サイトで復元手順を実機検証したものではなく、復元可能性や安全性を保証するものではありません。
資料確認日：2026年10月12日。