WordPressのバックアップは、作成しただけでは安心できません。トラブルが起きたときに必要な状態へ戻せて、初めて役割を果たします。しかし、復元は現在のファイルやデータベースを過去の状態に置き換える作業です。対象や日時を誤ると、直したかった不具合は残ったまま、直近の投稿や注文、問い合わせだけが消えることもあります。
大切なのは、復元ボタンをすぐ押すことではありません。何が壊れているのか、どの時点へ戻すのか、何を戻すのか、現在の状態を退避したか、復元後に何を確認するかを先に決めます。WordPress公式ドキュメントでも、更新やサーバー設定の変更前には最新のバックアップを作成し、問題が起きた場合に戻せるようにする考え方が示されています。
この記事では、バックアッププラグインの比較ではなく、実際に復元を判断するときの注意点に絞ります。レンタルサーバーの復元機能、バックアッププラグイン、手動バックアップのどれを使う場合でも共通する確認事項を、初心者が作業順を迷わないように整理します。
復元は最後の手段ではなく影響範囲を選ぶ作業
復元という言葉から、サイト全体を以前の状態へ戻す操作を想像しがちです。実際には、復元対象を細かく分けられる場合があります。WordPressの主な構成要素は、データベース、アップロード画像、テーマ、プラグイン、WordPress本体、設定ファイルです。障害の原因が一部だけなら、必要な範囲だけを戻す方が失う情報を抑えられます。
たとえば、テーマの編集直後に画面が崩れた場合は、テーマファイルだけを戻せば解決する可能性があります。プラグイン更新後にエラーが出た場合は、そのプラグインを停止する、または更新前の版へ戻す方法が先に検討できます。一方、誤って記事を削除した場合はデータベースが関係します。原因と復元対象が一致していなければ、サイト全体を戻しても問題は解決しません。
復元前には「何が起きたか」「いつから起きたか」「直前に何を変えたか」を短く記録してください。エラー画面、発生時刻、更新したテーマやプラグイン、操作したユーザー、影響しているページを控えると、戻す範囲と時点を判断しやすくなります。原因が不明なまま本番環境を何度も復元すると、状況の比較が難しくなります。
データベースに含まれる情報を理解する
データベースには、投稿、固定ページ、コメント、ユーザー情報、各種設定、プラグインが保存する情報などが入っています。ECサイトや予約サイト、会員サイトでは、注文、予約、会員の更新情報も含まれることがあります。古いデータベースへ戻すと、バックアップ取得後に追加された情報が消える可能性があります。
一般的な企業サイトやブログでも、問い合わせ履歴をWordPress内に保存するプラグイン、フォーム送信数、リダイレクト設定、SEO設定などがデータベースに入る場合があります。見た目の不具合を直すためにデータベースまで戻す必要があるかは慎重に判断します。
ファイルに含まれる情報を理解する
ファイル側には、アップロード画像、テーマ、プラグイン、WordPress本体、設定ファイルなどがあります。画像だけが欠けたときにデータベースだけを戻しても、実体の画像ファイルがなければ表示は直りません。反対に、記事本文が消えたときに画像フォルダだけを戻しても本文は復元できません。
ファイルとデータベースは互いに関係しています。画像の登録情報はデータベースにあり、画像本体はアップロードフォルダにあります。両方を別々の日時から戻すと、管理画面には画像情報があるのに実体がない、または実体はあるのに管理画面から探せない状態が起こり得ます。
復元前に確認するバックアップの条件
バックアップファイルが存在するだけで、復元に使えるとは限りません。取得日時、対象範囲、保存場所、ファイルの完全性、対象サイト、WordPressやPHPなどの環境差を確認します。特に複数サイトを管理している場合は、似た名前のバックアップを取り違えないようにします。
戻したい状態より前のバックアップを選ぶ
不具合が発生した時刻より後のバックアップには、不具合の原因も含まれている可能性があります。たとえば更新直後からエラーが出たなら、更新より前に取得されたバックアップが候補です。マルウェア感染が疑われる場合は、症状に気づいた直前ではなく、侵入前と考えられる時点まで遡る必要があります。
ただし古いほど安全とは限りません。古いバックアップへ戻すほど、その後に追加されたコンテンツや設定を失う範囲が広がります。候補ごとに「戻せる可能性」と「失う可能性」を並べ、最も新しく、かつ問題が入っていないと判断できる時点を選びます。
取得日時とタイムゾーンを確認する
サーバー管理画面、WordPress、バックアップサービスで表示される時刻の基準が異なる場合があります。日本時間だと思って選んだバックアップが、実際はUTC表記で数時間ずれていることもあります。更新や障害の発生時刻と比較するときは、日時だけでなくタイムゾーンも確認します。
自動バックアップが毎日作成される契約でも、取得時刻は深夜とは限りません。記事公開、フォーム送信、注文が多い時間帯と重なる場合は、バックアップ後に増えた情報を別途保全する必要があります。
バックアップ対象に不足がないか確認する
サービスによって「バックアップ」の範囲は異なります。ファイルだけ、データベースだけ、WordPress一式、サーバー領域全体など、対象を確認してください。メール、アクセスログ、DNS設定、SSL設定はWordPressバックアップの対象外であることが一般的です。必要なものが含まれていると決めつけないことが大切です。
プラグインで作成したバックアップも、保存容量の上限、除外設定、途中エラーによって一部が欠ける場合があります。完了通知だけでなく、作成ログ、ファイルサイズ、構成ファイル、保存先への実在を確認します。可能なら復元テスト済みのバックアップを優先します。
バックアップを本番サーバーの外にも保管する
本番サーバーと同じ場所にしかバックアップがないと、サーバー障害、契約停止、誤削除、侵害によって同時に失うおそれがあります。復元作業前には、利用予定のバックアップを手元または別の安全な保存先へ複製し、元データを直接加工しないようにします。
保存先には個人情報や認証情報が含まれる可能性があります。共有範囲を必要最小限にし、公開リンクを作らず、保管期間と削除方法も決めます。外部ストレージを使う場合は、暗号化やアクセス制御、利用規約も確認してください。
作業開始前に現在の状態を必ず保全する
すでに壊れているように見えても、現在の状態には復旧に必要な情報が残っています。復元を始める前に、現在のファイルとデータベースを新しくバックアップします。これは元に戻すためだけでなく、古いバックアップから復元した後に、直近の記事、画像、注文、問い合わせなどを救い出すためにも役立ちます。
現在のバックアップには「復元前」「障害発生後」など、正常なバックアップと混同しない名前を付けます。作成時刻、対象範囲、作業者、障害の概要もメモします。バックアップ一覧で最も新しいという理由だけで、後から誤って復元に使わないためです。
直近の更新情報を別に書き出す
古いデータベースへ戻す場合、バックアップ取得後の情報が失われます。記事や固定ページは下書きも含めて内容を控え、必要ならWordPressのエクスポート機能や個別コピーで保全します。EC、予約、会員、問い合わせを扱うサイトは、停止時間中に新しいデータが増えない運用も必要です。
復元直前まで注文やフォーム送信を受け付けると、どの情報が新旧どちらにあるのか分からなくなります。メンテナンス表示、受付停止、関係者への連絡などを検討し、作業中のデータ更新をできるだけ止めます。ただしメンテナンス機能を有効にする操作自体が難しい場合は、無理に変更を増やさずサーバー会社や制作者へ相談します。
画面と設定を記録する
復元前の管理画面、主要ページ、エラー表示、利用中のテーマとプラグイン、各バージョン、パーマリンク設定などを記録します。スクリーンショットだけでなく、文字で日時と変更内容も残すと比較しやすくなります。エラーログを確認できる場合は、消える前に保存します。
ログにはサーバーパス、IPアドレス、メールアドレスなどが含まれることがあります。外部へ相談するときは、必要な部分だけを共有し、認証情報や個人情報が映っていないか確認してください。
本番へ直接戻す前にテスト環境で確かめる
可能であれば、ステージング環境、検証用サブドメイン、ローカル環境などで復元を試します。バックアップが展開できるか、管理画面へ入れるか、主要ページが表示されるかを確認してから本番へ適用すると、作業中断のリスクを下げられます。
テスト環境は本番とPHP、データベース、Webサーバー、WordPressの構成が近いほど参考になります。環境差が大きいと、テストでは動いても本番では動かないことがあります。完全に同じ環境を用意できない場合も、バックアップが破損していないか、ファイルとデータベースが揃っているかを確かめる価値はあります。
テスト環境の公開を防ぐ
検証用サイトをインターネット上へ置く場合は、検索エンジンからのアクセス制御だけでなく、Basic認証、IP制限、サーバー側の非公開設定などを使います。「検索エンジンがサイトをインデックスしないようにする」設定だけでは、一般のアクセスを完全に遮断できません。
本番データを複製すると、テスト環境にも個人情報が入る場合があります。必要に応じて匿名化し、メール送信、決済、外部API、通知連携を止めます。テスト中に顧客へメールが届いたり、実際の決済処理が走ったりしないようにします。
復元完了だけで成功と判断しない
ツールに「成功」と表示されても、サイト全体が正常とは限りません。トップページ、代表的な投稿、固定ページ、画像、検索、フォーム、ログイン、管理画面を確認します。ECサイトなら商品、カート、注文管理、決済のテスト範囲も決めます。
ページを一度見ただけでは、キャッシュに残った古い画面を見ている可能性があります。ブラウザ、WordPress、プラグイン、サーバー、CDNのキャッシュを区別し、必要なものだけを削除して再確認します。キャッシュ削除を繰り返す前に、どの層のキャッシュを消したか記録しておくと原因を追いやすくなります。
復元方法を選ぶときの判断基準
復元方法には、レンタルサーバーの自動バックアップ、バックアッププラグイン、手動でのファイルとデータベース復元、制作会社や保守会社への依頼があります。最適な方法は、障害の種類、サイトの重要度、失えるデータ量、停止できる時間、作業者の経験で変わります。
レンタルサーバーの復元機能が向くケース
サーバー会社の機能は、サーバー内のファイルやデータベースを管理画面から戻せることがあり、WordPressへログインできない状況でも使える場合があります。対象範囲、保存世代、復元単位、料金、所要時間は契約によって異なります。自動バックアップがあるから無料で即時復元できるとは限りません。
利用前に、復元によって現在のデータが上書きされるか、復元先を別領域に選べるか、メールや他サイトへ影響するかを確認します。同じサーバー契約内で複数サイトを運営している場合は、対象サイトだけを戻せるのかが重要です。
バックアッププラグインが向くケース
WordPress管理画面へ入れて、プラグインが作成したバックアップが正常に残っている場合は、比較的分かりやすく復元できることがあります。ファイル、テーマ、プラグイン、データベースなどを選べる製品もあります。ただし管理画面へ入れない、PHPエラーでプラグインが動かない、保存先へ接続できない状況では使えないことがあります。
プラグインごとに復元手順と対象が異なるため、必ず利用中製品の公式手順を確認します。別製品の手順を流用したり、バックアップファイルを手動で展開したりすると、想定外の上書きが起こる場合があります。
手動復元を慎重に判断するケース
FTPやSSH、ファイルマネージャー、phpMyAdminなどを使う手動復元は、対象を細かく制御できます。一方で、設置先、データベース名、文字コード、URL、シリアライズされたデータ、ファイル権限など、確認項目が多い方法です。誤操作すると復旧範囲が広がるため、初心者が本番環境で手順を試しながら進める方法には向きません。
WordPress公式の上級者向けドキュメントでも、データベースやサーバー設定を扱う前のバックアップと、管理対象を理解した作業が重視されています。手順の意味を説明できない箇所がある場合は、サーバー会社や制作・保守担当者へ依頼する判断が安全です。
専門家へ依頼した方がよいケース
注文、予約、会員、決済を扱うサイト、長時間停止できないサイト、感染や改ざんが疑われるサイト、複数システムと連携するサイトは、単純な巻き戻しでは済まないことがあります。証拠保全、原因除去、データ差分の統合、パスワード変更、再発防止まで含めた対応が必要です。
依頼時には、障害発生時刻、直前の変更、利用可能なバックアップ、サーバー情報、保全したログ、失ってはいけないデータ、許容停止時間を伝えます。復元の実施だけでなく、復元前の保全、復元後の確認、原因調査が作業範囲に含まれるかを確認してください。
本番環境で復元するときの安全な進め方
作業順は、状況の記録、現在のバックアップ、更新停止、復元対象と時点の確定、復元、キャッシュ整理、動作確認、データ差分の反映、監視という流れが基本です。ツールによって画面は異なりますが、判断の順番は共通しています。
作業時間と連絡方法を決める
アクセスや更新が少ない時間を選び、関係者へ開始予定、影響範囲、完了連絡の方法を共有します。復元が長引いた場合の判断時刻も決めておくと、場当たり的な作業を避けられます。外部の担当者がいる場合は、誰が最終判断をするか明確にします。
一度に複数の変更をしない
復元と同時にWordPress本体、テーマ、プラグイン、PHPをまとめて更新すると、正常化した理由や新しい不具合の原因が分からなくなります。まず選んだバックアップを戻して確認し、その後に必要な更新を一つずつ進めます。
処理中に画面を閉じたり再実行したりしない
復元処理はデータ量によって時間がかかります。反応がないように見えても、同じ操作を重ねると競合する可能性があります。進行状況、ログ、サーバー負荷を確認し、製品の案内にある待機時間を超えた場合に限って次の判断をします。
エラーが出た地点を記録する
失敗したときは、エラーメッセージ、対象、時刻、完了した工程を記録します。すぐに別のバックアップを重ねて復元すると、どの操作が現在の状態を作ったのか分からなくなります。現在の状態を再度保全し、原因を確認してから再実行します。
復元後に確認する項目
復元後は、表示できるかだけでなく、データ、管理機能、外部連携、セキュリティを確認します。優先順位は、サイトの目的に合わせて決めます。問い合わせ獲得が目的ならフォーム、ECなら注文と決済、会員サイトならログインと権限を先に確認します。
公開ページと管理画面
トップページ、主要な下層ページ、最新記事、画像、メニュー、スマートフォン表示を確認します。管理画面では、投稿一覧、固定ページ、メディア、ユーザー、テーマ、プラグインの状態を見ます。警告や更新要求が表示されても、その場で一括更新せず内容を記録します。
URLと内部リンク
主要ページのURL、パーマリンク、画像URL、リダイレクト、サイト内検索を確認します。データベースを別環境で復元した場合は、URLが検証環境のまま残ることがあります。単純な文字置換では壊れるデータもあるため、専用の安全な方法を使う必要があります。
フォームとメール
問い合わせフォームは、送信完了画面だけでなく、管理者通知、利用者への自動返信、WordPress内の保存、迷惑送信対策を確認します。テストであることが分かる内容を送り、個人情報を使わないようにします。メールが届かない場合は、復元前後で送信設定や認証情報が変わっていないか確認します。
外部サービスと定期処理
アクセス解析、検索管理、CDN、決済、予約、会員、SNS連携、バックアップ先などを確認します。APIキーやWebhookの設定が古い状態へ戻ると、画面は正常でも連携が止まることがあります。定期実行される処理は、二重実行や未実行がないかも見ます。
セキュリティとアカウント
侵害が疑われる場合、復元しただけで安全になったとは判断できません。原因となった脆弱性、侵入経路、不正ユーザー、改ざんファイルが残っていれば再発します。WordPress本体、テーマ、プラグインを信頼できる配布元から適切な状態にし、管理者アカウント、パスワード、認証キー、外部サービスの認証情報を見直します。
古い版への復元は、既知の脆弱性を含む状態へ戻す可能性があります。復元直後にすべてを一括更新するのではなく、まず状態を確認し、バックアップを追加で作成したうえで、互換性を見ながら必要な更新を進めます。
復元をやり直すか切り戻すかの判断
一部のページが直らない、データが足りない、管理画面へ入れない場合は、同じ操作を繰り返す前に止まります。選んだ時点が適切だったか、復元対象が不足していないか、キャッシュを見ていないか、環境差がないかを確認します。
復元前に作成した現在のバックアップがあれば、作業前の状態へ切り戻して別の方法を検討できます。切り戻しにも上書きの危険があるため、現在位置を再度保全してから行います。復元を重ねるほどデータの由来が分かりにくくなるため、各操作の開始と完了を時系列で記録します。
判断に迷う場合は、サイトを一時的に非公開または更新停止にし、専門家へ相談します。停止時間を短くするために急いで操作を増やすより、失ってはいけないデータと利用可能なバックアップを整理する方が、結果的に復旧を早めることがあります。
日頃から復元しやすい状態を作る
安全な復元は、障害が起きる前の準備で決まります。ファイルとデータベースを含むバックアップを定期的に取得し、本番サーバーとは別の場所にも保管します。更新頻度やサイトの重要度に合わせて、必要な保存世代と取得間隔を決めます。
さらに、定期的な復元テストを行います。バックアップファイルを眺めるだけでは、パスワード、保存先の権限、ファイル破損、環境差などの問題に気づけません。検証環境で戻し、管理画面、主要ページ、画像、フォームまで確認して、手順書を更新します。
復元手順書に残しておきたい情報
手順書には、バックアップの作成元、保存先、対象範囲、保持期間、復元方法、必要な権限、連絡先、確認ページ、切り戻し条件を記載します。認証情報そのものは手順書へ直接書かず、安全なパスワード管理方法と参照権限を決めます。
担当者が変わっても使えるように、製品名だけでなく契約アカウント、対象サイト、サーバー領域、データベースの識別方法を記録します。画面変更に備え、操作ボタンの位置だけでなく「なぜこの確認が必要か」も書いておくと、手順が古くなったときに判断できます。
復元で起こりやすい失敗と避け方
復元時の失敗は、難しい技術操作だけが原因ではありません。対象や順番の思い込みから起こることも多くあります。よくある失敗を先に知っておくと、作業前の確認で止められます。
最も新しいバックアップを無条件で選ぶ
一覧の一番上にあるバックアップは新しく見えるため、そのまま選びたくなります。しかし障害の原因がすでに含まれている可能性があります。発生時刻と取得時刻を並べ、問題が入る前の候補を選びます。感染や改ざんは発見時刻と発生時刻が異なることもあるため、複数世代を残しておくことが重要です。
ファイルだけ、またはデータベースだけで全体が戻ると思う
記事、画像、設定は一か所だけに保存されているわけではありません。投稿本文がデータベースに戻っても、画像ファイルがなければ画像は表示されません。テーマファイルを戻しても、テーマ設定がデータベース側にある場合は以前と同じ表示にならないことがあります。症状と構成要素の対応を確認してから対象を選びます。
正常な現在データまで上書きする
一部の不具合を直すためにサイト全体を復元すると、問題のない直近データも過去へ戻ります。特に注文、予約、会員、問い合わせは後から完全に再現できないことがあります。部分復元が可能か確認し、難しい場合は現在データの書き出しと、復元後の差分反映方法を先に決めます。
復元直後に一括更新する
古い状態へ戻ると、多数の更新通知が表示されることがあります。安全性のため更新は必要ですが、復元確認前に一括更新すると、元の障害と更新による障害を区別できません。まず復元した状態を確認して追加バックアップを作り、影響の大きい更新から一つずつ適用します。
見た目だけで復旧完了と判断する
トップページが表示されても、フォーム、メール、予約、決済、管理画面、定期処理が止まっている可能性があります。サイトの目的から逆算して、収益や顧客対応に直結する機能を優先確認します。確認者、結果、時刻を残し、一定時間はエラーログや問い合わせ状況を監視します。
作業用バックアップを本番領域に置いたままにする
復元用の圧縮ファイルやデータベース書き出しを、公開ディレクトリに置いたままにすると、推測可能なURLから取得される危険があります。作業後は必要な保管先へ移し、公開領域や一時フォルダから削除します。削除前には、別の安全な保存先に必要な世代が残っていることを確認します。
復元前の最終チェック
作業を始める前に、次の項目を確認します。
- 障害の発生時刻と直前の変更を記録した
- 復元する対象と、戻さない対象を決めた
- 利用するバックアップの取得日時とタイムゾーンを確認した
- ファイルとデータベースの対象範囲を確認した
- 現在の状態を新しいバックアップとして保全した
- バックアップ取得後に増えた記事、注文、問い合わせなどを退避した
- 作業中の更新を止め、関係者へ影響を共有した
- 可能な範囲でテスト環境の復元を確認した
- 復元後に確認するページと機能を決めた
- 失敗時の切り戻し条件と相談先を決めた
一つでも不明な項目があり、その不明点がデータ消失や長時間停止につながる場合は、作業を止める判断が必要です。特にデータベースの上書き、複数サイトを含むサーバー全体の復元、感染が疑われる状態からの復旧は、経験のある担当者へ相談してください。
まとめ
WordPressのバックアップ復元で最も重要なのは、操作方法よりも、対象、時点、失うデータ、確認方法を先に決めることです。ファイルとデータベースの役割を分けて考え、現在の状態を保全し、可能ならテスト環境で確かめてから本番へ適用します。
復元後は、表示だけでなく、管理画面、フォーム、外部連携、ユーザー、セキュリティまで確認します。サイトの重要度が高い、失えないデータがある、原因が不明、感染が疑われる場合は、無理に本番環境で試行せず、サーバー会社や制作・保守担当者へ相談する方が安全です。
日頃からバックアップの取得と復元テストをセットで運用すれば、緊急時の判断が速くなります。「バックアップがある」から「必要な状態へ戻せる」へ、運用の目標を一段進めておきましょう。
