バックアップは「取っているか」だけでなく、「何世代残しているか」が重要です。 最新1回分しか残していないと、壊れた状態や誤操作後のデータで上書きされ、戻したい時点へ戻れないことがあります。
30秒でわかる結論
- 1世代だけでは、異常に気づく前の正常データへ戻れない可能性がある
- 小規模サイトでも、日次7世代＋週次4世代程度を基本に考えると使いやすい
- 更新頻度が高いサイトほど短い間隔で多く残す
- 会社サイト・EC・予約サイトは月次バックアップも加えると安心しやすい
- 世代数は「戻したい期間」と「1回あたりの容量」から決める
- 同じサーバー内だけでなく、別の保存先にも残す
- 教科書判定では「最低7世代、重要サイトは日次＋週次＋月次」で考える
バックアップの「世代」とは？
バックアップの世代とは、異なる日時のバックアップを何回分残しているかを表す考え方です。
7世代の例
- 10月28日
- 10月27日
- 10月26日
- 10月25日
- 10月24日
- 10月23日
- 10月22日
毎日1回バックアップし、7回分を残していれば「日次7世代」と考えられます。
ここで伝えたいポイント
世代数が多いほど、古い時点へ戻れる可能性が高くなります。 ただし保存容量も増えるため、「何日前まで戻りたいか」と「容量」のバランスで決めます。
1世代だけでは足りない理由
バックアップが最新1回分だけだと、異常な状態まで一緒に保存してしまうことがあります。
失敗例
月曜日にサイトが改ざんされ、木曜日に初めて気づいたとします。 毎日バックアップしていても最新1世代しか残していなければ、水曜夜の「すでに改ざん済みデータ」しか残っていない可能性があります。
バックアップ回数と世代数は別
毎日バックアップしていても、毎回前のデータを上書きしているなら1世代です。 「毎日取る」と「複数日分を残す」は分けて確認してください。
何世代残せばいい？
必要な世代数に絶対的な正解はありません。 更新頻度、トラブルへ気づくまでの日数、サイトの重要度で決めます。
| サイト | 目安 | 考え方 |
|---|---|---|
| 個人ブログ | 日次7世代前後 | 1週間程度戻れる状態 |
| 小規模会社サイト | 日次7〜14＋週次4 | 数日前〜1か月前を確保 |
| 高更新メディア | 日次14〜30＋週次 | 更新頻度が高いため細かく残す |
| EC・予約サイト | 日次＋週次＋月次 | 重要データが多く長期復旧も考える |
初心者はこれでOK
迷ったら、まず日次7世代を最低ラインとして確認します。 重要な会社サイトなら、日次だけでなく週次・月次も組み合わせると、より古い正常時点へ戻りやすくなります。
日次・週次・月次を組み合わせる
すべてを毎日30世代残す方法もありますが、日次・週次・月次に分けると保存期間と容量を両立しやすくなります。
直近の誤操作・更新失敗から戻す。
数週間前の正常状態へ戻す。
長期間気づかなかった問題へ備える。
例：日次7世代 ＋ 週次4世代 ＋ 月次3世代 ＝ 合計14世代
この構成なら、直近1週間は細かく戻し、さらに約1か月前・数か月前の時点も残せます。
世代数は「戻したい期間」から逆算する
バックアップ世代数を決めるときは、「異常に何日で気づけるか」を考えます。
具体例
週1回しかサイトを確認しない会社サイトなら、異常発生から気づくまで7日以上かかる可能性があります。 この場合、日次3世代だけでは正常な時点が消えている可能性があります。
世代数は「確認頻度より長く」残す
週1回しか確認しないサイトなら、少なくとも7日以上戻れる状態を作ります。 月1回しか確認しないなら、週次・月次バックアップを追加した方が安全です。
必要容量を計算する
世代数を増やすほど保存容量も増えます。 単純計算では、1回あたりのバックアップ容量に世代数を掛けます。
必要容量の目安 ＝ 1世代の容量 × 世代数
5GBのサイトを14世代残す場合
5GB × 14世代 ＝ 70GB
差分バックアップや圧縮が使える場合は実際の容量が小さくなることがありますが、容量設計では余裕を持って考えます。
容量不足の見落としに注意
5GB × 30世代 ＝ 150GB
「30日分残したい」と考えても、バックアップ先の空き容量が100GBしかなければ単純コピーでは収まりません。 世代数だけでなく保存先容量まで確認してください。
ファイルとデータベースは両方残す
WordPressでは、画像・テーマ・プラグインなどのファイルだけでなく、記事本文や設定が入るデータベースも必要です。
| バックアップ対象 | 主な内容 |
|---|---|
| ファイル | 画像、テーマ、プラグイン、WordPress本体など |
| データベース | 記事、ユーザー、設定、コメントなど |
片方だけでは完全復元できないことがある
画像だけ残っていても記事データがなければ元のサイトへ戻せません。 WordPressではファイルとデータベースをセットで復元できるようにします。
同じサーバー内だけに残して大丈夫？
同じサーバー内にしかバックアップがない場合、サーバー障害・アカウント侵害・誤削除で本体と一緒に失う可能性があります。
保存場所も分ける
レンタルサーバー側の自動バックアップに加えて、必要に応じて外部ストレージやローカルなど別の保存先にも残すと、同時消失のリスクを減らせます。
3-2-1ルールとは？
バックアップ運用でよく使われる考え方に「3-2-1ルール」があります。
Webサイト運用へ当てはめる例
- 本番サーバー
- レンタルサーバー側の自動バックアップ
- 外部クラウド・ローカルなど別環境のバックアップ
重要なのは「3」という数字を機械的に守ることより、1つの障害で全部消えないよう保存先を分けることです。
自動バックアップだけで十分？
レンタルサーバーの自動バックアップは便利ですが、「何日分残るか」「復元できる対象」「復元料金」「解約後の扱い」などはサービスごとに異なります。
自動バックアップで確認する項目
- 保存世代数
- 保存期間
- ファイルとDBの両方が対象か
- 復元手順
- 復元料金
- バックアップ先が本番環境と分離されているか
- 解約・障害時にも取り出せるか
初心者はこれでOK
「自動バックアップあり」だけで安心せず、何日前まで戻れるかを確認してください。 自分が必要とする保存期間より短いなら、別バックアップを追加します。
更新頻度が高いサイトは世代数を増やす
1か月に1回しか更新しない会社サイトと、毎日何十件も注文が入るECサイトでは必要なバックアップ頻度が違います。
| 更新頻度 | 考え方 |
|---|---|
| 月数回 | 日次7〜14世代でも対応しやすい |
| 毎日更新 | 日次14〜30世代を検討 |
| 頻繁な注文・予約 | 日次だけでなく、より短い間隔も検討 |
世代数だけ増やしても復旧時点が粗いことがある
ECサイトを1日1回だけバックアップしている場合、障害直前の数時間分の注文データは戻せない可能性があります。 重要システムでは「何世代」だけでなく「何時間おきに取るか」も確認してください。
バックアップは何日前まで残す？
更新失敗や誤削除へ備える。
異常発見が遅れる可能性を考える。
日次・週次・月次を組み合わせる。
大型更新・移行前は通常世代とは別に確保する。
アップデート前は別バックアップを残す
WordPress本体、テーマ、プラグインの大型更新やサーバー移行前は、通常の自動バックアップとは別に手動バックアップを残すと安全です。
バックアップは復元できて初めて意味がある
バックアップファイルが存在していても、復元方法が分からない、ファイルが壊れている、データベースが欠けている状態では実用的ではありません。
復元テストで確認すること
- バックアップファイルを取得できる
- データベースも含まれている
- 復元手順が分かる
- 必要な権限・ログイン情報を持っている
- テスト環境で表示できる
- 復元にかかる時間を把握している
世代数より先に「復元できること」を確認する
30世代残っていても復元できなければ役に立ちません。 少なくとも重要サイトでは、定期的にテスト環境へ復元し、バックアップが実際に使えることを確認してください。
バックアップ世代数でよくある失敗
毎日取っているから安心だと思う
上書き1世代なら、異常発生後に正常データが消える可能性があります。
世代数だけ増やして容量不足になる
保存容量不足で古いバックアップが削除されたり、新しいバックアップ自体に失敗したりする可能性があります。
本番サーバー内だけに保存する
サーバー障害やアカウント侵害で本体とバックアップを同時に失う可能性があります。
バックアップ成功通知だけを見る
取得できていても復元できるとは限りません。定期的な復元テストが必要です。
解約直前に取り出すつもりで忘れる
サーバー解約後はバックアップへアクセスできなくなる場合があります。移行・解約前に自分で取得します。
バックアップ世代数の判断フロー
はい → 日次7〜14世代以上を検討
はい → 週次バックアップも追加
はい → 日次＋週次＋月次を検討
いいえ → 保存容量を計算
いいえ → 外部保存も追加
いいえ → テスト環境で確認
教科書判定｜バックアップは何世代残すべき？
最低7世代。重要サイトは日次＋週次＋月次で残す
個人ブログや小規模サイトなら、まず日次7世代以上を基準にします。 会社サイトでは14〜30日程度戻れる構成を検討し、EC・予約・重要業務サイトなら週次・月次も組み合わせます。
ただし、本当に重要なのは世代数そのものではありません。 「異常へ気づくまでの期間より長く残す」「別保存先を持つ」「実際に復元できる」の3点を満たしてください。
よくある質問
Q．バックアップは7世代あれば十分ですか？
小規模サイトでは1つの基準になりますが、異常へ気づくまで1週間以上かかるサイトでは不足する可能性があります。更新頻度と確認頻度で決めてください。
Q．30日分残せば安心ですか？
長期間戻れる点では有利ですが、同じサーバー内だけに30世代ある状態では、サーバー障害時にまとめて失う可能性があります。保存場所も分けてください。
Q．レンタルサーバーの自動バックアップだけでいいですか？
保存日数、復元対象、復元方法が自分の要件を満たすなら有力です。重要サイトでは外部保存も追加すると、1つの障害で全データを失うリスクを下げられます。
Q．バックアップ容量が足りない場合はどうしますか？
日次を短くし、週次・月次を組み合わせる、差分バックアップを利用する、外部ストレージへ移すなどで調整します。
Q．WordPress更新前にもバックアップが必要ですか？
大きな更新や移行前は、通常の自動バックアップとは別に手動バックアップを作り、直前の状態へ戻せる地点を確保してください。問題発生時に直前の状態へ戻しやすくなります。
まとめ
この記事の結論
- 1世代だけでは正常時点へ戻れないことがある
- 小規模サイトは日次7世代以上を基本にする
- 重要サイトは日次・週次・月次を組み合わせる
- 1世代容量×世代数で必要容量を計算する
- 別保存先と復元テストまで行う
結局、バックアップの世代数は「多いほど良い」ではなく、「必要な時点へ戻れるか」で決めます。 まず日次7世代以上を確保し、サイトの重要度と確認頻度に合わせて週次・月次を追加してください。
次に読むなら
バックアップ世代数を決めたら、「Webサイトを復元する方法」や「WordPressの保守でやるべきこと」を確認すると、取得したバックアップを実際の復旧へつなげられます。