先に要点
バックアップって何世代くらい残せばいいの？ という相談はかなり多いです。
でも実際には、7世代が正解 みたいな単純な話ではありません。
大事なのは、どこまで戻れれば業務が成立するか、止まってよい時間はどのくらいか、バックアップが壊れていないか、まで一緒に考えることです。
このページでは、2026年4月4日時点で Microsoft Azure Well-Architected の信頼性指標、AWS Backup の restore testing、CISA の #StopRansomware Guide とバックアップ資料を確認しながら整理しています。
Linux サーバーの土台から見直したい場合は、Linuxサーバーの初期設定で最初にやることは？見直したい項目を実務目線で整理 もつながりやすいです。
ランサムウェアの全体像や、実際の事件から何を学ぶべきかまで含めて見たい場合は、ランサムウェアとは？手口・対応策・実際に起きた事件をわかりやすく解説 もあわせて読むとつながります。
何世代必要かに正解がない理由
バックアップの世代数は、何を守りたいか で変わります。
単に「最新だけ残す」では、誤削除や壊れた状態まで一緒に保存してしまうことがありますし、逆に闇雲に大量保存しても、復旧方針が曖昧なら意味が薄いです。
まず考えたいのはこの2つです。
たとえば、
- 社内Wikiなら
半日分戻ってもよいが、当日中には復旧したい - ECサイト受注データなら
数分でも戻りすぎると困る - 検証環境なら
最悪作り直しでもよい
のように、同じサーバーでも要求はかなり違います。
実務で多い世代の考え方
実務では、全部を同じ間隔で残すより、短期・中期・長期に分ける考え方が多いです。
よくある残し方の例
日次: 7世代
週次: 4世代
月次: 12世代
これはかなりよく見る形です。
意味としては、
- 日次: 直近のミスや障害に対応
- 週次: 少し前の破損や気づくのが遅れた問題に対応
- 月次: 長めの保管や棚卸し向け
という分担です。
もう少し短い構成で済む場面
- 検証環境
- すぐ作り直せる環境
- データ更新頻度が低いサイト
この場合は、日次数世代 + 週次少し、でも回ることがあります。
もっと厚くした方がよい場面
- 売上や受注を扱う
- 社内の重要業務データを持つ
- ランサムウェアや誤削除の影響が大きい
- 月末締めや監査で過去時点が必要
この場合は、世代数だけでなく 保管先を分ける、オフライン性を持たせる、スナップショットと論理バックアップを分ける まで考えた方が安全です。
世代数より大事なこと
世代数だけ先に決めても、実務では足りません。
少なくとも次はセットで見ます。
1. 保存場所を分ける
CISA のガイドでも、バックアップはオフラインまたはクラウド間など、元の環境と切り離して持つこと、そして定期的に復旧可能性を確認することが勧められています。
同じサーバー内だけに置くと、サーバー障害や侵害で一緒に失う可能性があります。
2. バックアップ方法を分ける
バックアップにはざっくり次の種類があります。
スナップショットは速く戻しやすいですが、誤った状態を丸ごと保存することもあります。
逆にダンプは戻す手間がかかりますが、論理的に中身を見やすいです。
どちらか片方だけより、役割を分けて持つ方が実務では強いです。
3. 復旧確認をする
AWS Backup でも restore testing が用意されていて、復元可能性や所要時間を定期的に確認できるようになっています。
つまり、クラウドでも 取っているだけでは足りない という前提です。
バックアップで本当に大事なのは、次を知っていることです。
- 戻せるか
- どれくらい時間がかかるか
- どこまで戻るか
- 誰が判断して実行するか
実際の復旧方法はどう考えるか
復旧は、保存方法ごとに考えた方が混乱しにくいです。
ファイルを戻す場合
たとえば /var/www/app/storage やアップロード画像だけ壊れた場合は、ファイル単位で戻す方が被害を小さくしやすいです。
tar.gz バックアップなら、まずは展開先を分けて確認します。
mkdir -p /tmp/restore-check
tar -xzf app-files-2026-04-03.tar.gz -C /tmp/restore-check
いきなり本番へ上書きするのではなく、
- 欲しいファイルが本当に入っているか
- パスが想定どおりか
- 権限や所有者を戻せるか
を先に見ます。
そのうえで必要な部分だけ戻します。
rsync -av /tmp/restore-check/storage/ /var/www/app/storage/
ここで大事なのは、全部戻す ではなく 必要な範囲だけ戻す ことです。
アプリ全体を古い状態へ巻き戻すと、別の差分まで消すことがあります。
スナップショットから戻す場合
サーバーやディスクの スナップショット は、環境をまとめて戻しやすいのが利点です。
ただし、本番中のディスクをそのまま即上書きで戻すのはかなり慎重にやるべきです。
実務では、まずこう考えることが多いです。
- スナップショットから別ディスクや別VMを起こす
- 中身を確認する
- 必要ならデータだけ取り出す
- 本番へ戻すか、新環境へ切り替えるか判断する
この流れの方が、誤って正常なデータまで消しにくいです。
MySQL をダンプから戻す場合
MySQL の論理バックアップが mysqldump などで取ってあるなら、復旧は比較的分かりやすいです。
ただし、本番DBへいきなり流し込む前に確認を入れた方が安全です。
まずは新しいDB名や検証環境へ戻して確認します。
mysql -u user -p -e "CREATE DATABASE restore_check;"
mysql -u user -p restore_check < db-2026-04-03.sql
確認したいのはこのあたりです。
- 必要なテーブルがあるか
- 件数が大きくずれていないか
- 文字化けしていないか
- 想定した時点まで戻っているか
問題がなければ、本番へどう戻すかを判断します。
丸ごと差し替えるのか、必要なテーブルだけ戻すのかで手順は変わります。
Laravel などアプリ込みで戻す場合
アプリ系は、ファイルだけ でも DBだけ でも足りないことがあります。
少なくとも次を一緒に見た方が安全です。
- アプリコード
.envなど設定- アップロードファイル
- DB
- キューやジョブ
- キャッシュ
復旧後に php artisan config:clear や php artisan cache:clear が必要なこともあります。
戻したあとにアプリが起動するか、ログインできるか、フォーム送信が通るかまで確認した方が実務向きです。
復旧確認はどうやるべきか
復旧確認は、本番事故のときに初めてやるものではありません。
少なくとも、定期的にこういう確認をしておくと安心です。
- バックアップファイルが取得できているか
- 展開やインポートが実行できるか
- 欲しい時点のデータが戻るか
- 復旧に何分かかるか
- 復旧後にアプリが正常動作するか
特に 所要時間 は軽く見ない方がいいです。
RTO を1時間で考えていたのに、実際はダウンロードや展開で3時間かかる、は普通に起こります。
実務で多いルールの例
ざっくりした叩き台なら、次のような形はかなり現実的です。
- 日次 7 世代、週次 4 世代、月次 12 世代
- 本番と別の保管先を持つ
- ファイルとDBを分けてバックアップする
- 重要環境はスナップショットも持つ
- 四半期に1回は復旧確認をする
- 復旧手順をメモではなく運用手順として残す
もちろん、これは万能ではありません。
でも 最新だけ1つ よりはかなり安全で、何十世代もあるけど戻したことがない よりも実務的です。
よくある失敗
世代数だけ決めて満足し、どこまで戻るか、何分かかるか、誰が復旧するかを決めていないケースはかなり多いです。バックアップ設計は「保存」と「復旧」を分けずに考えた方が安全です。
特に多いのはこのあたりです。
- 同じサーバーにしか置いていない
- バックアップはあるが復旧手順がない
- 本番へいきなり上書きして二次被害を出す
- DB とファイルの時点がずれている
- 所要時間を測っていない
まとめ
バックアップの世代数は、単純に 何個残すか ではなく、RPO と RTO をどう置くかで決まります。
実務では、日次・週次・月次に分けて複数世代を持ちつつ、保存先を分け、ファイル・DB・スナップショット の役割を分けるやり方がかなり多いです。
そして一番大事なのは、戻せることを確認する ことです。
バックアップは保存枚数より、復旧の現実味があるかどうかで価値が決まります。
参考情報
- Microsoft Learn: Architecture strategies for defining reliability targets
- AWS Backup: Restore testing
- AWS Backup: Restore a backup by resource type
- CISA: #StopRansomware Guide
- CISA: Back Up Government Data