この記事の内容(9項目)

レンタルサーバーを比べるとき、「自動バックアップあり」と書かれていると安心します。ただ、実際に戻す場面では、何日前まで残るかだけでなく、どのデータが対象か、どこまで戻るか、復元後に何を確認するかが必要です。

このサイトをXServerへ配信するとき、私はサーバーの自動バックアップとは別に、公開中のファイルを日時付きで残してから切り替えています。公開後は配信ファイルと生成したファイルを照合し、問題があれば直前版へ戻せるようにしました。

一方、XServerの管理画面にある自動バックアップからの復元操作は、この記事のためには実行していません。今回は公式マニュアルと自分の配信手順を使い、復元を始める前に確認したい項目をまとめます。

先に結論

「バックアップがある」だけでは、復元準備ができたとは限りません。私なら次の6つを確認します。

  1. Web、メール、データベースのどれが対象か
  2. 何日分が保持されているか
  3. 取得と復元のどちらを行うか
  4. 作業用の空き容量が足りるか
  5. 現在の状態を別に残したか
  6. 復元後に何を照合するか

特に、バックアップ取得とサーバー全体の復元を同じ操作だと思わないことが大切です。まず必要なデータを取り出して確認できるなら、いきなり本番を戻すより影響を小さくできます。

1. 対象データを分ける

サイトに必要なデータは、構成によって違います。

  • HTML、CSS、画像などのWeb領域
  • WordPressなどが使うデータベース
  • 独自ドメインのメール
  • サーバー上の設定ファイル
  • DNSや外部サービス側の設定

XServerの公式マニュアルでは、サーバー領域のWeb・メールデータについて、自動バックアップの取得・復元を案内しています。データベースは別のメニューと手順が用意されています。

静的サイトなら主にWeb領域ですが、WordPressならファイルだけを戻しても記事や設定が戻らない場合があります。復元対象を「サイト一式」とまとめず、Web、データベース、メールを分けて確認します。

DNSやSearch Console、アクセス解析など、サーバー外の設定はサーバーのバックアップだけでは戻りません。別の記録が必要です。

2. 保持日数と基準時刻を確認する

XServerの公式マニュアルでは、自動バックアップデータを14日間保持すると案内されています。一部の旧サーバーは7日間で、実際の保持日数はサーバーパネルで確認するよう記載されています。

保持日数だけでなく、問題が起きた時刻より前のバックアップを選べるかを見ます。更新直後に不具合へ気づかなかった場合、正常だった日付を記録していないと選びにくくなります。

普段の更新時に、公開日時、変更内容、直前版の保存先を残しておくと、戻したい時点を決めやすくなります。

3. 「取得」と「復元」を分ける

公式の「自動バックアップデータ取得申請」では、保存されたバックアップデータをサーバー上の /userbackup へ設置し、FTPなどでダウンロードできると案内されています。

これは、現在公開中のデータをすぐ置き換える操作とは別です。必要なファイルを確認したい場合は、まず取得して中身を見る方法があります。

一方、復元は現在の環境へ影響します。対象範囲、復元日時、復元中の更新、メールへの影響を確認し、必要なら利用者へ作業時間を案内します。

4. 空き容量と取得データの扱いを確認する

XServerの公式マニュアルには、バックアップデータのサイズ分の空き容量がないと取得に失敗する場合があると記載されています。

また、取得したバックアップデータは24時間経過すると自動削除され、保存先に既存データがある場合は古いデータが削除される注意もあります。

取得申請前に確認するのは次の3つです。

  • サーバーの空き容量
  • すでに /userbackup へ置かれたデータの有無
  • 取得後にどこへダウンロードして保管するか

バックアップを取得できても、確認前に消えたら復元判断へ使えません。取得後の保存先まで先に決めます。

5. 現在の状態も別に残す

過去へ戻す前に、現在の状態も保存します。

不具合がある状態でも、直近で追加した画像、記事、メールなど、残したいデータが含まれているかもしれません。過去版だけを正として全体を戻すと、問題がなかった更新まで消える可能性があります。

このサイトでは、公開ディレクトリを日時付きで複製してから新しいファイルへ切り替えています。サーバーの自動バックアップとは別に、直前の配信単位へ戻すための小さなバックアップです。

WordPressなどの動的サイトでは、ファイルとデータベースの時点を合わせる必要があります。現在版と復元候補を別々に残し、何を戻すかを決めます。

6. 復元後の照合項目を先に作る

復元ボタンが完了しても、サイト全体が正常とは限りません。

最低限、次を確認します。

  • トップページと主要記事が表示される
  • HTTPSとwwwの転送が想定どおり
  • 画像、CSS、内部リンクが取得できる
  • 問い合わせやログインなど必要な機能が動く
  • PR表記や広告リンクが欠けていない
  • 更新前後で残すべき記事やファイルが揃っている

このサイトでは、公開後にURL、タイトル、PR、リンク、配信ファイルの一致を確認しています。復元時も、正常だった版の確認項目をそのまま使えます。

サーバー選びで見る場所

契約前は、保持日数だけでなく、対象データ、取得方法、復元方法、費用、管理画面から操作できる範囲を比べます。

サイトを公開して実際に使ったサーバー機能では、公開時に使った機能へ絞っています。シンレンタルサーバーとエックスサーバーの比較では、料金だけでなく管理と復旧の条件も確認できます。

WordPressの復旧や移行を自分で抱えるか、ホスティング側へ任せるかまで比べたい場合は、Kinstaとエックスサーバーの比較もあわせて確認できます。

自動バックアップは最後の保険です。普段の更新でも直前版を残し、公開後の確認項目を固定しておくと、小さな不具合は小さな単位で戻せます。

復元前チェックメモ

【問題が起きた日時】

【最後に正常だった日時】

【戻す対象】
Web/メール/データベース/個別ファイル

【使うバックアップ日時】

【現在版の保存先】

【必要な空き容量】

【取得データの退避先】

【復元後に確認するURL・機能】

【問題が残った場合の戻し方】

この欄が埋まるまで、復元操作は始めません。

この記事の確認情報

最終確認日:2026年9月16日

確認に使ったもの

  • hitori-tool.comの配信前に公開ディレクトリを日時付きで複製している運用記録
  • 配信後に公開ファイルと生成ファイルを照合している検査記録

参照した公式情報

リンクは新しいタブで開きます。