INDEX目次を開く ＋閉じる −
※本記事には広告（PR）が含まれます。
wpX Speedには、WordPressのファイルとデータベースを自動バックアップから復元する機能があります。
ただし、画像やテーマなどを戻す「ファイルの復元」と、投稿や設定を戻す「データベースの復元」は別です。どちらか一方だけでは、WordPress全体が元に戻らない場合があります。
今回は、テスト投稿と画像を実際に削除し、2026年9月19日のバックアップから復元しました。約12秒間隔の監視ログも取り、何が、いつ戻ったのかを確認しています。
結論：画像はファイル、投稿はデータベースの復元で戻った
今回の結果を先にまとめます。
| 確認項目 | ファイルの復元 | データベースの復元 |
|---|---|---|
| 復元したもの | public_html内のファイル | MySQLデータベース |
| 削除した画像 | 戻った | 対象外 |
| 完全削除した投稿 | 戻らなかった | 戻った |
| 画面で使った日付 | 2026年9月19日 | 2026年9月19日 |
| 実測できた時間 | 画像の復活まで約8分33秒 | 確認画面から投稿の復活まで最大約81秒 |
| 復元前の注意 | バックアップ日以降の新規ファイルが消える | 現在のDBへ上書きされ、元に戻せない |
ファイル復元の開始画面を確認したのは00:26:33、削除した画像がキャッシュ回避URLで200に戻ったのは00:35:06でした。監視間隔は約12秒なので、画像の復活時刻には最大約12秒の幅があります。
データベース復元の確認画面を撮影したのは01:16:35、完了画面は01:17:49、投稿がキャッシュ回避URLで200に戻ったのは01:17:56です。確定ボタンを押した正確な時刻は記録していないため、確認画面から数えた最大時間として約81秒としています。
ファイル復元の処理全体が完了した正確な時刻は確認できませんでした。
画像は約8分33秒で戻りましたが、管理画面で「復元が完了しました」と確認したのは01:15:03です。画像が戻った時点で、すべてのファイル処理が終わっていたとは断定できません。
wpX Speedの復元画面はWordPress設定の下部にある
管理パネルで「サーバー管理」→「WordPress管理」→「インストール済みWordPress一覧」と進み、対象サイトの「設定」を開きます。
ページ下部の「自動バックアップ」に、次の3項目があります。
- データベースの復元
- データベースのバックアップデータ取得
- ファイルの復元
ファイルとデータベースは入口も復元操作も分かれています。
公式情報ではファイル14日、データベース7日と案内されている
2026年9月20日に公式マニュアルを確認すると、保持期間の記載は次のように分かれていました。
| 公式ページ | 記載内容 |
|---|---|
| ファイルの復元マニュアル | 復元可能なデータは過去14日分まで |
| データベースの復元マニュアル | 復元可能なデータは過去7日分まで |
| 自動バックアップのサービスページ | 全サーバープランで過去7日分を保持 |
総合案内は「過去7日分」ですが、ファイル復元の個別マニュアルは「過去14日分」です。今回の管理画面でも、ファイル側には9月19日から9月6日まで14日分の日付が表示されました。
一方、データベース側では9月19日と18日だけが選択でき、9月20日と9月17日以前には「データなし」と表示されました。
このサイトをwpX Speedへ設置したのは9月17日夜です。9月17日以前にデータがないこと、9月20日0時台に当日分がまだないことは、設置時刻とバックアップ取得時刻による可能性があります。ただし、管理画面だけでは取得処理の正確な時刻まで確認できませんでした。
ファイル側は14日分が並んでいましたが、古い日付のバックアップが実際に復元可能かは実行していません。今回は、ファイルとDBの両方で選択できた9月19日を使っています。
復元前に確認した検証条件
今回の対象は、記事57件が入った検証用WordPressです。検索結果へ出ないようnoindexに設定した環境で行いました。
| 項目 | 条件 |
|---|---|
| wp-content | 約1万ファイル・約237MB |
| データベース | 約17MB・41テーブル |
| 削除した投稿 | 「バックアップ復元テスト」をゴミ箱から完全削除 |
| 削除した画像 | /wp-content/uploads/2022/08/post23.jpg（100,324バイト） |
| 復元日 | ファイル・DBとも2026年9月19日 |
| 監視間隔 | 約12秒 |
| 確認対象 | 投稿URL、画像URL、トップページ |
| キャッシュ回避 | URL末尾に毎回異なる?cb=を追加 |
投稿はWordPress管理画面で完全に削除し、画像はFTPで削除しました。削除後、キャッシュ回避URLで投稿と画像が404になることを確認してから復元しています。
データベースは復元前にエクスポートできる
データベースの復元画面には、復元後に元の状態へ戻せないため、現在の内容が必要なら事前にエクスポートするよう案内があります。
「データベースのエクスポート・インポート」では、次の形式を選べます。
- 圧縮なしのSQLファイル
- gz形式
今回、エクスポート画面を開いたことは確認しています。ただし、エクスポートしたファイルそのものは確認していないため、保存完了までは検証済みとして扱いません。
本番サイトで復元する場合は、管理画面の自動バックアップだけに依存せず、現在のファイルとDBを別途保存してから進める方が安全です。
ファイルの復元手順と実測結果
1. バックアップ日と注意事項を確認する
「ファイルの復元」で対象日を選ぶと、次の注意事項が表示されます。
- 復元対象はバックアップファイルのデータですべて上書きされる
- バックアップに存在しない、取得日以降の新しいファイル・ディレクトリは削除される
- 空き容量が足りないと失敗する場合がある
- データサイズ、ファイル数、サーバー負荷によって時間がかかる場合がある
「上記の注意事項を理解した上で復元処理を行います」にチェックを入れ、「復元を開始（確認）」を押します。
2. 対象日を再確認して確定する
確認画面には対象バックアップ日が表示されます。
日付に間違いがなければ「復元を開始（確定）」を押します。
3. リストア開始後は完了まで待つ
確定後、「自動バックアップデータのリストアを開始しました」と表示されました。
ファイル復元ページへ戻ると、「復元中です。処理が完了するまでお待ちください」と表示されます。
4. 削除した画像は約8分33秒で戻った
00:26:33に開始画面を確認し、00:35:06に削除した画像のキャッシュ回避URLが404から200へ変わりました。開始から約8分33秒です。
管理画面で完了を確認したのは01:15:03でした。
画像が戻った後もテスト投稿は404のままでした。ファイルを復元しても、データベース内の投稿は戻らないことを実際に確認できました。
データベースの復元手順と実測結果
1. 上書きと事前エクスポートの注意を確認する
データベース復元には、次の注意事項があります。
- DBの内容はバックアップ時点の内容へすべて上書きされる
- 復元後に元の状態へ戻すことはできない
- 現在の内容が必要なら、復元前にエクスポートする
対象日を選び、注意事項への同意にチェックを入れて「復元（確認）」を押します。
2. 確認画面から復元を確定する
対象日を確認して「復元（確定）」を押します。
3. 投稿はデータベース復元後に戻った
01:17:49に「復元処理は正常に完了しました」と表示されました。
次の監視時刻である01:17:56に、完全削除したテスト投稿のキャッシュ回避URLが404から200へ変わりました。
ファイル復元では戻らなかった投稿が、データベース復元で戻ったことから、投稿本文、タイトル、カテゴリなどはDB側の復元対象だと確認できます。
削除や復元の確認ではキャッシュに注意する
今回、通常URLと、毎回異なるクエリを付けたキャッシュ回避URLを同時に監視しました。
| 状態 | 通常URL | キャッシュ回避URL |
|---|---|---|
| 投稿削除直後 | 200の古いページを表示 | 404 |
| 00:29:40以降 | 404 | 404 |
| DB復元後 | 404のまま | 200 |
| 画像削除後 | 200のまま | 404 |
| ファイル復元後 | 200 | 200 |
投稿の通常URLは、完全削除後も少なくとも約9分は古い200を返し続けました。DB復元後は反対に、通常URLが404のままなのに、キャッシュ回避URLでは復元済みの投稿を表示できました。
画像の通常URLも、削除後から復元まで200のままでした。
この挙動は、サーバーキャッシュに古い結果が残っていたためと考えられます。削除や復元の成否を確認するときは、次の方法を組み合わせてください。
- URL末尾に
?cb=任意の文字列を付ける - シークレットウィンドウで開く
- サーバーキャッシュを削除してから確認する
- 投稿だけでなく画像URLも直接確認する
キャッシュが有効にならない原因を調べる場合は、高速化設定がONなのにキャッシュが効かないときの確認方法も参考になります。
復元中もトップページは監視範囲では応答していた
ファイル復元からDB復元後まで、トップページのキャッシュ回避URLを約12秒間隔で266回確認しました。記録した範囲では、すべてHTTP 200でした。
ただし、1回の監視には8秒のタイムアウトを設定しており、約12秒の間隔があります。数秒だけ応答できなかった時間がなかったとは断定できません。
今回の規模では、長時間サイト全体が表示できなくなる状態は監視ログに記録されませんでした。アクセスの多い本番サイトで同じ結果になる保証はないため、影響を抑えたい場合はアクセスの少ない時間帯に作業してください。
FTPアカウントがOFFなら復元前後の確認ができない
今回使った検証環境では、WordPressを作り直した後、FTPアカウントのステータスがOFF、接続先フォルダが「-」になっていました。
OFFの状態で接続すると、今回の環境では530 Login incorrectになりました。FTPでファイルを削除・確認する場合は、対象WordPressのFTP設定を先に確認してください。
FTPアカウントは検証後もONのままにせず、必要がなければOFFへ戻す運用が考えられます。
wpX Speedのバックアップ復元に関するよくある質問
ファイルの復元だけでWordPress全体が戻りますか？
今回の検証では戻りませんでした。削除した画像はファイル復元で戻りましたが、完全削除した投稿は404のままで、DB復元後に戻りました。障害の内容に応じて、ファイルとデータベースの両方を確認してください。
復元するとバックアップ日以降のデータはどうなりますか？
ファイル復元では、選んだバックアップに存在しない新しいファイルやディレクトリが削除されます。DB復元では、現在のDBがバックアップ時点の内容へ上書きされ、元に戻せません。
復元前に現在の状態を別途バックアップしてください。
ファイルとデータベースは何日分戻せますか？
2026年9月20日時点の公式マニュアルでは、ファイルは過去14日分、データベースは過去7日分です。一方、自動バックアップのサービスページは全体を過去7日分と案内しています。
今回の画面ではファイル側に14日分の日付が並びましたが、すべての日付を実際に復元できるかは確認していません。実行前に管理画面で選択可能な日付と最新の公式案内を確認してください。
復元にはどのくらい時間がかかりますか？
約237MB・約1万ファイルの環境では、削除した画像が約8分33秒で戻りました。DBは約17MB・41テーブルで、確認画面から投稿の復活まで最大約81秒でした。
処理全体の完了時間は、データ量、ファイル数、サーバー負荷で変わります。今回の数値は1回の検証結果であり、目安として固定できる時間ではありません。
復元中もサイトは表示できますか？
今回の監視では、トップページは266回すべてHTTP 200でした。ただし、約12秒間隔の確認なので、短い停止まで否定できません。重要なサイトではアクセスの少ない時間帯に作業し、復元前後の表示も確認してください。
まとめ
wpX Speedの自動バックアップを実際に復元し、次の結果を確認しました。
- 削除した画像はファイル復元で戻った
- 完全削除した投稿はファイル復元では戻らず、DB復元で戻った
- 画像は復元開始画面の確認から約8分33秒でアクセス可能になった
- DBは確認画面から投稿の復活まで最大約81秒だった
- 通常URLだけを見ると、キャッシュで削除・復元の判断を誤る場合がある
- 復元前に現在のファイルとDBを別途保存した方がよい
ファイルとデータベースは別々に上書きされます。何が消えたのかを確認し、対象日以降の変更を失ってもよいか確認してから実行してください。
申し込み前の料金・速度・機能の比較は、エックスサーバーとwpX Speedの比較で確認できます。契約手順はwpX Speedの申し込み方法、WordPressの準備はwpX Speedの新規インストール方法にまとめています。
参照した公式情報
- wpX Speedのファイル復元マニュアル（2026年9月20日確認）
- wpX Speedのデータベース復元マニュアル（2026年9月20日確認）
- wpX Speedの自動バックアップ（2026年9月20日確認）