先に要点
バックアップは取っているのに、いざというとき戻せない という状態はかなり多いです。
実際、事故が起きてから初めて復元を試し、そこで ファイルが足りない パスワードが分からない データベースが入らない 思った時点まで戻らない と気づくケースは珍しくありません。
このテーマは、単に世代数を決めれば終わる話ではありません。
大事なのは、どこまで戻れれば業務が成立するか、止まってよい時間はどのくらいか、そして本当に復元できるかを先に確認しておくことです。
このページでは、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 でも復元テストが用意されていて、復元可能性や所要時間を定期的に確認できるようになっています。
つまり、クラウドでも 取っているだけでは足りない という前提です。
バックアップで本当に大事なのは、次を知っていることです。
可否
戻せるか
時間
どれくらい時間がかかるか
範囲
どこまで戻るか
担当
誰が判断して実行するか
事業者側の管理系が侵害されたときに、バックアップはどこにあるか
ここまでは「自分の環境が壊れたとき」の話でした。もう一段広げると、利用しているクラウド事業者の管理系そのものが侵害される場合があります。2026年10月27日、IDCフロンティアは「IDCFクラウド」の不正アクセスについて調査結果（第7報）を発表しました（2026年10月31日に確認）。この件を例に、発表されている事実と、そこから言える一般論を分けて整理します。
発表されている事実
| 項目 | 発表の内容 |
|---|---|
| 原因 | 顧客向けポータルの認証システムで使われていた OSS の脆弱性が悪用された（OSS 名や CVE 番号は発表に記載なし） |
| 経緯 | 認証システムに侵入し、管理コンソール経由で仮想化基盤の管理者権限を取得。仮想サーバーを停止し、仮想サーバー自体を暗号化 |
| 発生 | 2026年10月7日 3時40分頃に障害を検知 |
| 範囲 | 東日本リージョン1の一部の4ゾーン。仮想サーバー利用の影響は495の企業・自治体 |
| データ | 仮想サーバー内のデータの外部流出はなかったと判断（現時点で痕跡なし） |
| バックアップ | スナップショット機能の利用者のうち、取り出せるのは10月14日に194社、10月20日に206社。取り出しと引き渡しは10月17日から |
| 復旧 | ポータルは停止中で、段階的に再開する予定（時期は未公表） |
侵入の時期、OSS の具体名、ポータルの再開時期は、発表では示されていません。上の表は発表の記載に限っています。
事業者を問わず言えること（筆者の考え）
特定の事業者の良し悪しではなく、どのクラウドでも起こり得る型として受け止めるのが実務的です。以下は発表を踏まえた筆者の考えで、発表の内容そのものではありません。
置き場所を分ける
バックアップを、元のサーバーと同じ事業者・同じ管理画面の下だけに置かない。管理系が奪われると、本番とバックアップが同じ操作で止まったり消えたりし得ます。
別のコピーを一つ持つ
別のアカウント、別の事業者、またはオフラインのコピーを一つ持つ。書き換えと削除を一定期間禁じるオブジェクトロックのような仕組みがあれば併用します。
管理者の認証を強くする
多要素認証と接続元の制限は、事業者側だけでなく自社の管理アカウントにも当てはまります。
復元の訓練をする
別の場所から取り出し、別の環境で起動できるかを、事故の前に一度は試します。取り出せることと、動く状態に戻せることは別です。
なお、全体の考え方は ランサムウェアとは？手口・対応策・実際に起きた事件 の「バックアップは『あるか』より『戻せるか』」もあわせて読むとつながります。
出典：IDCフロンティア「【第7報】不正アクセスに関する調査結果および今後の対応について」（https://www.idcf.jp/news/topics/20261027001）
実際の復旧方法はどう考えるか
復旧は、保存方法ごとに考えた方が混乱しにくいです。
ファイルを戻す場合
たとえば /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/
ここで大事なのは、全部戻す ではなく 必要な範囲だけ戻す ことです。アプリ全体を古い状態へ巻き戻すと、別の差分まで消すことがあります。
スナップショットから戻す場合
サーバーやディスクの スナップショット は、環境をまとめて戻しやすいのが利点です。
ただし、本番中のディスクをそのまま即上書きで戻すのはかなり慎重にやるべきです。
実務では、まずこう考えることが多いです。
- 1
別ディスクや別VMを起こす
スナップショットから別ディスクや別VMを起こす。
- 2
中身を確認する
起こした環境で中身を確認する。
- 3
必要ならデータだけ取り出す
必要なデータだけを取り出す。
- 4
戻し方を判断する
本番へ戻すか、新環境へ切り替えるか判断する。
この流れの方が、誤って正常なデータまで消しにくいです。
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だけ でも足りないことがあります。
少なくとも次を一緒に見た方が安全です。
復旧後に php artisan config:clear や php artisan cache:clear が必要なこともあります。
戻したあとにアプリが起動するか、ログインできるか、フォーム送信が通るかまで確認した方が実務向きです。
復旧確認はどうやるべきか
復旧確認は、本番事故のときに初めてやるものではありません。
少なくとも、定期的にこういう確認をしておくと安心です。
- バックアップファイルが取得できているか
- 展開やインポートが実行できるか
- 欲しい時点のデータが戻るか
- 復旧に何分かかるか
- 復旧後にアプリが正常動作するか
特に 所要時間 は軽く見ない方がいいです。RTO を1時間で考えていたのに、実際はダウンロードや展開で3時間かかる、は普通に起こります。
戻せないを防ぐ確認手順
小規模サービスや社内システムでも、次の順番にするとかなり整理しやすいです。
戻せないを防ぐ確認手順
- 1バックアップ対象を一覧化する
データベース、アップロード、設定ファイル、証明書、ジョブ設定、シークレットのどこまでが必要かを整理します。
- 2復旧先を決める
いきなり本番へ流し込まず、別名データベース、検証環境、別ディレクトリなど安全な確認先を用意します。
- 3実際に展開・インポートする
「ファイルがあるはず」ではなく、展開できるか、インポートできるかを実際に試します。
- 4中身を確認する
件数、最新時点、画像や添付ファイル、文字化け、主要テーブルを見ます。
- 5アプリ動作まで確認する
ログイン、主要画面、フォーム送信、メール送信、権限エラーの有無まで見ると実務でかなり強いです。
- 6所要時間を記録する
ダウンロード、展開、データベース復元、キャッシュクリア、動作確認まで何分かかるかを残します。
- 7手順書を更新する
実際に詰まった点をそのままメモし、次回は迷わず戻せる形にします。
この確認を月1回までする必要があるとは限りませんが、少なくとも重要システムは四半期に1回くらいでも回しておくと安心感がかなり違います。
実務で多いルールの例
ざっくりした叩き台なら、次のような形はかなり現実的です。
- 日次 7 世代、週次 4 世代、月次 12 世代
- 本番と別の保管先を持つ
- ファイルとデータベースを分けてバックアップする
- 重要環境はスナップショットも持つ
- 四半期に1回は復旧確認をする
- 復旧手順をメモではなく運用手順として残す
もちろん、これは万能ではありません。でも 最新だけ1つ よりはかなり安全で、何十世代もあるけど戻したことがない よりも実務的です。
よくある失敗
世代数だけ決めて満足し、どこまで戻るか、何分かかるか、誰が復旧するかを決めていないケースはかなり多いです。バックアップ設計は「保存」と「復旧」を分けずに考えた方が安全です。
特に多いのはこのあたりです。
- 同じサーバーにしか置いていない
- バックアップはあるが復旧手順がない
- 本番へいきなり上書きして二次被害を出す
- データベースとファイルの時点がずれている
- 所要時間を測っていない
バックアップに関するよくある質問
Q. バックアップの世代数はいくつ持つべきですか？
A. 用途次第で正解はありませんが、日次・週次・月次に分けて残す考え方(GFS 方式と呼ばれます)がよく叩き台になります。この記事の例では、日次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 の日次ダンプ、別ストレージへの転送、定期的な復旧テストの3つがそろっていれば、個人開発として現実的な水準です。
まとめ
バックアップの価値は、保存枚数そのものより 本当に戻せるか にあります。
世代数の設計は大事ですが、データベース、ファイル、設定、権限、所要時間を一度も確認していないなら、事故時に初めて詰まりやすいです。
実務では、バックアップ対象を決める 別環境で戻す アプリ動作まで確認する 所要時間を残す の4つを回すだけでもかなり違います。
バックアップは、取った瞬間ではなく、戻せると確認できた瞬間に初めて安心材料になります。
復元の自動確認が「失敗」と出たときは、ダンプではなく確認の作りを疑う場合があります。Docker の公式 PostgreSQL イメージでの例を、初期化中の pg_isready と復元の失敗にまとめています。
参考情報
- 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