「サーバーに自動バックアップがあるから大丈夫」
「バックアップ用のプラグインを入れている」
「制作会社に任せているので、何かあっても戻せるはず」
サイトを運営していて、このように考えていませんか？
バックアップは、誤操作や更新時の不具合、サーバー障害、改ざんなどに備える大切な仕組みです。
しかし、保存してあることと、必要なときに正常な状態へ戻せることは同じではありません。
保存対象が足りない、正常な時点のデータが残っていない、復元方法が分からない。こうした状態では、バックアップがあっても復旧に時間がかかります。
確認したいのは「バックアップがあるか」だけでなく、「何を、いつの状態に、誰が戻せるか」です。
この記事では、WordPressのバックアップで確認しておきたい保存対象、保存先、世代管理、復元の備えを整理します。
WordPressは「ファイル」と「データベース」の両方を保存する
WordPressのサイトは、主にファイルとデータベースを組み合わせて動いています。
| 保存対象 | 主な内容 |
|---|---|
| ファイル | WordPress本体、テーマ、プラグイン、画像、設定ファイルなど |
| データベース | 記事、固定ページ、コメント、各種設定、サイト内に保存される注文・予約情報など |
サーバーからファイルをダウンロードしただけでは、通常、データベースまで保存したことにはなりません。
反対に、データベースだけを保存しても、画像や独自に制作したテーマなどは戻せません。
また、注文や予約を外部サービスで管理している場合、その情報がWordPressのバックアップに含まれるとは限りません。メールとして受け取るだけの問い合わせも、メール側の保管を別に確認する必要があります。
何がどこに保存されているのかを把握したうえで、必要な範囲をそろえることが大切です。
ファイルとデータベースは、できるだけ同じ時点の組み合わせで管理します。更新前後のデータを混在させると、プログラムと保存内容が合わなくなる場合があります。
サーバーの自動バックアップだけで十分なのか
サーバー会社の自動バックアップは、日々の保存作業を減らせる便利な機能です。
ただし、保存される期間や対象、復元方法はサービスによって異なります。「自動」という言葉だけで判断せず、現在の契約内容を確認しましょう。
Xserverの自動バックアップにも保存期間がある
Xserverのレンタルサーバーでは、1日1回、バックアップ専用サーバーへデータをコピーし、原則としてWeb・メールデータとMySQLデータベースを過去14日分保持すると案内されています。
ただし、一部の旧サーバーではWeb・メールデータの保持期間が7日分となる例外があります。実際に取得・復元できる日付は、サーバーパネルで確認してください。
また、公式案内ではデータの確実な保全を保証するものではなく、利用者自身でもバックアップすることを推奨しています。
※2026年10月28日時点の公式情報です。対象はXserverのレンタルサーバーで、ほかのサービスや契約では条件が異なる場合があります。
「作業直前」の状態が残っているとは限らない
1日1回の自動バックアップでは、その後に加えた変更が含まれていない場合があります。
例えば、午前中に記事や設定を変更し、午後にプラグインを更新する場合、直近の自動バックアップには午前中の変更が入っていない可能性があります。
大きな更新や設定変更の前には、作業直前の状態を別途保存しておくと、戻す時点を選びやすくなります。
ただし、バックアップの取得中にも注文などが入るサイトでは、データの整合性を保つ方法も検討する必要があります。
保存先は「一緒に失わない」ことを考える
バックアップが公開サイトと同じ場所にしかない場合、その場所に障害が起きたり、不正アクセスで削除されたりすると、元のデータと一緒に失うおそれがあります。
同じサーバー内の別フォルダへコピーするだけでは、備えとして不十分な場合があります。
サーバーの外にも保管する
外部ストレージや、適切に管理した別の保存先にもコピーを残す方法を検討しましょう。
ただし、別の場所に保存しても、同じアカウントからすべて削除できる状態では、アカウントを奪われた際の影響が広がります。
保存場所だけでなく、アクセス権限も分けることが重要です。可能であれば、通常時は接続しない保存媒体や、一定期間変更・削除できない保管機能も選択肢になります。
CISAも、ランサムウェアへの備えとして、オフラインでの暗号化バックアップと、定期的な復元確認を推奨しています。
参考：CISA「#StopRansomware Guide」
バックアップそのものも保護する
バックアップには、個人情報や設定情報などが含まれる可能性があります。
ダウンロードした圧縮ファイルを、誰でもアクセスできる公開フォルダに置いたままにしてはいけません。
保管先のアクセス制限、アカウントの保護、必要に応じた暗号化を確認します。暗号化する場合は、復元に必要な鍵やパスワードを失わない管理も必要です。
最新の1回分だけでは足りない理由
バックアップを取るたびに前のデータを上書きしていると、過去の状態を選べなくなります。
日付の異なるバックアップを残すことを「世代管理」といいます。
改ざん後の状態を保存してしまうことがある
サイトへの侵入や改ざんは、発生したその日に気づけるとは限りません。
気づかないまま自動バックアップが続けば、不正なファイルや設定が含まれた状態も保存されます。
例えば、異変に気づくまで3週間かかり、保存期間が2週間だった場合、正常な状態のバックアップが残っていない可能性があります。これは保存期間を考えるための想定例です。
新しいバックアップだから安全とは限りません。正常な時点を選べることが重要です。
日次だけでなく、週次・月次も検討する
保存方法の一例として、直近の日次バックアップに加え、週単位・月単位のデータを残す考え方があります。
ただし、すべてのサイトに同じ保存期間が適しているわけではありません。
変更の多さ、異変に気づくまでの期間、保存容量、個人情報の保持方針などに合わせて決めましょう。長く残すほど、保存費用や管理の負担も増えます。
バックアップの頻度は「どれだけ失えるか」で考える
記事を月に数回更新するサイトと、注文や予約が日々入るサイトでは、必要な保存間隔が異なります。
記事の更新頻度だけでは決められない
見た目を更新していなくても、注文、予約、会員登録などの情報は増えている場合があります。
確認するべきなのは、ページを何回編集したかだけでなく、サイトの中でどのようなデータが変わっているかです。
1日1回なら、最大で約1日分の差が生じる場合がある
例えば、毎日午前3時に取得が完了する運用で、翌日の午前2時に障害が起きたとします。
直近のバックアップへ戻すだけでは、その間の約23時間に追加された情報が含まれません。これは仕組みを説明するための想定例で、実際には取得時刻や成功状況によって変わります。
注文や予約を扱う場合は、その間のデータを失ってよいのか、別の記録と照合できるのかを考える必要があります。
より短い間隔の保存や変更分の記録が必要になる場合もありますが、対応できる機能、サーバーへの負荷、費用も含めて選びましょう。
「復元できるか」は実際に確認する
バックアップ処理が成功と表示されていても、それだけでサイト全体が正常に戻るとは言い切れません。
実際に復元することで、不足しているデータや手順の問題が見つかることがあります。
検証環境で復元する
復元テストは、公開中のサイトをいきなり上書きするのではなく、検証用の環境で行うことを基本にします。
検証環境では、一般公開を制限し、実際の顧客へのメール送信や決済などが起きないように外部連携を調整します。
本番データを使う場合は、検証環境側の個人情報の保護も必要です。
表示だけでなく、必要な機能まで確認する
トップページが表示されたら完了、ではありません。
- 管理画面へログインできるか
- 記事や画像が正常に表示されるか
- フォームや予約機能が動くか
- 必要な設定や保存データがそろっているか
- 別途設定する外部連携や認証情報がないか
復元にかかった時間と、必要だった作業も記録します。
「データは戻せるが、再開まで数日かかる」という状態では、業務の要求に合わない場合があります。戻せる範囲と、再開までの時間を両方確認しておきましょう。
障害が起きても、すぐに上書き復元しない
トラブルが起きると、急いで元に戻したくなります。
しかし、原因や復元対象を確認せずに操作すると、新しいデータを失ったり、調査に必要な記録を消したりすることがあります。
復元前に、現在のデータと影響範囲を確認する
担当者と次の点を確認します。
- 障害が起きた日時と症状
- 復元に使えるバックアップの日付
- 戻すことで失われる記事・注文・予約など
- 復元対象が一部なのか、サイト全体なのか
- 必要な記録の保全と、受付・更新の一時停止の要否
特に注文や予約があるサイトでは、古いデータベースをそのまま戻すことで、その後の受付情報が消える可能性があります。
必要な差分をどう扱うかも含めて、復旧方法を判断する必要があります。
改ざんの場合は、原因への対応も必要
侵入されたサイトでは、正常なバックアップへ戻しても、侵入経路が残っていれば再び被害を受ける可能性があります。
脆弱性の修正、不正なアカウントやファイルの調査、必要な認証情報の変更なども含めて対応します。
また、バックアップは失われたデータを戻すための備えであり、すでに漏えいした情報を取り消す機能ではありません。
改ざんが疑われる場合は、記録を保全しながら、サーバー会社や保守担当者へ相談してください。
制作会社に任せている場合、どこまで対応してもらえる？
保守契約があっても、バックアップの取得と復旧作業が同じ契約範囲とは限りません。
「バックアップしています」という説明だけでは、必要な対応が分からないため、具体的に確認しましょう。
| 確認すること | 確認したい内容 |
|---|---|
| 保存対象 | ファイルとデータベースの両方か。外部サービスは含まれるか |
| 保存間隔・期間 | どの頻度で取得し、何世代・何日分残すか |
| 保存先 | どこにあり、誰が取り出せるか |
| 復元テスト | 実施しているか。何を確認しているか |
| 障害時の対応 | 連絡先、対応時間、作業開始までの目安 |
| 復旧費用 | 契約内か、別料金か。調査や再構築は含まれるか |
| 契約終了時 | バックアップや復元手順を引き継げるか |
サーバー側でデータ取得や復元を利用できても、原因調査、動作確認、個別の修正などの作業費まで含まれるとは限りません。
安さだけで比較するのではなく、困ったときにどこまで対応してもらえるかを確認しておくことが大切です。
まず確認したい、バックアップの備え
今日確認するなら、次の6つから始めましょう。
- ファイルとデータベースの両方が保存されている
- 最後に正常に取得できた日時が分かる
- 日付の異なるバックアップが残っている
- 元のサイトと一緒に失わない保管方法がある
- 復元手順と担当者が決まっている
- 復元後の表示・機能を確認した記録がある
バックアップを導入した後も、サイトの機能が増えたり、注文や予約が増えたりしたら、保存方法を見直しましょう。
「保存している」から「必要なときに戻せる」へ。そこまで準備して、バックアップが復旧の備えになります。
日々の更新や不正アクセス対策とあわせて確認したい方は、WordPressのサイバー攻撃対策もご覧ください。
現在のバックアップで十分か分からない、制作会社に何を確認すればよいか迷っているという方は、お問い合わせフォームからお気軽にご相談ください。相談は無料です。