Webサイトを復元する方法は、バックアップの取り方によって変わります。レンタルサーバーの自動バックアップ、WordPressプラグイン、手動で保存したファイルとデータベースなど、それぞれ復元手順が異なります。大切なのは、復元前に「どの時点へ戻すか」「ファイルとデータベースの両方がそろっているか」を確認することです。
30秒でわかる結論
- 復元前に「いつの状態へ戻すか」を決める
- WordPressはファイルとデータベースの両方を戻すのが基本
- まずレンタルサーバーの自動バックアップが使えるか確認する
- 復元前に現在の状態もバックアップしておく
- データベースだけ戻すと画像・テーマは戻らない
- 復元後は表示・ログイン・フォーム・SSL・メールを確認する
- 重要サイトでは本番へ直接戻す前にテスト環境で確認する
Webサイトを復元する方法
Webサイトを復元する方法は、大きく3つあります。
| 方法 | 向いているケース |
|---|---|
| サーバー自動バックアップから復元 | 初心者・一般的な障害復旧 |
| WordPressプラグインから復元 | プラグインで定期バックアップしている場合 |
| 手動でファイル・DBを戻す | 移転・高度なトラブル対応 |
ここで伝えたいポイント
最も簡単なのは、レンタルサーバー側の自動バックアップから戻す方法です。まず契約中サーバーに復元機能があるか確認してください。
復元前に最初に確認すること
復元前チェックリスト
- 何が壊れているか
- いつから問題が起きたか
- どのバックアップ世代へ戻すか
- ファイルとDBの両方があるか
- 現在の状態をバックアップしたか
- メールや注文データへ影響しないか
いきなり復元しない
原因を確認せず古いバックアップへ戻すと、最新記事・注文・問い合わせなどを失う可能性があります。まず障害発生時点を特定してください。
復元ポイントはどう選ぶ?
復元では「できるだけ新しいバックアップ」ではなく、「問題が起きる前の正常なバックアップ」を選びます。
具体例
10月20日にプラグイン更新後から不具合が出たなら、10月19日以前の正常なバックアップへ戻すのが候補です。
最新=正解ではない
マルウェア感染や設定ミスに気づくのが数日遅れた場合、最新バックアップにも問題が含まれている可能性があります。
WordPressはファイルとデータベースを戻す
WordPressサイトの復元では、ファイルとデータベースの両方が重要です。
| 対象 | 主な内容 |
|---|---|
| ファイル | 画像、テーマ、プラグイン、WordPress本体、wp-config.phpなど |
| データベース | 記事、固定ページ、ユーザー、設定、コメントなど |
WordPress完全復元 = ファイル復元 + データベース復元
片方だけ戻すと整合性が崩れることがある
古いデータベースと新しいプラグインファイルを組み合わせるなど、時点がずれると不具合が起こる場合があります。できるだけ同じバックアップ時点のセットを使います。
方法1:サーバー自動バックアップから復元
レンタルサーバーに自動バックアップ機能がある場合は、管理画面から復元できることがあります。
正常だった日付を選びます。
Webファイル、データベースなどを確認します。
対象ドメイン・DBを間違えないよう確認します。
トップ、記事、管理画面、フォームを確認します。
初心者はこれでOK
復元機能が用意されているなら、FTPやphpMyAdminで手動作業する前にサーバー管理画面から戻せないか確認してください。
方法2:WordPressプラグインから復元
バックアッププラグインを使っている場合は、そのプラグインから復元できることがあります。
復元前に確認すること
- バックアップファイルが正常に残っているか
- ファイルとDBの両方を含むか
- 外部ストレージへ保存されているか
- 復元対象の日付が正しいか
- 現在のサイトも別途保存したか
管理画面へ入れない場合は使えないことがある
WordPress自体が起動しない場合、プラグイン画面から復元できません。その場合はサーバー側バックアップや手動復元を使います。
方法3:ファイルを手動で復元する
手動復元では、FTP・SFTP・SSHなどを使ってバックアップ済みファイルをサーバーへ戻します。
上書き前に現状を保存します。
対象時点のファイルを準備します。
公開ディレクトリへ戻します。
ファイル・ディレクトリ権限に異常がないか確認します。
画像だけ消えた場合はwp-content/uploadsだけを戻すなど、障害範囲が明確なら部分復元も可能です。
データベースを手動で復元する
データベースは、phpMyAdminやコマンドラインなどからSQLバックアップをインポートして戻します。
DB復元は上書きになる
古いDBへ戻すと、バックアップ取得後に追加された記事、注文、コメント、ユーザー情報などが失われる可能性があります。
損失量を数字で考える
1日20件の注文が入るECサイトを3日前のDBへ戻すと、最大60件分の注文データへ影響する可能性があります。
20件/日 × 3日 = 最大60件
部分復元と全体復元の違い
| 方法 | 向いているケース |
|---|---|
| 部分復元 | 特定画像、テーマ、プラグインだけ壊れた |
| 全体復元 | サイト全体が壊れた、感染範囲が広い |
必要最小限を戻す
原因が特定できているなら、サイト全体を古い状態へ戻すより必要な部分だけ復元したほうが、最新データを失いにくくなります。
復元にかかる時間の目安
復元時間はサイト容量と方法によって変わります。
| サイト規模 | 作業イメージ |
|---|---|
| 1〜5GB | 数十分程度で終わる場合もある |
| 10〜30GB | 転送・展開に時間がかかる |
| 100GB以上 | 数時間以上かかる可能性 |
転送速度10MB/秒で20GBを戻す場合
単純計算では約34分です。
20,000MB ÷ 10MB/秒 = 2,000秒 ≒ 33分20秒
実際には展開・DB復元・検証もあるため、さらに時間を見込みます。
復元後に必ず確認すること
復元後チェックリスト
- トップページが表示される
- 主要記事・固定ページが表示される
- WordPress管理画面へログインできる
- 画像が表示される
- 問い合わせフォームを送信できる
- HTTPSで証明書エラーが出ない
- 内部リンクが正常
- メール送受信が必要なら確認する
- アクセス解析が動いている
復元後にキャッシュを削除する
サイトを復元しても、ブラウザ・WordPressプラグイン・CDNなどに古いキャッシュが残ることがあります。
確認対象
WordPressキャッシュ、サーバーキャッシュ、CDNキャッシュ、ブラウザキャッシュを順番に確認します。
復元失敗と決めつけない
ファイルは戻っていてもキャッシュで古い表示が残ることがあります。別ブラウザやシークレットモードでも確認してください。
マルウェア感染時はそのまま戻さない
改ざん・マルウェア感染からの復元では、正常なバックアップへ戻すだけでなく侵入原因も修正する必要があります。
感染時に追加で行うこと
- WordPress本体・テーマ・プラグインを更新
- 不要なプラグインを削除
- 管理者パスワードを変更
- FTP・SSH・DBパスワードを見直す
- 不審な管理者ユーザーを確認
- WAFやログを確認
原因を残すと再感染する
脆弱性や漏えいした認証情報を修正しないまま復元すると、正常状態へ戻しても再び改ざんされる可能性があります。
本番サイトはテスト復元が安全
売上や問い合わせに関わる重要サイトでは、本番へ直接復元する前にステージングや別環境で確認する方法が安全です。
本番とは別のURL・サーバーを準備します。
ファイルとDBを戻します。
表示、ログイン、フォームなどを確認します。
問題なければ本番復元を行います。
復元に失敗したときの切り戻し
復元作業前に現在の状態をバックアップしておけば、復元後に別の問題が起きても元へ戻せます。
安全な復元 = 過去バックアップ + 作業直前バックアップ
復元前の現状バックアップを必ず取る
壊れている状態でも、原因調査や最新データ救出に使える可能性があります。復元対象を上書きする前に、現在のファイルとDBを保存してください。
サイト別の復元判断
更新頻度が低ければ、直近正常世代へ全体復元しやすいです。
古いDBへ戻す前に、最新記事を退避できないか確認します。
注文・予約データを失うため、可能なら部分復元や専門対応を検討します。
正常世代へ戻すだけでなく、脆弱性・認証情報も修正します。
復元方法を決めるフロー
はい → まず復元機能を確認
はい → プラグイン復元も候補
はい → 部分復元を検討
はい → DB全体の巻き戻しは慎重にする
はい → 復元と原因除去をセットで行う
教科書判定:まずサーバー復元、重要サイトはテストしてから
初心者はサーバー自動バックアップを第一候補にする
一般的な会社サイト・ブログなら、レンタルサーバーの自動バックアップから正常な世代へ戻す方法を第一候補にしてください。復元前には現在の状態を保存し、重要サイトやECではテスト環境で復元確認してから本番へ反映するのが安全です。
よくある質問
Q.ファイルだけ戻せばWordPressは復元できますか?
完全には戻りません。記事・設定・ユーザー情報などはデータベースへ保存されるため、完全復元にはファイルとDBの両方が必要です。
Q.最新バックアップを使えばいいですか?
必ずしもそうではありません。問題発生後のバックアップには不具合や感染が含まれる場合があります。正常だった時点を選んでください。
Q.復元すると最新記事は消えますか?
古いデータベースへ戻せば、バックアップ後に追加した記事・コメント・注文などが失われる可能性があります。必要なら事前に最新データを退避してください。
Q.復元後も表示がおかしい場合は?
キャッシュ、DNS、SSL、プラグイン、PHPバージョンなども確認します。シークレットモードで表示確認し、サーバー・CDNキャッシュも削除してください。
Q.バックアップがない場合は復元できますか?
完全復元は難しくなります。サーバー会社に自動バックアップが残っていないか確認し、残存ファイル・DB・検索キャッシュなどから部分的に復旧できないか検討します。
まとめ
この記事の結論
- 復元前に正常だった時点を確認する
- 現在の状態もバックアップする
- WordPressはファイル+DBを戻す
- 初心者はサーバー自動バックアップを第一候補にする
- 重要データがある場合は部分復元も検討する
- 復元後は表示・ログイン・フォーム・SSLを確認する
- 感染時は原因除去まで行う
Webサイトの復元で重要なのは、「とにかく古い状態へ戻す」ことではありません。問題が起きる前の正常な時点を選び、現在データを退避し、必要最小限の範囲で復元してから動作確認するのが安全です。
次に読むなら
復元方法が分かったら、「WordPressの保守でやるべきこと」を確認すると、バックアップ・更新・セキュリティ・動作確認を日常運用へ組み込みやすくなります。