原著者：釘田泰子／改訂：WEBセールス実践協会／改訂日：2026年10月8日

バックアップがあっても、戻す場所を間違えると、いま動いているサイトを上書きしてしまいます。復元は、最初に元のファイルとDBを消す作業ではありません。まず戻したい時点と保存範囲を決め、元データを残したまま別環境で試します。

どの状態まで戻すのかを決める

表示が崩れた直前、更新前、誤削除前など、復元する時点を記録します。その後に追加された記事・コメント・問い合わせがある場合、古いDBを戻すと失われることがあります。現在の状態も保存し、復元後に取り込む必要がある追加データを把握してください。

改ざんが疑われる場合は、感染前のバックアップを特定し、侵入原因やアカウントの安全性も確認します。バックアップを戻すだけで原因が解消したとは判断しません。

バックアップの不足を先に調べる

UpdraftPlusのDB・プラグイン・テーマ・アップロード・その他を、同じ日時のまとまりで確認します。分割されたZIPも全部必要です。WordPress本体、wp-config.php、.htaccessを含む範囲かを確認し、不足分があれば元サーバーから追加保存します。

保存済みのZIPとgzipが読み取れることは、破損の確認になります。ただし、PHPの互換性や画像の参照先まで検査できたわけではありません。復元テストを行う理由は、ここを別に確かめるためです。

検証環境の準備は復元より先に行う

• DBを分ける：検証専用のDBと接続ユーザーを用意し、本番DBの接続情報をコピー先で使いません。接続先を画面と設定の両方で照合します。
• 非公開にする：閲覧制限をかけ、未ログインの状態からアクセスできないことを確認します。検索エンジンへの非表示設定だけではアクセス制限の代わりになりません。
• メールを捕捉する：復元したサイトから顧客や管理者へ送られないよう、検証用の保管先に捕捉する仕組みを先に設定します。
• 外部処理を分離する：自動投稿、予約処理、外部APIへの書き込み、本番Driveのバックアップ実行・世代整理を止めます。DBを復元すると連携設定も戻るため、管理画面を開く前から動かない仕組みが必要です。
• 実行環境を合わせる：復元したい時点で動いていたPHP等の条件を確認します。古いテーマをそのまま新しいPHPで起動できるとは限りません。

当サイトでは、本番とは独立したDBと非公開の検証場所を用意し、メール捕捉と外部通信・Drive・自動予約処理の停止を確認してから検証しました。これらの設定は、単にWordPressのURLを書き換えるだけでは実現しません。

UpdraftPlusでの復元の流れ

1. 復元先が検証環境であることを確認し、互換性のあるWordPressとUpdraftPlusを準備します。
2. 「バックアップファイルをアップロード」から、保管した対象日時の一式を登録します。表示された種類とファイル数を保存一覧と照合します。
3. 対象の「復元」を開き、戻す項目を選びます。画面が示す不足ファイル、バージョン、DB等の警告を確認してから進めます。
4. 完了後、復元ログを保存します。復元された設定により、本番URLや本番の外部連携が有効になっていないかを確認します。
5. 別URLへ移す場合は、移行機能の対応範囲を確認するか、シリアライズされた設定を壊さない方法でURLを置換します。SQLの文字列を単純に一括置換すると設定が壊れる場合があります。

サーバー全体の復旧や別URLへの移行では、UpdraftPlusの復元画面だけでは終わらないことがあります。無料版・有料版の対応範囲と、サーバー側の復元手順を区別してください。

完了表示の後に確認すること

検証に通るまで元環境とバックアップを残します。エラーが出たら、発生した操作・時刻・ログを記録し、検証環境で原因を切り分けます。復元のために元環境の全ファイルやDBを先に削除しないでください。

本番へ戻す際の確認

本番作業の直前に最新バックアップを追加し、編集や注文が増えるサイトでは一時停止の範囲を決めます。復元後にDB接続エラー、編集不能、主要画像の欠落が解消しない場合は、作業前に保存した状態へ戻す条件に従います。DBだけ、またはファイルだけを戻すと組み合わせが不整合になる場合があるので、一式と実行環境の組み合わせを記録しておきます。

関連資料

• UpdraftPlus公式：WordPressの復元
• UpdraftPlus公式：手動復元の範囲