先に要点
バックアップは取っているのに、いざというとき戻せない という状態はかなり多いです。
実際、事故が起きてから初めて復元を試し、そこで ファイルが足りない パスワードが分からない データベースが入らない 思った時点まで戻らない と気づくケースは珍しくありません。
このテーマは、単に世代数を決めれば終わる話ではありません。
大事なのは、どこまで戻れれば業務が成立するか、止まってよい時間はどのくらいか、そして本当に復元できるかを先に確認しておくことです。
このページでは、2026年4月4日時点で Microsoft Azure Well-Architected の信頼性指標、AWS Backup の復元テスト、CISA の #StopRansomware Guide とバックアップ資料を確認しながら整理しています。
Linux サーバーの土台から見直したい場合は、Linuxサーバーの初期設定で最初にやることは？見直したい項目を実務目線で整理 もつながりやすいです。
ランサムウェアの全体像や、実際の事件から何を学ぶべきかまで含めて見たい場合は、ランサムウェアとは？手口・対応策・実際に起きた事件をわかりやすく解説 もあわせて読むとつながります。
何世代必要かに正解がない理由
バックアップの世代数は、何を守りたいか で変わります。
単に「最新だけ残す」では、誤削除や壊れた状態まで一緒に保存してしまうことがありますし、逆に闇雲に大量保存しても、復旧方針が曖昧なら意味が薄いです。
まず考えたいのはこの2つです。
たとえば、
- 社内Wikiなら
半日分戻ってもよいが、当日中には復旧したい - ECサイト受注データなら
数分でも戻りすぎると困る - 検証環境なら
最悪作り直しでもよい
のように、同じサーバーでも要求はかなり違います。
実務で多い世代の考え方
実務では、全部を同じ間隔で残すより、短期・中期・長期に分ける考え方が多いです。
よくある残し方の例
日次: 7世代
週次: 4世代
月次: 12世代
これはかなりよく見る形です。
意味としては、
- 日次: 直近のミスや障害に対応
- 週次: 少し前の破損や気づくのが遅れた問題に対応
- 月次: 長めの保管や棚卸し向け
という分担です。
もう少し短い構成で済む場面
- 検証環境
- すぐ作り直せる環境
- データ更新頻度が低いサイト
この場合は、日次数世代 + 週次少し、でも回ることがあります。
もっと厚くした方がよい場面
- 売上や受注を扱う
- 社内の重要業務データを持つ
- ランサムウェアや誤削除の影響が大きい
- 月末締めや監査で過去時点が必要
この場合は、世代数だけでなく 保管先を分ける、オフライン性を持たせる、スナップショットと論理バックアップを分ける まで考えた方が安全です。
バックアップはあるのに戻せない原因
実務で詰まりやすいのは、次のようなパターンです。
- バックアップファイルはあるが、展開やインポートを試したことがない
- 本番と違うデータベースバージョンで戻そうとして失敗する
- アップロードファイルや添付ファイルがバックアップ対象から漏れている
.envや接続情報、証明書など復旧に必要な設定値が残っていない- ファイル権限や所有者が崩れてアプリが起動しない
- 復旧に何時間かかるか分かっていない
つまり、問題は 保存していない ことより、戻す前提で設計していない ことにあります。
世代数より大事なこと
世代数だけ先に決めても、実務では足りません。
少なくとも次はセットで見ます。
1. 保存場所を分ける
CISA のガイドでも、バックアップはオフラインまたはクラウド間など、元の環境と切り離して持つこと、そして定期的に復旧可能性を確認することが勧められています。
同じサーバー内だけに置くと、サーバー障害や侵害で一緒に失う可能性があります。
2. バックアップ方法を分ける
バックアップにはざっくり次の種類があります。
スナップショットは速く戻しやすいですが、誤った状態を丸ごと保存することもあります。
逆にダンプは戻す手間がかかりますが、論理的に中身を見やすいです。
どちらか片方だけより、役割を分けて持つ方が実務では強いです。
特に AWS では、AMI と スナップショット が似て見えやすいですが役割は別なので、起動用イメージとディスク時点コピーの違いを整理したい場合は AMIとスナップショットはどう違うのか もあわせて読むとつながります。
3. 復旧確認をする
AWS Backup でも復元テストが用意されていて、復元可能性や所要時間を定期的に確認できるようになっています。
つまり、クラウドでも 取っているだけでは足りない という前提です。
バックアップで本当に大事なのは、次を知っていることです。
- 戻せるか
- どれくらい時間がかかるか
- どこまで戻るか
- 誰が判断して実行するか
実際の復旧方法はどう考えるか
復旧は、保存方法ごとに考えた方が混乱しにくいです。
ファイルを戻す場合
たとえば /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 などで取ってあるなら、復旧は比較的分かりやすいです。
ただし、本番データベースへいきなり流し込む前に確認を入れた方が安全です。
まずは新しいデータベース名や検証環境へ戻して確認します。
mysql -u user -p -e "CREATE DATABASE restore_check;"
mysql -u user -p restore_check < db-2026-04-03.sql
確認したいのはこのあたりです。
- 必要なテーブルがあるか
- 件数が大きくずれていないか
- 文字化けしていないか
- 想定した時点まで戻っているか
問題がなければ、本番へどう戻すかを判断します。
丸ごと差し替えるのか、必要なテーブルだけ戻すのかで手順は変わります。
Laravel などアプリ込みで戻す場合
アプリ系は、ファイルだけ でも DBだけ でも足りないことがあります。
少なくとも次を一緒に見た方が安全です。
- アプリコード
.envなど設定- アップロードファイル
- データベース
- キューやジョブ
- キャッシュ
復旧後に php artisan config:clear や php artisan cache:clear が必要なこともあります。
戻したあとにアプリが起動するか、ログインできるか、フォーム送信が通るかまで確認した方が実務向きです。
復旧確認はどうやるべきか
復旧確認は、本番事故のときに初めてやるものではありません。
少なくとも、定期的にこういう確認をしておくと安心です。
- バックアップファイルが取得できているか
- 展開やインポートが実行できるか
- 欲しい時点のデータが戻るか
- 復旧に何分かかるか
- 復旧後にアプリが正常動作するか
特に 所要時間 は軽く見ない方がいいです。
RTO を1時間で考えていたのに、実際はダウンロードや展開で3時間かかる、は普通に起こります。
戻せないを防ぐ確認手順
小規模サービスや社内システムでも、次の順番にするとかなり整理しやすいです。
-
バックアップ対象を一覧化する
データベース、アップロード、設定ファイル、証明書、ジョブ設定、シークレットのどこまでが必要かを整理します。 -
復旧先を決める
いきなり本番へ流し込まず、別名データベース、検証環境、別ディレクトリなど安全な確認先を用意します。 -
実際に展開・インポートする
ファイルがあるはずではなく、展開できるか、インポートできるかを実際に試します。 -
中身を確認する
件数、最新時点、画像や添付ファイル、文字化け、主要テーブルを見ます。 -
アプリ動作まで確認する
ログイン、主要画面、フォーム送信、メール送信、権限エラーの有無まで見ると実務でかなり強いです。 -
所要時間を記録する
ダウンロード、展開、データベース復元、キャッシュクリア、動作確認まで何分かかるかを残します。 -
手順書を更新する
実際に詰まった点をそのままメモし、次回は迷わず戻せる形にします。
この確認を月1回までする必要があるとは限りませんが、少なくとも重要システムは四半期に1回くらいでも回しておくと安心感がかなり違います。
実務で多いルールの例
ざっくりした叩き台なら、次のような形はかなり現実的です。
- 日次 7 世代、週次 4 世代、月次 12 世代
- 本番と別の保管先を持つ
- ファイルとデータベースを分けてバックアップする
- 重要環境はスナップショットも持つ
- 四半期に1回は復旧確認をする
- 復旧手順をメモではなく運用手順として残す
もちろん、これは万能ではありません。
でも 最新だけ1つ よりはかなり安全で、何十世代もあるけど戻したことがない よりも実務的です。
よくある失敗
世代数だけ決めて満足し、どこまで戻るか、何分かかるか、誰が復旧するかを決めていないケースはかなり多いです。バックアップ設計は「保存」と「復旧」を分けずに考えた方が安全です。
特に多いのはこのあたりです。
- 同じサーバーにしか置いていない
- バックアップはあるが復旧手順がない
- 本番へいきなり上書きして二次被害を出す
- データベースとファイルの時点がずれている
- 所要時間を測っていない
バックアップに関するよくある質問
Q. バックアップの世代数はいくつ持つべきですか？
A. 用途次第ですが、日次7世代 + 週次4世代 + 月次12世代の 7-4-12 体制が一般的です。短時間で気づくミスは直近で、ランサムウェアは月次まで遡れる構成が安心です。
Q. クラウドサービスのスナップショットだけで十分ですか？
A. 同一アカウント内のスナップショットだけでは不安が残ります。アカウント侵害や設定ミスでまとめて消える可能性があるため、別アカウント、別リージョン、または外部ストレージへの転送と組み合わせるのが安全です。
Q. オフラインバックアップは必要ですか？
A. ランサムウェア対策としては必要です。Object Lock(WORM)、テープ、物理的に切り離すストレージなど、攻撃者から書き換えできない場所 を1つ持つのが推奨されます。
Q. 復旧テストはどれくらいの頻度でやるべきですか？
A. 重要システムは四半期ごと、軽微なシステムでも年1回が目安です。テストしないバックアップは 存在するだけ で、いざ復旧時に詰まる原因になります。
Q. データベースとファイルの整合性はどう取りますか？
A. DB は pg_dump や mysqldump、または PITR を使ったスナップショット時刻、ファイルは LVM スナップショットや同時刻の rsync で揃えるのが基本です。トランザクション系では特に時刻合わせが重要です。
Q. RPO と RTO は何ですか？
A. RPO は どこまで戻して良いか(許容データ損失)、RTO は どれくらいで復旧すべきか(許容停止時間) です。設計を始めるときに、業務側と数値で合意することが大事です。
Q. 個人開発のサービスでも本格的なバックアップは必要ですか？
A. データを失ったらサービスが終わるなら必要です。最低限、DB の日次ダンプ + 別ストレージ転送 + 月1の復旧テストができていれば、個人開発でも十分な水準です。
まとめ
バックアップの価値は、保存枚数そのものより 本当に戻せるか にあります。
世代数の設計は大事ですが、データベース、ファイル、設定、権限、所要時間を一度も確認していないなら、事故時に初めて詰まりやすいです。
実務では、バックアップ対象を決める 別環境で戻す アプリ動作まで確認する 所要時間を残す の4つを回すだけでもかなり違います。
バックアップは、取った瞬間ではなく、戻せると確認できた瞬間に初めて安心材料になります。
参考情報
- 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