エックスサーバーのバックアップ時間はいつ?復元の目安も解説
標準的レンタルサーバー、運営者の吉岡です。いつもブログ運営お疲れ様です!
エックスサーバーを使っていて、「バックアップって具体的に何時に取られているんだろう?」「サイトを壊しちゃった時、復元にはどのくらい時間がかかるのかな?」って不安になること、ありますよね。私も昔、カスタマイズに失敗して真っ白になった画面を前に、冷や汗を流しながら復元ボタンを連打した苦い経験があります(笑)。
今回は、そんなあなたの不安を解消するために、エックスサーバーのバックアップに関する「時間」の仕様を、中の人レベルで徹底的に深掘りしました。公式サイトには載っていない現場のリアルな数字も出していくので、ぜひ最後までお付き合いくださいね。
この記事を読むメリット
- 自動バックアップが実行される正確なタイミングと仕組みがわかる
- サイトの容量に応じた「復元にかかる時間」のリアルな目安がわかる
- バックアップが実は止まっていた……という最悪の落とし穴を防げる
- 万が一のトラブル時にも、焦らず冷静に対処できる知識が身につく
- エックスサーバーのバックアップ時間はいつ?実行の仕様を解説
- エックスサーバーでバックアップを復元する時間の実態と対策
エックスサーバーのバックアップ時間はいつ?実行の仕様を解説
エックスサーバーを契約しているなら、まず絶対に知っておきたいのが「バックアップの基本仕様」です。実は、エックスサーバーのバックアップは私たちが寝ている間に、ものすごく緻密なスケジュールで動いているんですよ。ここでは、その「時間」にまつわる裏側を詳しく解説しますね。
自動バックアップの開始は深夜から早朝に行われる
「私のサイトのバックアップ、今この瞬間取られているの?」と気になるかもしれませんが、残念ながらユーザー側で「何時何分」と指定することはできません。エックスサーバーの自動バックアップは、一般的に「深夜から早朝にかけて」順次実行される仕組みになっています。具体的にはAM2:00からAM6:00くらいの間に行われることが多いですね。
なぜ時間が固定されていないのか?
これは、エックスサーバーが「共有サーバー」という仕組みを採用しているからです。一つの強力なサーバーの中に、数千というユーザーが同居しています。もし全員のバックアップを「深夜0時ぴったり」に開始したらどうなるでしょうか?サーバーの読み書き(ディスクI/O)が限界を超えてしまい、サイトの表示がガクンと重くなったり、最悪の場合はサーバーがダウンしてしまったりするんです。だから、システム側が全体の負荷を見ながら、各ユーザーの処理を少しずつズラして実行しているんですよ。朝の通勤ラッシュを避けるために、みんなが少しずつ時間をズラして出社するようなイメージですね。
夜型ブロガーさんは注意!
深夜に記事を執筆しているあなたにとって、この「時間のゆらぎ」は少し注意が必要です。たとえばAM3:00に渾身の記事を書き上げて公開したとします。もしその日のバックアップがAM2:30に終わっていたら、公開した記事はまだバックアップに含まれていません。逆に、AM4:00にバックアップが始まったなら、その記事もしっかり保存されています。このように「何時まで書いたものが保存されているか」は、その日のサーバーの混雑状況による「運次第」なところがあるんです。深夜に大幅なカスタマイズをする際は、自動バックアップがあるからと油断せず、自分でも保存しておくのが安心ですよ。
データの保持期間はWebもメールも14日間
エックスサーバーのバックアップにおける「時間」でもう一つ重要なのが、「過去14日間」という保持期間です。この2週間という絶妙な長さには、実は大きな意味があるんですよ。
Web・メール・データベースすべてが14日間
以前は「Webデータは7日間、データベースは14日間」と分かれていた時期もありましたが、現在は全プラン一律で14日間となっています。Web領域(public_htmlの中身)、受信・送信済みのメール、そしてWordPressの命とも言えるデータベース(MySQL)が、しっかり過去14日分ストックされています。これ、冷静に考えるとものすごい安心感ですよね。
なぜ「14日間」が重要なのか?
「3日分もあれば十分じゃない?」と思うかもしれませんが、実はそうではないんです。一番怖いのは「マルウェア(ウイルス)」への感染です。サイトが改ざんされた時、すぐに気づければ良いのですが、実際には感染してから数日が経って「あれ、なんかサイトの挙動がおかしいぞ?」と気づくケースが多いんです。もし保持期間が3日間しかなかったら、気づいた時にはバックアップデータもすでに感染後のものに上書きされていて、お手上げ……なんてことになりかねません。14日間あれば、2週間前という「確実に健全だった頃」のデータに戻れる可能性がぐんと高まるわけです。この「時間の猶予」こそが、エックスサーバーがプロにも選ばれる理由なんですよ。
吉岡のワンポイントアドバイス:
メールデータも14日間戻せるのは地味に嬉しいポイントです。「あ!間違えて大切な取引先からのメールを完全に消しちゃった!」という時も、バックアップからサルベージできる可能性がありますよ。意外と助けられる人が多い機能なんです。
ファイル数制限で自動処理が停止するリスクと通知
さて、ここからは少し「怖い」お話をします。エックスサーバーを長く使っていると、ある日突然「自動バックアップの対象から除外しました」という恐ろしいメールが届くことがあるんです。これには、ファイル数という名の「時間の壁」が関係しています。
大量のファイルは「時間の泥棒」
エックスサーバーには「inode(アイノード)」という概念があります。簡単に言うと、サーバー内のファイルの総数のことです。一つのアカウントで保存できるファイル数には制限(プランによりますが数十万単位)があり、これを超えてしまうと自動バックアップが停止されます。なぜかというと、何十万、何百万という小さなファイルをバックアップするのは、ものすごく時間がかかるからです。巨大な動画ファイルを1個コピーするよりも、極小の画像を10万枚コピーする方が、サーバーにとっては数倍〜数十倍も重い作業なんです。一人のユーザーのバックアップに時間がかかりすぎると、他のユーザーのバックアップが終わる前に朝が来てしまう……なんて事態を防ぐための、苦肉の制限なんですね。
どんな人が制限に引っかかりやすい?
特に注意が必要なのは、以下のタイプの方です。
- キャッシュ系プラグイン(WP Super Cacheなど)を使っている
- 画像最適化プラグインで、元画像の他に大量のサムネイルを自動生成している
- 何年もメールを削除せず、サーバーに残しっぱなしにしている(1通=1ファイルです!)
- 古いバックアップファイルをサーバー内に溜め込んでいる
もし「除外通知」が届いたら、それはサーバーからの「データが散らかりすぎていて、もう守りきれません!」という悲鳴です。不要な画像を整理したり、古いメールをローカルに移動したりして、ファイル数を減らす努力をしましょう。自分自身のサイトの健全性を保つことが、結果的に「バックアップ時間を短縮し、守りを固める」ことにつながるんですよ。
バックアップ専用サーバーへの退避でデータ保護
エックスサーバーのバックアップが「速くて確実」と言われる理由の一つに、そのインフラ構成があります。ただデータをコピーするだけでなく、「物理的に別の場所」へ逃がしているんです。
本番環境とバックアップ環境の分離
多くの格安レンタルサーバーでは、サイトが動いているのと同じサーバー(筐体)の中にある別のハードディスクにバックアップを取ることが多いです。これでも十分な気がしますが、もし火災や地震などでサーバー筐体そのものが物理的に物理的にポシャってしまったら、本番データもバックアップデータも一蓮托生で消えてしまいますよね。エックスサーバーの場合、バックアップデータは専用の「バックアップ専用ストレージサーバー」に転送されます。この転送処理も高速な内部ネットワークで行われるため、私たちが気づかないうちに安全な「避難所」へデータが送り届けられているんです。
RAID1(ミラーリング)との違いを知っておこう
「エックスサーバーはRAID1構成だからバックアップはいらないって聞いたけど?」という質問をたまに受けますが、これは間違いです。RAID1(ミラーリング)は、2台のディスクに同時に同じ内容を書き込む技術で、これは「ハードディスクが1台故障しても止まらないため」のもの。もしあなたが間違ってファイルを削除したら、RAID1だと両方のディスクから瞬時に消えてしまいます。一方、バックアップは「過去のある時点」の状態を保存しておくもの。この「時間の巻き戻し」ができるかどうかが、運用における決定的な違いです。エックスサーバーはこの両方を組み合わせることで、まさに鉄壁の守りを築いているというわけですね。
他社と比較した保持期間や復元手数料のメリット
「エックスサーバーのバックアップって、他のサーバーと比べてどうなの?」というのは、これからサーバーを選ぶ人、あるいは乗り換えを検討している人にとって一番知りたいところですよね。結論から言うと、エックスサーバーは「無料化の波を牽引したパイオニア」なんです。
かつては「復元は有料」が当たり前だった
これ、今の若いユーザーさんは驚くかもしれませんが、数年前までエックスサーバーも「データの復元」は有料だったんですよ。バックアップは自動で取ってくれるけれど、いざ戻そうとすると「手数料1万円(税別)いただきます!」という世界でした。ところが、競争が激しくなる中でエックスサーバーはいち早く「復元手数料の完全無料化」に踏み切りました。これが業界のスタンダードになり、今のConoHa WINGやロリポップのハイスピードプランなども追随した形になります。
| 項目 | エックスサーバー | Mixhost | ロリポップ! |
|---|---|---|---|
| 自動バックアップ | 無料・標準 | 無料・標準 | プランにより有料 |
| 保持期間 | 14日間 | 30日間 | 7〜14日間 |
| 復元手数料 | 0円(無料) | 0円(無料) | プランにより1.1万円 |
Mixhostの「30日間」との比較
表を見るとわかる通り、Mixhostは「30日間」という驚異的な長さを誇っています。これは確かに魅力ですよね。でも、エックスサーバーの強みは「速度と安定性の実績」にあります。いくら30日前まで戻せても、いざという時に復元処理が重くて進まない、あるいはサーバー自体がダウンしている……なんてことになったら意味がありません。エックスサーバーの「14日間」は、最新のNVMe SSDを採用した超高速環境とセットでの提供なので、安心の質が違うかな、と私は個人的に感じています。「ちょうどいい14日間」と「絶対的な安定性」のバランスが、エックスサーバーの黄金比なんです。
手動バックアップを併用すべき更新前の注意点
ここまで「自動バックアップ最強!」という話をしてきましたが、運営者である私からあなたに一つ、どうしても伝えたい「鉄則」があります。それは、「重要な作業の前は、必ず手動でバックアップを取ること」です。自動に頼りきるのは、実は少しだけ危険なんですよ。
「最新の自分」を守れるのは自分だけ
何度も言うように、自動バックアップは深夜に行われます。たとえば、あなたが午後の3時間かけて魂を込めて書いた新着記事。これを公開した直後に、ふと思いついてプラグインを更新したら、サイトが真っ白になったとします。「大丈夫、自動バックアップがある!」と思って昨夜のデータに戻すと……どうなるでしょうか?そう、今日3時間かけて書いた記事は、跡形もなく消えてしまいます。なぜなら、バックアップが取られたのは「昨日の深夜」だからです。この「時間の隙間」を埋めるのが、手動バックアップの役割なんです。
吉岡が推奨する「手動バックアップ」のタイミング
私はいつも、以下のタイミングでは必ず手動保存をしています。
- WordPressの本体(メジャーアップデート)を更新する時
- 新しくプラグインを導入したり、一括更新したりする時
- テーマのコード(functions.phpなど)を直接編集する時
- 長文記事を公開する直前(特にブラウザでの直接執筆時)
エックスサーバーの管理画面(サーバーパネル)から、WebデータとデータベースをポチポチっとダウンロードするだけでOK。時間にすればわずか3分程度の手間です。この3分を惜しんで、3日分の作業を失う人を私はたくさん見てきました。あなたにはそうなってほしくないんです。「自動は保険、手動は自衛」。この意識を持つだけで、あなたのサイト運営の安全性は飛躍的に高まりますよ!
エックスサーバーでバックアップを復元する時間の実態と対策
ここからは、いざトラブルが起きた時の「復元(リストア)」に焦点を当てていきます。「復元ボタンを押してからどのくらい待てばいいの?」という、最も緊張感のある部分を詳しく見ていきましょう。
データ容量別に見るリストア所要時間のリアルな目安
復元にかかる時間は、一言で言えば「データの重さ」に比例します。でも、単なる重さだけでなく、中身が「どう詰まっているか」でも変わってくるんです。公式サイトには具体的な所要時間は書いてありませんが、多くの検証データと私の経験から導き出した目安を公開しますね。
1GB以下のサイト(個人の日記ブログなど)
所要時間:約5分〜10分
この規模なら、スマホで少しSNSをチェックしている間に終わります。「え、もう終わったの?」というくらい早いです。WordPressを入れたてで、まだ記事数が少ない状態なら、このスピード感を味わえますよ。
10GB前後のサイト(数年運営している中規模ブログ)
所要時間:約30分〜1時間
画像もたくさん増え、データベースもしっかり成長してきたこのくらいの規模が一番多いかもしれません。復元ボタンを押して、ゆっくりコーヒーを淹れて一息つくくらいがちょうど良い待ち時間ですね。画面をじっと見つめていると長く感じますが、裏側では必死にデータが書き込まれています。
30GB〜50GB超え(大規模メディア、動画・高画質画像を多用するサイト)
所要時間:約4時間〜8時間(半日〜1日!)
ここは注意が必要です。データ量が数10GBを超えてくると、復元時間は「数時間単位」に跳ね上がります。実際、約25.5GBのサイトを復元した際に「7時間半」かかったという報告もあります。これは、単にファイルをコピーするだけでなく、共有サーバーのリソース制限(他のお客さんに迷惑をかけないためのスピード制限)がかかるためです。もしあなたが大規模サイトを運営しているなら、「復元ボタン=半日はサイトが見られなくなる」という覚悟を持つ必要があります。
復元が遅い原因はファイル数とI/O負荷の影響
「たった3GBのサイトなのに、復元に1時間以上かかっている!これっておかしくない?」そう思われる方も多いかもしれません。実は、復元時間を左右するのは「データの重さ(GB)」だけではないんです。ここで、サーバーの裏側で何が起きているのか、ちょっとした専門的なお話をしますね。難しい用語も出てきますが、わかりやすく解説するので安心してください!
「重さ」よりも「数」がネックになる理由
復元時間を決める最大の要因、それは「ファイル数(inode数)」です。たとえば、1GBの巨大な動画ファイルを1個コピーするのと、1KBの小さな画像を100万枚コピーするのでは、後者の方が圧倒的に時間がかかります。なぜなら、ファイルを一つひとつ戻すたびに、サーバーは「このファイルの名前はこれ、場所はここ、権限はこれ……」という管理情報(メタデータ)を更新しなければならないからです。WordPressサイトは、特にキャッシュプラグインや画像のリサイズ機能によって、自分でも気づかないうちに数万〜数十万個の小さなファイルが生成されがちです。この「ちりも積もれば山となる」ファイルたちが、復元時の「時間の泥棒」の正体なんですよ。
共有サーバー特有の「スロットリング」という制限
もう一つの原因は、エックスサーバーが「共有サーバー」であることです。一人のユーザーが復元処理のためにディスクの読み書き性能(I/O)をフルパワーで使い切ってしまうと、同じサーバーに同居している他のお客さんのサイトが重くなってしまいます。これを防ぐために、サーバーには「リソース制限(スロットリング)」という仕組みが備わっています。一度に流せるデータの蛇口を少し絞っている状態ですね。そのため、深夜の空いている時間帯ならスッと終わる復元も、多くの人がサイトを見ている昼間やゴールデンタイムには、想定以上に時間がかかってしまうことがあるんです。これはエックスサーバーが「誰のサイトも安定して動かす」ために行っている優しい制限なのですが、急いでいる時にはちょっともどかしく感じちゃいますよね。
データベース(SQL)のインポートという別工程
さらに、ファイルの復元とは別に「データベースの復元」も行われます。これはSQLという形式のデータを読み込んで、一件ずつレコードを再構築していく作業です。特にコメントが数千件あるサイトや、大きなログデータが残っているデータベースの場合、この処理だけでもかなりの計算リソースを消費します。ファイルとデータベース、この二重の作業を丁寧にこなしているからこそ、復元にはそれなりの「誠実な時間」が必要になるというわけです。
吉岡の共感ポイント:
「早く戻って!」と願う気持ち、本当によくわかります。でも、ここで焦って何度もボタンを押したり、サーバーを再起動しようとしたりするのは逆効果なんです。サーバーは裏で一生懸命頑張っているので、信じて待ってあげましょうね。
処理が終わらない時の進捗確認方法とステータス
復元ボタンを押した後、画面がずっと「準備中」や「実行中」のまま変わらないと、「もしかしてフリーズしちゃった?」と不安になりますよね。私も初めて大規模サイトを戻した時は、30分経っても画面が動かなくて、ブラウザを閉じていいのか、PCをつけっぱなしにすべきか、本当に悩みました。でも、大丈夫です。ちゃんと確認する方法がありますよ。
「自動バックアップデータ取得・復元履歴」をチェック!
エックスサーバーのサーバーパネル内には、過去のバックアップ操作を確認できる「自動バックアップデータ取得・復元履歴」というタブがあります。ここを見れば、今行っている復元が「受付中」なのか「実行中」なのか、あるいは「正常終了」したのかが一目でわかります。もし画面が固まったように見えても、この履歴画面をリロード(再読み込み)して「実行中」となっていれば、サーバーは止まらずに作業を続けています。これが確認できれば、ひとまずは安心ですね。
ブラウザは閉じても大丈夫?
結論から言うと、復元を開始した後はブラウザを閉じても、PCの電源を切っても全く問題ありません! 復元処理はあなたのPCで行っているのではなく、エックスサーバーの超高性能なコンピューターの中で行われているからです。一度「復元」の命令がサーバーに届けば、あとはサーバーが自分自身で最後までやり遂げてくれます。深夜に復元を開始して、「終わるまで寝られない……」なんて修行をする必要はありません。履歴画面で「実行中」になっているのを確認したら、あとはゆっくり休んで、明日の朝に「正常終了」しているのを確認すればOKですよ。
もし「失敗」や「エラー」になっていたら?
めったにありませんが、ごく稀に「エラー」で止まってしまうことがあります。主な原因は、一時的なサーバーの高負荷や、後述するディスク容量不足などです。もし失敗してしまっても、焦らないでください。エックスサーバーのサポートは非常に優秀ですので、エラーの内容を控えて(またはスクリーンショットを撮って)問い合わせれば、迅速に原因を調べてくれます。まずは履歴画面を「心の拠り所」として、落ち着いて状況を見守ることが大切です。
(出典:エックスサーバー公式サイト:自動バックアップからの復元手順)
容量不足や24時間ルールによる復元失敗を防ぐコツ
バックアップからの復元を「100%確実に」成功させるためには、いくつか知っておくべきコツがあります。これを知らないと、「せっかく数時間待ったのにエラーで終わった……」という悲しい事態になりかねません。吉岡が現場で学んだ「失敗しないためのチェックリスト」を共有しますね。
ディスク空き容量の「2倍ルール」
これは意外と知られていない落とし穴なのですが、復元を行うには、現在のサイトのデータ量に加えて「バックアップデータと同じ分だけの空き容量」が必要になる場合があります。復元処理のプロセスで、一時的にデータを解凍したり展開したりするスペースが必要だからです。たとえば、300GBのプランで200GB使っている場合、新しく100GB分のデータを復元しようとすると、一時的に容量オーバーになって処理が止まってしまうことがあるんです。復元前には、不要なゴミ箱のファイルや一時ファイルを消して、できるだけディスクに「呼吸をさせるスペース」を作ってあげてくださいね。
「取得(ダウンロード)」時の24時間ルールに注意
エックスサーバーには、直接サイトを書き換える「復元」のほかに、バックアップデータを一旦PCにダウンロードする「取得」という機能があります。この取得機能を使った場合、サーバー上にダウンロード用のリンクが生成されるのですが、これには「24時間以内」という期限があります。24時間を過ぎると、生成されたデータはサーバーの負担を減らすために自動的に削除されてしまいます。「週末にゆっくり作業しよう」と思って金曜日に生成ボタンを押しておくと、土曜日には消えていて、また数時間かけて生成し直し……なんてことになってしまいます。ダウンロードの準備ができたら、すぐに自分のPCへ保存するようにしましょう!
復元前に「壊れた現状」も保存しておく
これ、実は一番大事なアドバイスかもしれません。復元を実行すると、今のサーバーにあるデータはすべてバックアップデータで「上書き」され、消えてしまいます。「2日前のデータに戻したけど、やっぱり昨日のあの部分だけは残しておきたかった!」と思っても、もう手遅れです。ですから、復元ボタンを押す前に、あえて「今の壊れた状態のサイト」を一度手動バックアップしておくことを強くおすすめします。壊れているデータでも、その中に最新の記事のテキストだけは生きているかもしれません。「戻す前に、今を捨てる覚悟はあるか?」と自分に問いかけてみてくださいね。この慎重さが、あなたの大切なコンテンツを守る最後の砦になります。
まとめ:エックスサーバーのバックアップ時間を賢く活用
ここまで読んでくださってありがとうございます!エックスサーバーのバックアップに関する「時間」のナゾ、かなり解けてきたのではないでしょうか?最後に大切なポイントを振り返ってみましょう。
エックスサーバー「バックアップ時間」の要点
- 実行時間:深夜AM2:00〜AM6:00頃に自動で行われる(時間は選べない)
- 保持期間:過去14日間。Web・メール・データベースすべて対象で安心!
- 復元時間:容量によるが、大規模サイトは数時間〜半日かかることもある
- 成功のコツ:ディスク容量に余裕を持ち、復元前には「今の状態」も手動保存する
エックスサーバーのバックアップ機能は、間違いなく業界トップクラスの信頼性があります。14日間という長い保持期間と、無料で何度でも戻せる仕組みは、私たちブロガーにとって「最強の保険」です。でも、その保険を過信しすぎず、復元には時間がかかること、そして大事な作業の前には自分でバックアップを取ることを忘れないでくださいね。
「時間」というルールを正しく知っておけば、万が一トラブルが起きてもパニックにならず、「よし、今はサーバーにお任せして、明日の朝まで待とう!」と冷静に対処できるようになります。それが、長く楽しくブログを続けていくための秘訣かな、と私は思います。あなたのサイトが、これからも安全に成長していくことを心から応援していますよ!



コメント