WordPressのバックアップ確認｜更新前に復元できる範囲を確かめる

01．リビジョン・XML・サイトのバックアップを分ける

「前の状態に戻す」機能でも、戻せる対象はそれぞれ違います。
まず、手元にあるものが次のどれに当たるかを確認してください。

保存方法ごとの役割と確認点

WordPress公式のリビジョン説明では、保存した下書きや公開内容の更新履歴を扱っています。
記事の編集を戻す際に役立ちますが、テーマやプラグインを含めた復旧用一式にはなりません。
残る履歴の数も、サイトの設定によって変わります。

管理画面のエクスポートで作られるXMLは、WXRというコンテンツ書き出し用の形式です。
書き出し対象に応じて、投稿・固定ページ・コメント・カスタムフィールド・カテゴリー・タグ・ユーザーなどが含まれます。
ただし、XMLがあるだけで画像ファイル本体やテーマまで保存できたとは判断できません。
対象と絞り込み条件は、WordPress公式のエクスポート説明で確認できます。

一般的なサイトを全体復旧するには、ファイルとデータベース（DB）の両方が必要です。
DBは記事・コメント・多くの設定を管理し、ファイルには画像・テーマ・プラグインなどがあります。
通常、WordPressのフォルダーをコピーするだけではDBは保存されません。
この区別は、WordPress公式のバックアップ案内でも説明されています。

02．保存手段ごとに、最新の成功日時を調べる

最初から新しいプラグインを増やす必要はありません。
現在使っている保存手段を、サーバーの自動保存、プラグイン、手動コピーに分けて書き出します。
複数ある場合は、保存対象や日時が混ざらないよう別々に記録してください。

• サーバーの自動保存：契約中の管理画面で、対象サイトと取得済みの一覧を確認する
• プラグイン：設定した予定時刻に加え、実際の取得履歴・結果・保存対象を確認する
• 手動コピー：保存した場所、作成日時、ファイルとDBの有無を確認する

プラグインの「有効」表示や、自動保存の設定だけでは、直近の取得成功は分かりません。
一覧やログで、最後に成功した取得日時と、失敗・警告の有無を読み取ります。
最新の処理が失敗している場合は、以前の成功分が今も残っているかも要確認です。

複数のサイトを運営しているなら、対象のドメインを先に照合します。
日時はタイムゾーンも記録すると、別画面の記録と比較しやすくなります。
表示の意味が分からない箇所は、成功と推測せず「未確認」と残しましょう。

03．ファイルとDBの対象・日時・除外を照合する

ファイルとDBを、同じ復旧に使う組み合わせとして確認します。
取得日時が違う場合は、その間に追加・変更した記事、画像、設定をメモしてください。
記事は新しくても対応する画像が古い保存分にない、といった食い違いを見つけるためです。
日時が近いことだけで、データの整合性や復元成功まで確認できたとは扱いません。

対象欄には「全部」だけでなく、画像、テーマ、プラグイン、DBなどを分けて記入します。
独自に変更したファイルや設定ファイルがある場合は、その保存場所も確認対象です。
製品の対応範囲と、実際に選択した対象・除外設定を照らし合わせましょう。

例えば、UpdraftPlus公式の保存範囲では、無料版の対象をwp-content内のファイルとWordPressのDBとしています。
wp-config.php、変更したWordPress本体、通常の構成外にある独自ディレクトリなどは、Premium側の説明です。
そのため、導入済みというだけで「サイト上の全ファイルが保存される」とは扱えません。

ここで有料版への変更を決める必要はありません。
利用版・設定・除外・取得済みデータを確認し、不足があれば既存のサーバー機能で補えるか調べます。
読み方が難しければ、対象と警告内容を整理して公式サポートへ相談する方が判断しやすくなります。

04．保持条件と、管理画面に入れないときの復元入口を確かめる

「7日間保持」と「7世代保持」は別の条件です。
世代数は残すバックアップの数なので、取得頻度が変わると、さかのぼれる期間も変わります。
保存先、保持条件、今ある保存分の期限をそれぞれ記録してください。
設定だけでなく、実際の一覧に残る最古・最新の保存日時も確かめます。

UpdraftPlus公式のスケジュール説明では、ファイルとDBの取得間隔・保持数を別々に設定できます。
保持数の上限に達すると古い保存分が削除されるため、片方の設定だけで両方の期間を判断できません。
予定作業後も必要な保存分が残るか、現在の一覧と設定を合わせて確認します。

サーバーの仕様も、実契約の画面で確かめます。
エックスサーバー公式のWeb・メール領域の復元手順は14日間保持を案内しています。
一部の旧サーバーは7日間のため、同社の案内でもサーバーパネルでの確認が必要です。
Web領域を戻す手順と、DBを戻す手順・対象は別に確認してください。

次に、WordPressへログインできなくても使える復旧入口をメモします。
サーバー管理画面、保存先へのアクセス方法、公式手順や窓口が候補です。
サイトと同じサーバー内にだけ保存している場合は、そのサーバーに入れないときの取得方法も調べておきましょう。

確認目的で、本番サイトの「復元」を試しに押さないでください。
上記のエックスサーバーの手順では、対象ファイルの上書きに加え、保存時点にない新しい対象ファイルの削除も案内されています。
復元は現在のデータを変える操作なので、対象と失われる差分を理解してから行う必要があります。

05．確認の段階を分けて、復旧準備シートへ記録する

「取得成功」と「実際に戻して動作を確認した」は、異なる確認結果です。
副業スタックでは、次の3段階を分けて残す方法を提案します。
一覧を見ただけの状態を、復元テスト済みとして記録しないためです。

1. 画面で確認済み：対象サイト、取得日時、成功・警告の表示を確認した
2. 保存内容を確認済み：取得済みデータの構成や必要ファイルを、公式手順に沿って確認した
3. 分離環境で復元確認済み：本番と分けた検証環境で復元し、記事・画像・管理画面などを確認した

保存内容が確認できても、実際の復元成功を保証するものではありません。
復元を検証する際は、本番を上書きしない構成と公式手順を確認し、不明なら担当者へ依頼してください。
検証環境で確認した場合も、環境・日付・確認範囲を残すと、後の変更との差が分かります。

下のシートをメモへコピーし、保存手段ごとに1組ずつ記入します。
空欄を推測で埋めず、未確認点と次の確認先まで書くのが使い方です。
パスワード、認証コード、APIキー、DBの認証情報は記入しないでください。

06．3つの仮の記入例で、次の確認を決める

以下はすべて説明用の仮定で、実測や特定サイトの運用記録ではありません。
同じ製品でも設定によって対象が変わるため、例の結果を自分のサイトへそのまま当てはめないでください。

例1：XMLを書き出しただけ

確認済みにできるのは、コンテンツの書き出しファイルがあることです。
ファイルとDBをそろえた全体復旧の準備は「未確認」と記入します。
次は現在のサーバーや保存機能で、対象と取得状況を確認してください。

例2：同じ取得予定でDBは成功、ファイルは失敗

DBの成功ログがあっても、今回必要なファイルの保存まで成功したとは書けません。
失敗ログと対象を確認し、公式手順や窓口に沿って原因を解消します。
必要な保存範囲がそろうまでは、更新の準備が完了したと判断しないようにしましょう。

例3：09:00の取得後、09:30に記事と画像を追加

10:00に更新する想定なら、09:30の追加分を差分として記録します。
09:00の状態へ戻す場合、その記事や画像を失う可能性があるためです。
更新前に差分を保護する方法を公式手順で確かめ、追加取得する場合は対象と成功日時を記録してください。

07．未確認点を解消してから、予定していた作業へ進む

シートで目指すのは「復元できるはず」を、根拠と未確認点に分けることです。
対象・日時・復元入口に不足があれば、必要な公式ページや担当者へ確認してから作業を判断します。
ただし、緊急のセキュリティ更新を長く放置する理由にはせず、対応可能な窓口へ速やかに相談してください。

準備後にテーマを変更する場合は、テーマ導入・変更の手順と表示確認へ進めます。
更新を含む運営上のリスクも整理したい場合は、WordPressで失敗する原因と予防策を確認してください。