サーバーの自動バックアップとは、Webサイトのファイルやデータベースなどを、サーバー側で定期的に自動保存する仕組みです。
WordPressの更新失敗、誤削除、データベース破損、不正アクセスなどが起きたとき、過去の状態へ戻すために使います。
ただし、「自動バックアップあり」だけでは十分ではありません。何日前まで残るのか、何世代あるのか、復元は無料か、メールも対象か、同じサーバー障害で同時に失われないかまで確認する必要があります。
30秒でわかる結論
- 自動バックアップはサーバー側で定期的にデータを保存する仕組み
- WordPressファイルとデータベースの両方が対象か確認する
- 「14日保存」なら14世代とは限らないため、保存頻度も見る
- 復元が無料か、有料か、自分で操作できるかを確認する
- メールやSSL設定など、バックアップ対象外のデータもある
- バックアップが同じ障害範囲にあると、災害・大規模障害には弱い場合がある
- 重要サイトはサーバー自動バックアップ＋別保存の二重化が安心
サーバーの自動バックアップとは？
自動バックアップとは、利用者が毎回操作しなくても、サーバー事業者側で定期的にデータのコピーを保存する仕組みです。
例
毎日深夜2時にWebファイルとデータベースを保存し、過去14日分を残す、といった運用です。
現在のデータ ＋ 過去のコピー ＝ 障害時の復元材料
バックアップがあることで、現在のデータが壊れたときに「昨日」「3日前」「1週間前」などの状態へ戻せる可能性があります。
自動バックアップは何から守る？
自動バックアップは、主に「壊れた後に戻す」ための対策です。
| トラブル | バックアップで対応できる可能性 |
|---|---|
| WordPress更新失敗 | 高い |
| 記事・画像の誤削除 | 高い |
| データベース破損 | 高い |
| 不正改ざん | 改ざん前データが残っていれば可能 |
| サーバー障害 | 保存先・構成による |
| ドメイン失効 | 原則別問題 |
バックアップは予防ではなく復旧対策
自動バックアップがあっても、不正アクセスや更新失敗そのものを防ぐわけではありません。セキュリティ対策とバックアップは役割が違います。
バックアップ対象は何？
レンタルサーバーの自動バックアップでは、主に次のデータが対象になります。
よくある対象
- Webサイトのファイル
- WordPress本体
- テーマ・プラグイン
- アップロード画像
- データベース
- メールデータ
ただし、何が対象になるかはサービスによって異なります。
「サイト全体」と思い込まない
Webファイルとデータベースは保存されても、メール、アクセスログ、DNS設定、SSL証明書、サーバー設定などは対象外の場合があります。
WordPressではファイルとデータベースの両方が必要
WordPressは、ファイルだけ戻しても完全には復元できません。
記事本文、固定ページ、コメント、各種設定などの多くはデータベースへ保存されています。
| 保存場所 | 主な内容 |
|---|---|
| ファイル | WordPress本体、テーマ、プラグイン、画像 |
| データベース | 記事、固定ページ、設定、ユーザー情報 |
WordPress復元 ＝ ファイル ＋ データベース
WordPress用途では「ファイル＋DB」が復元できるかを最優先
「自動バックアップ対応」と書かれていても、WordPressのデータベースまで戻せるかを確認してください。
保存期間と保存世代の違い
バックアップを見るときは、「何日保存するか」と「何個のバックアップがあるか」を分けて考えます。
例1：毎日バックアップ・14日保存
1日1回なら、単純には最大14世代です。
1日1回 × 14日 ＝ 14世代
例2：週1回バックアップ・14日保存
同じ「14日保存」でも、残るのは2～3世代程度になる可能性があります。
「14日保存」という表記だけでなく、バックアップ頻度も確認することが大切です。
毎日バックアップなら十分？
一般的なブログや会社サイトでは、毎日バックアップが使いやすい基準です。
ただし、更新頻度が高いサイトでは1日1回では失うデータが多くなる場合があります。
1日100件の注文があるECサイト
深夜0時にバックアップし、23時に障害が起きた場合、最大で約23時間分の注文データを失う可能性があります。
100件/日 ÷ 24時間 × 23時間 ≒ 96件
重要なのは「毎日かどうか」ではなく、どこまでのデータ損失を許容できるかです。
RPOで考えるとバックアップ頻度を決めやすい
RPOは、障害発生時に「何時間前までのデータ損失なら許容できるか」という考え方です。
| 許容損失 | 必要なバックアップ頻度の考え方 |
|---|---|
| 24時間 | 1日1回 |
| 6時間 | 6時間ごとなど |
| 1時間 | 1時間ごと等を検討 |
サイト用途で変える
週1回しか更新しない会社サイトと、毎時間注文が入るECサイトでは、必要なバックアップ頻度は同じではありません。
復元方法も必ず確認する
バックアップが保存されていても、自分で簡単に復元できるとは限りません。
| 復元方法 | 特徴 |
|---|---|
| 管理画面から復元 | 初心者でも操作しやすい |
| バックアップをダウンロード | 自分で手動復元が必要 |
| サポートへ依頼 | 時間・費用がかかる場合あり |
バックアップ数より「戻せるか」が重要
30日分残っていても、復元方法が難しく緊急時に使えなければ意味が薄くなります。初心者は管理画面から復元できるサービスを選ぶと安心です。
復元料金は無料？有料？
レンタルサーバーによって、バックアップ保存は無料でも、復元時に料金がかかる場合があります。
費用の見方
月額1,000円のサーバーでも、復元依頼が1回5,000円なら、トラブル時の実質コストは変わります。
月額だけでなく復元費用も確認
特に会社サイトでは、「バックアップ無料」だけでなく「復元無料」「何回まで」「どの範囲まで」を確認してください。
自動バックアップとWordPressプラグインの違い
WordPressバックアッププラグインでも、ファイルやデータベースを保存できます。
| 比較 | サーバー自動バックアップ | WordPressプラグイン |
|---|---|---|
| 設定 | 事業者側が管理 | 自分で設定 |
| WordPress停止時 | 使いやすい | 復元が難しい場合あり |
| 保存先 | 事業者側 | クラウド等へ指定可能 |
| 細かな頻度設定 | サービス次第 | 柔軟な場合あり |
初心者はこれでOK
まずサーバー自動バックアップを基本にし、重要サイトでは別クラウド保存などを追加すると二重化しやすくなります。
同じサーバー内だけのバックアップで大丈夫？
バックアップは、元データと同じ障害で失われない場所に保存するほど安全性が高まります。
たとえば元データとバックアップが同じ物理サーバーだけにあると、そのサーバー自体の大きな障害で両方失うリスクがあります。
元データと別障害領域へ保存 ＝ リスク分散
保存先の分離を確認
「別サーバー保存」「遠隔地保存」「別ストレージ保存」など、バックアップがどこに保存されるか確認できると安心です。
自動バックアップがあっても手動バックアップは必要？
重要な変更前には、手動バックアップも取っておくと安全です。
手動保存がおすすめのタイミング
- WordPress本体を大きく更新する前
- テーマ変更前
- プラグイン大量更新前
- サーバー移転前
- データベース操作前
- 大規模リニューアル前
なぜ必要？
自動バックアップが毎日3時でも、15時に大きな変更をするなら、その直前状態は自動バックアップには残っていません。作業直前の手動保存があると戻しやすくなります。
バックアップから戻せないケース
自動バックアップがあっても、必ず復元できるわけではありません。
| ケース | 理由 |
|---|---|
| 改ざんに長期間気づかない | 正常世代がすべて上書きされる |
| 対象外データを失う | メール・設定等が未保存 |
| 契約終了後 | バックアップも削除される場合 |
| 保存期間を超えた | 古い世代が消えている |
| バックアップ自体が破損 | 復元できない可能性 |
「14日保存」の弱点
不正改ざんに20日間気づかなければ、14日分すべてが改ざん後データになっている可能性があります。長期世代や別保存が役立つ場面です。
何世代残っていれば安心？
一般的なWordPressサイトでは、最低でも7～14日程度の世代があると直近トラブルへ対応しやすくなります。
会社サイトや更新頻度が高いサイトでは、日次に加えて週次・月次の長期バックアップがあると安心です。
世代構成の例
日次：14世代
週次：4世代
月次：3世代
これなら、直近の誤操作にも、数週間前から続いていた問題にも対応しやすくなります。
バックアップ容量はサーバー容量に含まれる？
バックアップ領域が契約中のSSD容量に含まれるかどうかはサービスによって異なります。
容量計算の例
サイトデータが10GBで14世代すべてを単純コピーすると、理論上は140GBです。
10GB × 14世代 ＝ 140GB
実際のバックアップは差分保存や圧縮が使われる場合もあるため単純計算どおりではありませんが、バックアップ領域が別枠かどうかは確認する価値があります。
自動バックアップで確認する8項目
契約前・運用前チェック
- バックアップ頻度
- 保存期間
- 保存世代数
- ファイルが対象か
- データベースが対象か
- メールが対象か
- 復元料金
- 復元方法と保存先
用途別｜必要なバックアップ体制
日次バックアップと7～14日程度の世代があれば、日常的な更新事故へ対応しやすくなります。
サーバー自動バックアップに加え、定期的に別ストレージへ保存すると安心です。
注文・予約データが頻繁に増えるため、1日1回では損失が大きい可能性があります。
RPO/RTO、復元テスト、別障害領域保存まで含めて設計します。
自動バックアップでよくある失敗
「バックアップあり」だけで契約する
保存日数や復元料金を確認せず、必要なときに使えないことがあります。
データベースが対象外だった
WordPressの記事や設定まで戻せない可能性があります。
復元手順を一度も確認していない
障害時に操作方法が分からず、復旧が遅れます。
自動バックアップだけを信じる
長期間気づかない改ざんや事業者側の大規模障害には弱い場合があります。
バックアップを取ったまま復元テストしない
実際に戻せることを確認して初めて、バックアップとして機能します。
初心者向けのバックアップ運用
教科書判定｜「自動バックアップあり」ではなく「戻せる条件」で選ぶ
初心者は日次・7～14日以上・ファイル＋DB・簡単復元を基準にする
一般的なWordPressブログや会社サイトなら、毎日自動バックアップされ、7～14日以上残り、ファイルとデータベースの両方を復元できるサービスが扱いやすいです。重要サイトでは、さらに別ストレージへの保存を追加してください。
よくある質問
Q．自動バックアップがあればプラグインは不要ですか？
一般的なサイトではサーバー自動バックアップだけでも十分な場合があります。重要サイトや別保存が必要な場合は、プラグインや外部ストレージを追加します。
Q．毎日バックアップなら安全ですか？
更新頻度によります。1日に何度も注文や予約が入るサイトでは、日次だけでは最大24時間近いデータを失う可能性があります。
Q．バックアップは何日残ればいいですか？
一般サイトなら7～14日程度が扱いやすい目安です。改ざん発見が遅れる可能性や業務要件がある場合は、週次・月次の長期世代も検討します。
Q．自動バックアップから復元すると現在のデータはどうなりますか？
過去データで現在のデータを上書きする方式では、バックアップ時点以降の更新が失われる場合があります。復元前に現在データも保存してください。
Q．メールも自動バックアップされますか？
サービスによって異なります。Web・DBだけ対象でメールは対象外の場合もあるため、契約先のバックアップ対象を確認してください。
まとめ｜自動バックアップは「保存」より「復元できるか」が重要
この記事の結論
- 自動バックアップは障害・誤操作後に戻すための仕組み
- WordPressではファイルとデータベースの両方が重要
- 保存日数だけでなく頻度・世代数を見る
- 復元料金と復元方法を契約前に確認する
- メール等が対象外の場合がある
- 大きな変更前は手動バックアップも取る
- 重要サイトは別保存を追加する
初心者は、「自動バックアップがあるか」ではなく「いつの状態まで、何を、どうやって戻せるか」で判断してください。一般的なWordPressサイトなら、日次・7～14日以上・ファイル＋DB・簡単復元を基準にすると選びやすくなります。
次に読むなら
自動バックアップの仕組みを理解したら、「バックアップは何世代残すべき？」で、日次・週次・月次の世代設計を用途別に確認してください。