エックスサーバーのバックアップ復元時間は？解決策と目安を解説
こんにちは！「標準的レンタルサーバー」を運営している吉岡です。今日もサイト運営、本当にお疲れ様です！
今この記事を読んでいるあなたは、おそらく「サイトが急に真っ白になってしまった！」「プラグインを更新したらエラーが出て戻せない……」と、かなり心臓がバクバクしている状態ではないでしょうか。あるいは、万が一の時に備えて、エックスサーバーの復元にどれくらいの時間がかかるのか、慎重にシミュレーションされている最中かもしれませんね。私もサーバー運営者として、データの消失やダウンタイムの怖さは痛いほどよく分かります……。本当に、冷や汗が止まらなくなりますよね。
エックスサーバーは国内シェアも高く、非常に信頼性の高いサーバーですが、こと「バックアップの復元時間」に関しては、公式の案内だけでは見えてこない「現場のリアル」があるんですよ。今回は、あなたが抱えている「いつ終わるの？」という不安を解消するために、具体的な目安時間から、処理を高速化させる裏技、そして万が一終わらない時の対処法まで、私の経験をフル動員して詳しく解説していきますね。一緒に、一刻も早いサイト復旧を目指しましょう！
この記事を読んで解決できること
- データ容量やファイル数に基づいた、現実的な復元時間の見積もりができる
- 14日間の自動バックアップを、失敗のリスクなく使いこなせるようになる
- 復元が終わらない、エラーが出るといったトラブルに自分で対処できる
- SSHなどの高度な手法を使って、復元時間を大幅に短縮する方法がわかる
目次
xserverのバックアップ復元にかかる時間の目安
エックスサーバーで「復元ボタン」をポチッと押した後、画面がグルグル回っているのを見ている時間は、1分が1時間にも感じられますよね。まずは、あなたがどれくらい待つべきなのか、その「基準」を整理していきましょう。サーバー運営者の視点から見ると、実はデータの「重さ」だけが問題ではないんですよ。
容量やファイル数で変わる実際の所要時間
エックスサーバーのバックアップ復元にかかる時間は、実は一概に「○分です」と言い切るのが難しいんです。というのも、サーバーの混雑具合や、あなたのサイトが持っている「ファイルの種類」によって、劇的に変わるからなんですよ。ここ、ちょっと専門的な話に聞こえるかもしれませんが、すごく大事なポイントです。
「容量」よりも「ファイル数」が時間を決める
多くの方は「10GBあるから時間がかかるかな？」と考えがちですが、実はデータの重さ（容量）よりも、「ファイルがいくつあるか（ファイル数）」の方が、復元時間にダイレクトに響きます。ここが共有サーバーの面白い……というか、厄介なところなんですね。
例えば、1GBの巨大な動画ファイル1つを復元するのは、サーバーにとっては「一箇所の大きな書き込み」で済むので一瞬です。でも、WordPressのように数KBの小さなファイル（画像、PHPファイル、キャッシュなど）が数万個集まって合計1GBになっている場合、サーバーは「数万回」も書き込みの命令を処理しなければなりません。この「ファイル一つ一つをディスクに登録する作業（メタデータ処理）」が、共有サーバーにおいては最大のボトルネックになるんです。
現実的な所要時間のベンチマーク
私がこれまでに見てきた、一般的なWordPressサイト（画像数千枚、記事数百本程度）を想定した際の目安をまとめました。理想的な状態と、ちょっと苦戦している時の差を見てみてください。
| データの種類 | データ容量（目安） | 理想的な時間 | 混雑時・ファイル数多めの場合 |
|---|---|---|---|
| データベース（MySQL） | 200MB程度 | 約3分〜5分 | 15分〜30分 |
| Web領域（小規模） | 5GB以下 | 約10分〜20分 | 1時間以上 |
| Web領域（中〜大規模） | 20GB以上 | 30分〜1時間 | 3時間〜一晩（4時間〜7時間） |
14日間無料で保存される自動バックアップの仕様
エックスサーバーの最大の強みといえば、この「自動バックアップ」ですよね。ユーザーが設定を一切いじらなくても、サーバー側で毎日勝手にバックアップを取っておいてくれる。この安心感は、一度トラブルを経験すると本当に身に沁みます。ここでは、その仕様を運営者の視点でさらに深掘りしてみましょう。
保存期間と対象データの範囲
エックスサーバーでは、以下のデータが過去14日間保持されます。
1. サーバー上の全ファイル（Web・メール領域すべて）
2. MySQLデータベース（WordPressの記事本文や設定など）
これらは毎日1回、深夜から早朝にかけて自動的に取得されます。例えば、「3日前のプラグイン更新でバグが出たけど、今日まで気づかなかった！」なんて時でも、4日前の状態にサクッと戻せるわけです。保存期間が14日というのは、レンタルサーバー業界の中でもかなり長い部類に入りますよ。他社さんだと「過去7日分」というところも多いですから、安心感は倍ですね。
契約時期による「7日間」制限の罠
「自分のサーバーはどうかな？」と不安になったら、サーバーパネルの「サーバー情報」を確認してみてください。sv12301以前の番号を使っている古い環境の方は要注意です。現在は順次14日間への移行が進んでいますが、緊急時に「あ、14日分遡れない！」とならないよう、平時の時にチェックしておいてくださいね。
（出典：
バックアップの取得タイミングは選べない
自動バックアップは非常に便利ですが、一つだけ弱点があります。それは「任意のタイミングで取れない」こと。深夜に自動取得されるので、例えば「今日の昼12時に記事を更新して、14時に操作ミスで消した」場合、戻せるのは「昨日の深夜の状態」です。つまり、今日の午前中の作業分は消えてしまいます。これを防ぐには、大きな作業の前には自分で「手動バックアップ」を取る癖をつけておくと、より完璧かなと思いますよ。
復元が終わらない・失敗する主なトラブル原因
「復元を開始したのに、1時間経っても画面が変わらない」「エラーメッセージが出て止まってしまった」。こんな時、パニックになりますよね。でも大丈夫、原因のほとんどは特定可能です。私のようなサーバー運営者が、トラブル時にまず疑う3つのポイントを解説しますね。
1. ディスク容量不足によるプロセス停止
これ、実は「灯台下暗し」で一番多い原因なんです。復元作業というのは、実は「バックアップファイルを解凍して展開する」という工程を含んでいます。
例えば100GBのデータを復元しようと思ったら、サーバー上に「展開するための空きスペース」が最低でも同量、できればその1.5倍くらい（150GB程度）必要なんです。もし、あなたの契約プラン（スタンダードなら300GBなど）の容量をギリギリまで使い切っている状態で復元をかけると、途中で書き込みができなくなり、処理が「無限ループ」に入ったり「失敗」と表示されたりします。復元前には、不要なログファイルや古い一時ファイルを削除して、心に……ではなく「ディスクに余裕」を持たせてあげてくださいね。
2. ノイジー・ネイバー（近隣ユーザーの影響）
「自分は何も悪くないのに遅い」というケースがこれです。エックスサーバーは「共有サーバー」です。一つの物理的なマシンを、あなただけでなく他の多くのユーザー（数百人単位）と共有しています。
もし同じマシン内に、たまたま猛烈なアクセスを集めているバズり中のサイトや、巨大なプログラムを回しているユーザー（ノイジー・ネイバー）がいた場合、サーバー全体の「ディスクを読み書きする力（I/Oリソース）」が奪われてしまいます。この場合、あなたの復元処理は後回しにされ、通常10分で終わるはずが3時間かかる……なんてことが物理的に起こり得ます。こればかりは運の要素もありますが、サーバー運営側でも制限をかけているので、極端に遅い場合は時間を変えてみるのも手ですよ。
3. PHPのタイムアウト問題
管理画面から操作する場合、ブラウザとサーバーの間で通信が行われますが、多くの環境では1つの通信に「時間制限（タイムアウト）」を設けています。復元に時間がかかりすぎると、ブラウザ側が「返事がないから切るね！」と勝手に通信を遮断してしまい、画面が真っ白になったりエラー画面になったりします。
ここが重要なのですが、「ブラウザの画面がエラーになっても、サーバー内部では復元が続いている」ことがほとんどです。画面が変わらなくても、焦って何度も「復元ボタン」を連打するのは厳禁ですよ！さらに負荷をかけて、復元を本当に失敗させてしまう原因になりますからね。落ち着いて、コーヒーでも飲みながら裏側の処理を信じましょう。
サイトを元に戻すWeb領域とデータベースの手順
さて、ここからは具体的な復元手順を改めて確認しておきましょう。WordPressサイトの場合、「Web領域（ファイル）」と「データベース（記事内容）」の2つをセットで戻す必要があります。難しい専門用語が出てきますが、手順はシンプルなので安心してくださいね。
ステップ1：Web領域（ファイル）の復元手順
画像やテーマ、プラグインのファイルを戻す手順です。
- サーバーパネルにログインし、「バックアップ」セクションの「自動バックアップ」を選択します。
- 「復元」タブを選択。ここ、重要です！「取得」ではなく「復元」ですよ。
- 対象のドメインと「復元したい日付」を選びます。
- 「復元する（Web領域）」をクリックします。
この時、注意してほしいのは、今のサーバーにあるデータが「バックアップ時点のものに完全に上書きされる」という点です。バックアップを取った日以降にアップロードした画像などは消えてしまいます。もし大事な新着画像などがあるなら、復元前にFTPソフトで手元に保存しておくと、後から「あ、あれも消えた！」と嘆かずに済みますよ。
ステップ2：データベース（MySQL）の復元手順
記事の本文やコメント、カテゴリー情報を戻すには、こちらの手順が必要です。
- サーバーパネルの「データベース」セクションから「MySQLバックアップ」を選択します。
- 「自動バックアップから復元」タブを開きます。
- 戻したい「データベース名」と「日付」を選びます。
- 「復元」ボタンを押します。
作業前に知っておきたい料金と制限事項
「復元ってお金かかるんでしょ？」と思っている方、実はそれ、古い情報かもしれません。エックスサーバーの復元は、現在は完全に無料です！かつてはWeb領域の復元に5,000円、データベースに5,000円……といった手数料が必要な時代もありましたが、今はユーザーに寄り添った神対応になっているんですよ。本当にありがたい話ですよね。ただ、無料だからといって無限に何でもできるわけではありません。いくつか覚えておいてほしい「制限ルール」があるんです。
Inode（ファイル数）の制限に注意
エックスサーバーには「Inode」という、ファイルやディレクトリの総数に対する制限があります。一般的には100万個程度が目安ですが、これを超えてしまうと、バックアップ処理自体がエラーでスキップされてしまう可能性があるんです。
「えっ、100万個もファイルないよ！」と思うかもしれませんが、キャッシュプラグインが大量のゴミファイルを生成していたり、古いメールが溜まっていたりすると、意外とこの制限に引っかかります。平時の時にサーバーパネルの「統計」などでファイル数を確認しておくと、「いざという時にバックアップがなかった……」という悲劇を避けられますよ。
テーブル数制限（データベース）
もう一つの落とし穴が、データベースの「テーブル数」です。1つのデータベース内に1,000個以上のテーブルがあると、バックアップ対象外になる場合があります。これは、一つのデータベースに多数のWordPressを詰め込みすぎている（接頭辞を変えて共用している）場合に起こりやすい問題です。もし心当たりがあるなら、データベースをサイトごとに分けて整理しておくのが、サーバー運営者としての私からのアドバイスです。リスクは分散させるのが鉄則ですからね！
xserverでバックアップ復元時間を短縮する対策
ここからは、少し応用編です。「標準のやり方じゃ遅すぎる！」「エラーが出て進まない！」という緊急事態に、私のようなサーバー運営者が裏で行っているテクニックをこっそり伝授しますね。これを知っているだけで、復旧までの焦りがぐっと減るはずですよ。
504タイムアウトエラーを回避して復元するコツ
復元中に「504 Gateway Time-out」が出るのは、ブラウザが「もう待てないよ！」と諦めたサイン。でも、サーバー側はまだ諦めていないことが多いんです。ここを上手く乗り切るコツをお話ししますね。
「履歴画面」を別タブで監視するのが正解
復元ボタンを押して画面が止まってしまったら、その画面でリロード（再読み込み）するのはNGです！二重に処理が走って、さらに重くなる原因になります。
正しい対処法は、**別のタブ（または別のブラウザ）で改めてサーバーパネルにログインする**こと。メニューの中に「自動バックアップデータ取得・復元履歴」という項目があります。ここを見ると、現在の処理が「実行中」なのか「正常終了」なのか、真実のステータスが表示されています。画面がエラーでも、ここで「実行中」となっていれば、サーバーは裏で必死に頑張っています。この履歴画面を時々リロードして、終わるのを待つのが、精神衛生上も一番いい方法なんですよ。ここ、テストに出ます（笑）。
通信環境を安定させる
意外な盲点ですが、カフェの無料Wi-Fiなどの不安定な回線で復元ボタンを押すと、通信が途切れてリクエストが届かないことがあります。復元のような重い処理を行う時は、できるだけ安定した自宅の固定回線などから操作することをおすすめします。それだけで、無駄なエラーに遭遇する確率がぐっと下がりますよ。また、ブラウザのキャッシュをクリアしておくのも、地味ですが効くことがあります。
SSHコマンドを活用した高速な手動復元のやり方
さて、ここからは中〜上級者向けですが、爆速で復旧させるための「最強の手段」を紹介しますね。それがSSH接続を使ったコマンド操作です。
「えっ、プログラミングみたいで怖い！」と思うかもしれませんが、やり方さえ分かればこれほど頼もしいものはありません。ブラウザ経由（HTTP）の制約をすべて無視して、サーバーのOSと直接対話できるからです。
データベースの高速復旧テクニック
- まず、サーバーパネルからバックアップデータを「取得（ダウンロード）」します。
- そのSQLファイルをFTPソフト（FileZillaなど）でサーバーの適当なフォルダにアップロードします。
- SSHでサーバーにログインし、以下のコマンドを打ち込みます。
mysql -u (DBユーザー名) -p -h (DBホスト名) (DB名) < backup.sql
ファイル復旧もコマンドなら一瞬
Web領域の復旧も、バックアップの圧縮ファイルをサーバー上で直接展開（tarコマンドなど）すれば、FTPでちまちま数万個のファイルを送るより100倍速いです。エンジニア気質な方は、ぜひこの「コマンドの力」を味方につけてみてくださいね。
ConoHaなど他社と比較した復元機能の優位性
最近はConoHa WINGやMixhostといった強力なライバルも増えてきましたね。「エックスサーバーの復元って、他と比べてどうなの？」と聞かれることも多いです。正直に言いますと、「堅実さと安定感」ではエックスサーバーが今でもトップクラスかな、と私は思います。
他社との違いを冷静に分析してみた
例えば、ConoHaさんは復元のUIが非常にモダンで速いと言われていますが、実は「作成したリストアデータは24時間で自動削除される」といった独自のルールがあります。また、1週間に5回以上復元すると制限がかかる……といった制約がある場合も。
一方、エックスサーバーは良い意味で「無骨」です。回数制限もゆるやかですし、何より20年近い運営実績の中で培われた「データの保全性」へのこだわりがすごいです。復元速度だけで言えば、最新の他社サーバーに一歩譲る場面もありますが、「いざという時に必ず戻せる」という信頼感は、我々サーバー運営者の間でも高く評価されていますよ。
| 比較項目 | エックスサーバー | ConoHa WING | Mixhost |
|---|---|---|---|
| 保存期間 | 14日間 | 14日間 | 14日間 |
| 復元料金 | 無料 | 無料 | 無料 |
| 特筆すべき点 | SSH復元など回避策が豊富 | UIが使いやすく高速 | JetBackup採用で多機能 |
結局のところ、どのサーバーも「14日間保存・無料復元」という横並びの状態ですが、エックスサーバーはユーザー数が多い分、トラブル解決の記事がネットに溢れているのが最大の強み。独りで悩まずに済む、というのは初心者の方にとって何よりの保険ですよね。
整合性を守るためのWeb領域とDBの同時復元
ここ、今日一番大事なことを言いますね。WordPressは「ファイル」と「データベース」の二人三脚で動いています。
想像してみてください。あなたは3日前に新しい記事を書き、画像をアップしました。今日、不具合が起きたので「ファイル」だけを3日前の状態に戻したとします。するとどうなるか？
「データベース」には記事の情報が残っているのに、表示するための「画像ファイル」がサーバーに存在しない……というチグハグな状態になり、サイトが虫食い状態（リンク切れ）になってしまうんです。これ、本当に悲惨ですよ……。
同時復元のゴールデンルール
不具合を完全に解消したいなら、面倒でも「Web領域」と「データベース」の両方を、同じバックアップ日のデータで同時に戻すこと。これが鉄則です。
「昨日の記事だけは消したくないから、データベースだけは今のままにしたい……」という気持ちも分かります。でも、不整合が起きた後に手作業で数千枚の画像のリンクを直すのは、地獄の作業です。まずは同じ日付で完全に「正常だったあの頃」にリセットし、その後に消えてしまった記事だけをメモ帳などから書き直す。急がば回れ、これが一番安全で確実なサイト復旧の道ですよ。相槌を打ちながら聞いてほしいくらい、重要なポイントなんです。
まとめ：xserverのバックアップ復元時間を把握
最後まで読んでいただき、本当にありがとうございます！「xserver バックアップ 復元 時間」についての疑問は、少しは解消されましたでしょうか。
エックスサーバーの復元時間は、10分で終わることもあれば数時間かかることもあります。それはファイル数やサーバーの混雑状況という「現場の事情」があるからなんです。大切なのは、以下の3点です。
復元を成功させるための最終チェック
- 復元には数時間かかる可能性があることを覚悟し、焦ってボタンを連打しない！
- 画面が止まったら「履歴画面」を別タブで開き、裏側の動きを冷静にチェックする。
- 必ず「Web領域」と「データベース」を同じ日付でセットで戻し、整合性を守る。
サイトが表示されなくなった時の焦りは、私も本当によく分かります。でも、エックスサーバーを使っているなら、強力なバックアップがあなたを守ってくれています。落ち着いて対処すれば、必ず元のサイトに戻せますよ！この記事が、あなたのサイト運営の安心に少しでも繋がれば幸いです。もし「どうしても戻らない！」なんて時は、またいつでも相談に来てくださいね。吉岡でした！
コメント