はじめに
第31章では、ホームページを公開する前の基本セキュリティを確認しました。
次に確認したいのがバックアップです。
バックアップは、問題そのものを防ぐ機能ではありません。
何か起きたときに、
以前の状態へ戻れる可能性を作るもの
です。
WordPressでは、更新、Theme変更、Plugin追加、コード修正など、公開後も変更を続けます。
変更できるということは、失敗する可能性もあります。
だからこそ、変更する前に「戻れる状態」を作っておきます。
バックアップとは
バックアップは、現在のデータを別の場所や別の時点として保存しておくことです。
たとえば、
変更前
↓
バックアップ
↓
変更
↓
問題発生
↓
必要なら復元という使い方をします。
バックアップがあることで、変更を恐れて何も触れなくなる状態を減らせます。
WordPressでは何をバックアップする？
初心者向けには、大きく2つに分けると分かりやすいです。
ファイル
+
データベースです。
どちらか一方だけでは、WordPressサイト全体を元の状態へ戻せない場合があります。
ファイルには何が入っている？
ファイル側には、たとえば、
- Theme
- Plugin
- アップロードした画像
- WordPress本体
- 各種設定ファイル
などがあります。
特にwp-contentにはTheme、Plugin、アップロード ファイルなどサイト固有のデータが多く含まれます。
データベースには何が入っている？
データベースには、たとえば、
- 投稿
- 固定ページ
- 利用者情報
- WordPress設定
- メニュー
- Pluginが保存する設定やデータ
などがあります。
そのため、
「画像ファイルを保存したからバックアップ完了」
とは限りません。
WordPressを戻すには、ファイルとデータベースの両方を意識します。
Xserverには自動バックアップがある
Xserverでは、サーバー上のデータを自動でバックアップする機能が提供されています。
2026年8月時点では、原則として、
- Web・メール データ：過去14日分
- MySQLデータベース：過去14日分
を保持しています。
ただし、一部の旧サーバーではWeb・メール データの保持期間が異なる場合があります。
そのため、このGuideの数字を覚えるより、
自分のサーバーパネルで実際の取得可能日を確認する
ことが大切です。
自動バックアップがあるから何もしなくてよい？
そうではありません。
Xserverも、自動バックアップデータの完全性を保証するものではなく、利用者自身でもバックアップを行うことを推奨しています。
特に、
- 大きなサイト変更
- Theme変更
- コード変更
- 移行
- 重要な更新
などの前は、ホスティング側の自動バックアップがあることを確認したうえで、サイトの重要度に応じて自分でもバックアップを持つことを考えます。
復元とは
復元は、バックアップデータを使って以前の状態へ戻すことです。
ここで重要なのは、
復元すると現在のデータが上書きされる場合がある
ことです。
XserverのWeb領域復元でも、対象Directory / ファイルがバックアップ時点の内容へ上書きされ、バックアップ後に作成されたファイルが失われる可能性があります。
そのため、
「壊れたから、とりあえず昨日へ戻す」
ではなく、
何が壊れた？
↓
いつから？
↓
どのデータを戻す？
↓
現在のデータで残すべきものは？を確認します。
ファイルだけ戻す？ データベースも戻す？
問題によって、戻す対象は違います。
たとえばThemeファイルの変更だけが原因なら、データベースまで戻す必要がない場合があります。
逆に、投稿データや設定が壊れているならデータベース側の復元が必要になる場合があります。
XserverではWeb領域とMySQLデータベースで復元操作が分かれています。
初心者が自信を持てない場合は、むやみに全部戻すより、原因を確認してから復元します。
復元前に現在データも考える
たとえば、3日前のバックアップへ戻すとします。
その3日間に、
- 新しい問い合わせ
- 新しい投稿
- ページ修正
- EC Order
- 利用者登録
などがあれば、古い状態へ戻すことで失われる可能性があります。
復元は「過去へ戻る操作」です。
戻す前に、
戻ることで何を失うか
も確認します。
バックアップは「ある」だけで終わらせない
バックアップはいつ確認する？
特に確認したいのは、大きな変更の前です。
たとえば、
- WordPress Coreの大きな更新
- Theme変更
- Pluginの大きな変更
- PHPバージョン変更
- コード編集
- ドメイン / サーバー移行
などです。
すべての小さな編集で大掛かりなバックアップ作業を行う必要はありません。
変更リスクに応じて考えます。
バックアップを一か所だけに依存しすぎない
小規模サイトではXserverの自動バックアップが非常に心強い仕組みです。
ただし、重要度が高いサイトでは、
ホスティング バックアップ
+
必要に応じた別バックアップという考え方もあります。
「バックアップPluginを何個も入れる」という意味ではありません。
重要なのは、
同じ障害で全部失われない状態を考えること
です。
バックアップは「ある」ではなく「使える」まで確認する
バックアップの弱点は、
「取れていると思っていた」
が起きることです。
最低限、
- バックアップは存在する？
- 何日前まである？
- ファイルとデータベースは？
- 復元はどこから行う？
- 誰が戻せる？
を確認します。
実際の復元を本番サイトで気軽に試す必要はありません。
ただし、戻し方を一度も見たことがない状態は避けます。
Xserverで復元する場合
Xserverではサーバーパネルから自動バックアップデータを選び、Web領域やMySQLデータベースを復元できます。
復元はデータを上書きする操作です。
画面を見ながら、
- 対象ドメイン
- バックアップ日付
- 復元対象
をよく確認します。
不安な場合はXserverサポートや詳しい担当者へ確認してから実行します。
今回のポイント
- バックアップは事故を防ぐ機能ではなく、戻れる状態を作るもの
- WordPressではファイルとデータベースの両方を考える
- Xserverには自動バックアップがある
- 2026年8月時点では原則14日分だが、一部旧サーバーでは異なる場合がある
- ホスティング バックアップだけへ完全依存しない
- 復元すると現在データが上書きされる場合がある
- 戻す前に「何を失うか」も確認する
- 大きな変更前にはバックアップ状態を確認する
- バックアップは存在だけでなく、戻し方まで把握する
今回の視点
バックアップは、
「壊れたときのための保険」
だけではありません。
戻れると分かっているから、
更新できる。
改善できる。
新しいことを試せる。
つまりバックアップは、
ホームページを安全に変えていくための土台
でもあります。
第41章では、このバックアップを前提にWordPressを安全に更新する方法を扱います。
Part 5｜公開前の安全性と復旧準備
前へ：第31章「WordPress公開前の基本セキュリティを確認しよう」