※小説ではない※専門書 要約資料集 為替(換算)3.9万円でもらう 紐解集生成 専門 初入門 資料 作：｛作者名｝
※物語はフィクションです ※
※即時通報案件は専門家にご通報ください※
※お手数ですが疑問点は各分野でご確認いただけましたら幸いです※
# BOOK-0365 情報防衛と復旧シリーズ 第6巻: バックアップと災害復旧 — 止めないためではなく、止まった後に必ず戻ってこられるようにするための一冊
> 情報防衛と復旧シリーズ(全12巻・BOOK-0360〜0371・設計書=CATALOG_情報防衛と復旧シリーズ.md)第6巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務のうち、本巻が担うのは**構成し直し**の段階——判定によって何が壊れたかが確定した後、実際にどう作り直せば「戻ってこられる」のかを、RPO/RTOという設計の言葉と、3-2-1ルール・物理分離・復元検証という具体の技術で支える一冊である。
> **安全枠(§16.18・本巻での適用範囲・最重要)**: 本巻は防御・復旧・教育に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。ランサムウェアという言葉には触れるが、その展開手順・感染拡大の技術には一切立ち入らず、「バックアップという資産をどう守るか」という防御側の設計判断だけを扱う(IMPORTANT: authorized security testing/defensive securityの枠内)。**誇張禁止(§16.5)**: 「この方式さえ使えば絶対にデータは失われない」等は書かない。多層の備えは被害の確率と大きさを下げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0360『情報セキュリティ総論』(全巻の土台。CIA三要素のうち可用性を、本巻は主に扱う)、→BOOK-0363『インシデント対応の一本道』(前々巻。本巻は同書第十章が予告にとどめた「復旧」段階と、第四章の一日再構成プレイブックのうち6〜18時間の「復旧」枠を、詳しく掘り下げる)、→BOOK-0364『フォレンジクスとログ解析』(前巻。本巻は同書が扱う「判定」の後を受け取る)、→BOOK-0366『可用性・信頼性工学(SRE)』(次巻。冗長化・段階的縮退という「止まらない」ための設計は、そちらが専門に扱う)、→BOOK-0371『セキュアな再構成の実務』(バイト同一移植の詳しい手順と境界の作り直し方は、そちらが最終的に引き継ぐ)。
> 水準: 一〜十二(バックアップとは何か・なぜ必要かという土台から、3-2-1ルール、フル・差分・増分という方式の違い、RPO/RTOという設計の物差し、物理分離システムの意味、補助技術の定量効果、バイト同一移植と機械突合による復元検証、復元テストの重要性、DRPとBCPの違い、クラウド時代の災害復旧、イミュータブルバックアップとエアギャップの復権、そして「一日で全システムを再構成せよ」と言われたときの完全な段階表までを扱う。初心者→熟練者→上級専門家→講師級の四段は、おおむね第一〜三章/第四〜七章/第八〜十章/第十一〜十二章に対応する)。
---
# BOOK-0365 情報防衛と復旧シリーズ 第6巻: バックアップと災害復旧 — 止めないためではなく、止まった後に必ず戻ってこられるようにするための一冊
> 情報防衛と復旧シリーズ(全12巻・BOOK-0360〜0371・設計書=CATALOG_情報防衛と復旧シリーズ.md)第6巻。ガイド役: Fable 5 監修 / Sonnet 5 執筆(脚本班)
> トーン規約: GAKUMON_UNIVERSE.md準拠。専門用語は初出で必ず説明する。
> **値札**: 「一日停止・全システム再構成の段階判断」という特命業務のうち、本巻が担うのは**構成し直し**の段階——判定によって何が壊れたかが確定した後、実際にどう作り直せば「戻ってこられる」のかを、RPO/RTOという設計の言葉と、3-2-1ルール・物理分離・復元検証という具体の技術で支える一冊である。
> **安全枠(§16.18・本巻での適用範囲・最重要)**: 本巻は防御・復旧・教育に限定する。実在システムへの侵入手順・動作するエクスプロイト・攻撃の再現コード・検知回避手法は一切書かない。ランサムウェアという言葉には触れるが、その展開手順・感染拡大の技術には一切立ち入らず、「バックアップという資産をどう守るか」という防御側の設計判断だけを扱う(IMPORTANT: authorized security testing/defensive securityの枠内)。**誇張禁止(§16.5)**: 「この方式さえ使えば絶対にデータは失われない」等は書かない。多層の備えは被害の確率と大きさを下げるが、ゼロにはしない、という正直な水準で書く。
> 接続先: →BOOK-0360『情報セキュリティ総論』(全巻の土台。CIA三要素のうち可用性を、本巻は主に扱う)、→BOOK-0363『インシデント対応の一本道』(前々巻。本巻は同書第十章が予告にとどめた「復旧」段階と、第四章の一日再構成プレイブックのうち6〜18時間の「復旧」枠を、詳しく掘り下げる)、→BOOK-0364『フォレンジクスとログ解析』(前巻。本巻は同書が扱う「判定」の後を受け取る)、→BOOK-0366『可用性・信頼性工学(SRE)』(次巻。冗長化・段階的縮退という「止まらない」ための設計は、そちらが専門に扱う)、→BOOK-0371『セキュアな再構成の実務』(バイト同一移植の詳しい手順と境界の作り直し方は、そちらが最終的に引き継ぐ)。
> 水準: 一〜十二(バックアップとは何か・なぜ必要かという土台から、3-2-1ルール、フル・差分・増分という方式の違い、RPO/RTOという設計の物差し、物理分離システムの意味、補助技術の定量効果、バイト同一移植と機械突合による復元検証、復元テストの重要性、DRPとBCPの違い、クラウド時代の災害復旧、イミュータブルバックアップとエアギャップの復権、そして「一日で全システムを再構成せよ」と言われたときの完全な段階表までを扱う。初心者→熟練者→上級専門家→講師級の四段は、おおむね第一〜三章/第四〜七章/第八〜十章/第十一〜十二章に対応する)。
---
## 入口の物語 — 判定は終わった。次は、戻ってこられるかどうかという勝負
前巻(BOOK-0364)でたどった、深夜3時に止まった在庫管理システムの一件を、もう一度思い出してほしい。当直担当者の焦った再起動のあと、朝になって在庫データの数字がおかしいことに気づき、「今日一日、全システムを止めてでも原因を突き止めて直せ」という指示が下った。あの物語は、証拠を保全し、ログを読み、タイムラインを再構成し、記録の帳尻から改竄を検知するという「判定」の技術で、ひとまず終着点にたどり着いた。何が、いつ、どう壊れたのかは、もう憶測ではない。証拠と検算で語れる状態になった。
だが、判定が終わっただけでは、在庫管理システムはまだ止まったままである。原因がわかったところで、データそのものが元に戻るわけではない。ここから先に待っているのは、判定とはまったく別の種類の勝負である——「本当に、戻ってこられるかどうか」。
戻る場所がなければ、どれだけ丁寧に原因を調べても、担当者は途方に暮れることになる。逆に、戻る場所さえ確かに用意されていれば、たとえ原因の全容が完全にはわからなくても、「少なくとも、この時点までは確実に戻せる」という足場を手に入れられる。この「戻る場所」こそが、本巻が最初から最後まで扱う**バックアップ**であり、その戻る場所をどう設計し、どう検証し、どう使うかという一連の技術体系が**災害復旧**である。
前巻の第二章には、忘れてはならない一文があった——「定期バックアップがあるから、いざとなればそこから復元できる」という安心感は、判定の観点からは危うい、という指摘である。バックアップそのものが「いつのハッシュ値と一致する状態のバックアップなのか」が記録されていなければ、そのバックアップが改竄前の状態なのか改竄後の状態なのかを、後から証明することができない——これは事実であり、本巻でもこの前提を引き継ぐ。証拠としての保全(前巻の仕事)と、業務を再開するための復元(本巻の仕事)は、目的が異なるために設計も異なる。本巻は、この「戻るための備え」そのものを、土台から実務の最先端まで、一本の道として歩いていく。
---
## 第一章: バックアップとは何か、なぜ必要か(水準一)
### データが失われる理由は、一つではない
まず、いちばん基本の言葉を確認しておこう。**バックアップ(backup、水準一: 元のデータが失われた・壊れた場合に備えて、同じ内容の複製をあらかじめ別の場所に作成しておくこと)**とは、この定義がそのまま示すとおり、単純な考え方である。だが「なぜ必要か」を本当に理解するには、データが失われる理由が、一つではないという事実を、まず正直に見つめる必要がある。
```
ハードウェア故障 : ディスクや記憶装置そのものが物理的に壊れる
人為的操作ミス : 誤って削除する、誤って上書きする
ソフトウェアの欠陥 : プログラムの不具合がデータを壊す
自然災害・事故 : 火災・水害・停電・地震などで設備そのものが失われる
意図的な攻撃 : 前巻・前々巻で扱った、外部・内部からの意図的な破壊や暗号化
```
情報セキュリティの実務でよく引かれる調査(業界団体や記憶装置メーカーが継続的に行っている損失原因の集計)では、これら5つの原因のうち、単一の原因だけがデータ損失の大半を占めるわけではなく、複数の原因が入り混じって発生し続けている、と繰り返し報告されている。この事実が示す教訓は明快である——「攻撃さえ防げればデータは安全だ」という考え方は誤りであり、バックアップという備えは、意図的な攻撃だけでなく、ありふれた操作ミスや、ただの部品の寿命にも等しく効く、汎用性の高い防御策だという点である。
### 可用性という物差しに立ち戻る
→BOOK-0360で扱われるCIA三要素のうち、バックアップが直接に支えるのは**可用性(かようせい、Availability、水準一: 使いたいときに使えること)**である。機密性(見られないこと)や完全性(書き換えられていないこと)を守る技術は、暗号や認証やアクセス制御が主に担うが、「壊れた後、使える状態に戻す」という仕事は、バックアップと災害復旧という、本巻の領域が専門に担う。
### 点検1 — バックアップと「単なるコピー」は何が違うか
ある担当者が、大事なファイルをデスクトップの別のフォルダにコピーしただけで、「バックアップは万全だ」と考えていたとする。この考え方の弱点はどこにあるだろうか。同じディスク・同じ機器の中にコピーを置いているだけでは、そのディスクが物理的に壊れた瞬間に、元のファイルとコピーの両方が同時に失われる。バックアップという言葉が本当に意味するのは、単に複製が存在することではなく、**元のデータと運命を共にしない場所に**複製が存在することである(点検成立)。この「運命を共にしない」という条件を、どう具体的に満たすかが、次章で扱う3-2-1ルールの中心的な主張になる。
### 実例 — このプロジェクト自身にある「戻る場所」という発想
この「戻る場所」という発想は、本プロジェクトの開発文化そのものにも、形を変えて組み込まれている。総関数辞書には、ゲーム状態全体を後から復元可能な形で保存する**FUNC-0996(巻き戻し/rollback・revert)**という機能素が登録されており、その組合せと罠の欄には次のような一節がある——「復元番兵のようなバックアップからの緊急復旧運用は、本カードの手動・緊急版に相当する」。ここでいう「復元番兵」とは、本プロジェクトがフォルダの消失や巻き戻り事故に一括対応するために備えている運用の名であり、まさに「壊れた・消えたときに、戻る場所へ手動で復元する」という、本巻が扱う災害復旧そのものの縮図である。ソフトウェアの世界での「巻き戻し」と、実務の世界での「バックアップからの復元」は、根っこの発想を共有している。
### よくある誤解 — 「クラウドに置いてあるから、もうバックアップは要らない」
クラウドサービスにファイルを置いておけば、それだけでバックアップとして十分だと考えてしまう担当者は少なくない。しかしこれは正確ではない。多くのクラウドサービスは、同期(sync、手元の変更を即座にクラウド側へも反映する仕組み)を主な機能として提供しており、これは「常に最新の状態を映す鏡」であって、「過去のある時点へ戻れる保険」とは性格が異なる。誤って上書き保存したファイルは、同期の仕組みによって、クラウド側の内容も同じように上書きされてしまうことがある。クラウドサービスが真にバックアップとして機能するのは、過去の複数時点へ戻れる版管理機能を備え、かつ意図的に有効化されている場合に限られる——この誇張のない線引きを、本章の締めくくりとして明確にしておく。
---
> **定着量の目安(第一章)**: データが失われる5つの原因(ハードウェア故障・人為的操作ミス・ソフトウェアの欠陥・自然災害・意図的な攻撃)を、何も見ずに書き出せるようにしておく。あわせて、自分が「バックアップだと思っているもの」が、本当に元のデータと運命を共にしない場所にあるかどうかを、1つ点検してみるとよい。
---
## 第二章: 3-2-1ルール — いくつ、どこに、どう置くか(水準二)
### 3・2・1という3つの数字
バックアップを「なんとなく」ではなく、具体的にどう設計すればよいかを示す、もっとも広く知られた指針が**3-2-1ルール(さんにいちルール、水準二: 少なくとも3つのコピーを持ち、2種類以上の異なる媒体に保存し、そのうち1つは遠隔地に置く、という基本原則)**である。
```
3 : 少なくとも3つのコピーを持つ(元のデータ+バックアップ2つ以上)
2 : 2種類以上の異なる媒体に保存する(例: 内蔵ディスク+外付けディスク+クラウド)
1 : そのうち少なくとも1つは、元のデータとは別の場所(遠隔地)に置く
```
このルールの起源は、アメリカの写真家ピーター・クロッグ(Peter Krogh)が2005年に発表した著書『The DAM Book』の中で、写真家自身の大切な作品データを守るための実践知として整理したことにあるとされ、その後、企業のIT実務にも広く転用されるようになったと一般に紹介されている。現在では、米国のCISA(サイバーセキュリティ・インフラセキュリティ庁)のような公的機関も、基本的な備えとしてこの3-2-1ルールを推奨資料の中で紹介しており、写真家個人の知恵から出発した考え方が、組織のシステム全体を守る基本原則にまで育った、という経緯そのものが興味深い。
### なぜ「2種類の媒体」が要るのか
3つのコピーがあっても、そのすべてが同じ種類の媒体(たとえば同じメーカーの同じ型番のディスクを3台)であれば、その媒体そのものに共通する欠陥や、同じ環境要因(たとえば同じ部屋の停電や水害)によって、3つとも同時に失われる危険がある。媒体の種類を変える(内蔵ディスク・外付けディスク・磁気テープ・クラウドストレージなど)ことで、「1種類の媒体すべてに共通する弱点」から複数のコピーを守ることができる。
### なぜ「1つは遠隔地」が要るのか
同じ建物の中に3つのコピーをどれだけ分散させても、その建物そのものが火災や水害、地震といった物理的な災害に見舞われれば、すべてのコピーが同時に失われる可能性がある。遠隔地(オフサイト、off-site、水準二: 元のデータがある場所とは物理的に離れた、別の拠点や地域)にコピーを1つ置くことで、この「建物単位の全滅」という最悪のシナリオからも身を守ることができる。
### 点検2 — 次のバックアップ運用は、3-2-1ルールを満たしているか
ある小さな事務所が、次のようなバックアップ運用を行っていたとする。「業務用パソコンの中に元データがあり、同じパソコンの別のフォルダにコピーを1つ作り、さらに机の上に置いた外付けディスクにもコピーを1つ作っている」。この運用は3-2-1ルールを満たしているだろうか。コピーの数は3つ(元データ+2コピー)で足りているように見えるが、外付けディスクも業務用パソコンも同じ建物の同じ机の上にあり、遠隔地のコピーが存在しない。媒体の種類も、パソコン内蔵ディスクと外付けディスクという2種類は満たしているものの、「1つは遠隔地」という条件が欠けているため、3-2-1ルールは満たされていない(点検成立)。この事務所が本当に守られるには、クラウドストレージや、別の建物にある拠点への複製など、遠隔地のコピーをもう1つ加える必要がある。
### 実例 — このプロジェクト自身が実践する、3-2-1に近い運用
この3-2-1ルールという考え方は、机上の理論にとどまらない。本プロジェクト自身の運用記録にも、これに近い実践が残っている。プロジェクトの規約書(`CLAUDE.md`)には、「波の締めごと(検定合格の記録後)に `cp -r gakumon docs library SYSTEM.md CLAUDE.md HANDOFF.md *.html tools _vault/snapshot_<日時>/` を実行する」という具体的な退避運用が明記されている。さらに進捗台帳である`gakumon/NUMBER_REGISTRY.md`には、大きな作業の節目ごとに「退避=波締め時_vault」「安全紐: 3班・アンカー=着荷順に司令塔検品・退避=_vault(波締め時)」という記述が、追記専用の記録として繰り返し残されている。これは、作業中の成果物(元データ)とは別に、日時つきのフォルダへ複製を追加していくという運用であり、「元のデータとは別の場所に、時点を追って複数のコピーを持つ」という3-2-1ルールの精神——特に「3」(複数のコピー)と「1」(元データとは別の置き場)——に近い考え方を、このプロジェクト自身が日々実践している一次資料だと言える。ただし、この退避先(`_vault`)が同一の作業フォルダ配下にある点は、次章以降で扱う「本当の意味での物理分離」とは水準が異なる、という限界も正直に記しておく必要がある。
### コラム — 「3-2-1」は絶対の数字ではない
3・2・1という数字そのものは、絶対に守らなければならない数式ではなく、「複数・複数種類・離れた場所」という3つの独立した考え方を、覚えやすい形にまとめた語呂合わせに近い。データの重要度が極めて高い組織では、コピーの数をさらに増やしたり、遠隔地を2箇所以上に分散させたりする拡張形も広く採用されている。この拡張の考え方は、第十一章で扱う「3-2-1-1-0」という、より新しい変種にもつながっていく。
---
> **定着量の目安(第二章)**: 自分の大切なデータ(写真・書類など)について、現在のコピーの数・媒体の種類・保存場所を書き出し、3-2-1ルールのどこが満たされていてどこが欠けているかを点検してみる。第三章に進む前に、「なぜ2種類の媒体が要るのか」「なぜ1つは遠隔地が要るのか」を自分の言葉で説明できるようにしておくと理解が定着しやすい。
---
## 第三章: フル・差分・増分 — 方式の違いと復元時間のトレードオフ(水準三)
### 3つの方式
バックアップを「毎回どこまで複製するか」という観点で見ると、代表的な方式は3つに分けられる。**フルバックアップ(full backup、水準三: 対象のデータをまるごと複製すること)**がもっとも基本の形であり、**差分バックアップ(さぶんバックアップ、differential backup、水準三: 直前のフルバックアップ以降に変更された部分をまとめて複製すること)**、そして**増分バックアップ(ぞうぶんバックアップ、incremental backup、水準三: 直前のバックアップ〈フルバックアップまたは増分バックアップ〉以降に変更された部分だけを複製すること)**という2つの派生形がある。
```
フルバックアップ : 対象のデータをまるごと複製する
差分バックアップ : 直前のフルバックアップ以降の変更分をまとめて複製する
増分バックアップ : 直前のバックアップ以降の変更分だけを複製する
```
### 表で比べる — 書き込む量と、復元に必要な手順
```
方式 | 毎回の書き込み量 | 復元に必要な手順
-----------------|---------------------------|----------------------------------
フルバックアップ | 常に全量 | 直近のフル1つを読むだけ
差分バックアップ | 直前のフル以降の変更分 | フル1つ+最新の差分1つ
| (日が経つほど増えていく) | (常に2つだけで済む)
増分バックアップ | 直前のバックアップ以降の | フル1つ+それ以降の増分を
| 変更分のみ(最小) | すべて順番に適用する必要がある
```
この表からすぐに読み取れる大きなトレードオフがある。増分バックアップは毎回の書き込み量がもっとも少なく済む(=バックアップにかかる時間と容量がもっとも節約できる)一方で、復元するときには、フルバックアップ1つに加えて、それ以降のすべての増分を、順番を間違えずに適用しなければならない。差分バックアップは、増分よりも毎回の書き込み量は多くなるものの、復元のときはフル1つと最新の差分1つだけで済むという、復元の単純さで優れている。
### 点検3 — 増分方式の「連鎖」が抱える弱点
月曜日にフルバックアップを取り、火曜日から金曜日まで毎日増分バックアップを取っていたとする。もし水曜日の増分バックアップのファイルだけが何らかの理由で壊れて読めなくなっていた場合、木曜日・金曜日のデータは正しく復元できるだろうか。増分バックアップは「直前のバックアップ以降の変更分」を記録する方式であるため、木曜日の増分は水曜日の状態を前提にしており、水曜日の増分が失われると、その後の連鎖全体が繋がらなくなる。したがって、木曜日・金曜日の増分だけを取り出しても、正しい状態には復元できない(点検成立)。これは増分方式の構造的な弱点であり、増分バックアップを運用する組織は、連鎖のどこか1つが壊れただけで全体が復元できなくなるリスクを踏まえたうえで、後述する復元テスト(第八章)を欠かせない、という結論につながる。
### 実例 — 総関数辞書に見る「差分だけを扱う」という設計思想
差分・増分という考え方は、バックアップの世界だけのものではない。本プロジェクトの総関数辞書には、**FUNC-0969(差分再生成/incremental・diff regeneration)**という機能素が登録されている。その定義は「変更されたカードだけを再処理し、変更のない部分の生成物はそのまま使い回すことで全体再生成のコストを避ける」というものであり、まさに増分バックアップと同じ発想——「全部をやり直さず、変わった分だけを扱う」——をソフトウェアの生成処理に適用した実例である。この機能素の不変条件には、次のように記されている——「差分再生成の結果は、全カードからのフル再生成の結果と完全に一致する(効率化が正しさを損なわない)」。この一文は、本章のトレードオフに、もう一つの重要な視点を付け加える。増分・差分という効率化の手法は、「フルでやり直した場合とまったく同じ結果になる」ことが保証されて初めて安全に使える、という条件である。次章以降で扱う復元検証(第七章)は、まさにこの一致を機械的に確かめるための技術である。
---
> **定着量の目安(第三章)**: フル・差分・増分の3方式を、「毎回の書き込み量」と「復元に必要な手順」の2つの軸で、自分の言葉で説明できるようにしておく。特に、増分方式が抱える「連鎖のどこか1つが壊れると全体が復元できない」という弱点を、具体例(曜日ごとのバックアップ)で説明できるようにしておくと、後の章の理解が助けられる。
---
## 第四章: RPOとRTO — 「どこまで戻すか」と「どれだけ止められるか」(水準四)
### 2つの物差し
バックアップの設計を、感覚ではなく数値で語るための、もっとも基本的な2つの物差しがある。
**RPO(目標復旧時点、Recovery Point Objective、水準四: 障害が起きたとき、どの時点の状態までデータを復旧できればよいかを示す目標であり、言い換えれば「どれだけのデータ損失まで許容できるか」を時間の長さで表したもの)**と、**RTO(目標復旧時間、Recovery Time Objective、水準四: 障害が発生してからシステムが復旧し業務を再開できるまでに許容される最大の時間)**である。
この2つは、しばしば混同されるが、まったく別の問いに答えている。RPOは「巻き戻ってよい過去の長さ」を問い、RTOは「止まっていてよい時間の長さ」を問う。
### 図で確かめる
```
障害発生
│
───┼───────────┼──────────┼──────▶ 時間
直近の 復旧が
バックアップ 完了する時点
│◀── RPO ──▶│
│◀───── RTO ─────▶│
```
RPOは「障害発生の瞬間」から「さかのぼって、直近の使えるバックアップの時点」までの距離であり、この距離が長いほど、失われるデータの量が多くなる。RTOは「障害が発生してから」「復旧が完了するまで」の距離であり、この距離が長いほど、業務が止まっている時間が長くなる。
### 検算1 — RPOが4時間のとき、最悪どれだけのデータを失うか
ある業務システムが、6時間ごとにバックアップを取得しているとする。もし午前9時にバックアップを取得した直後、午後2時(9時から5時間後)に障害が発生したとすると、直近の使えるバックアップは午前9時の1つしかなく、9時から2時までの5時間分のデータは失われる。この組織が「RPOは4時間まで」という目標を掲げているなら、6時間ごとのバックアップでは目標を満たせない。RPOを4時間以内に収めるには、バックアップの取得間隔そのものを4時間以内に短縮する必要がある——RPOという物差しは、単なる目標値ではなく、「バックアップをどれだけの頻度で取るべきか」という設計判断に直結する数値である、という点検がここから成り立つ。
### 点検4 — RPOとRTOのどちらが厳しい要求か
ある小さなオンラインショップと、ある大規模な証券取引システムを比べてみよう。オンラインショップは「注文データが数時間分失われても、後で顧客に確認すれば復旧できる」と考え、比較的緩いRPO・RTOで運用している。一方、証券取引システムは「1件の取引データも失うことが許されず、システムが数秒止まっただけでも巨額の損害につながりかねない」と考え、極めて厳しいRPO・RTOを掲げている。この違いは何によって決まるだろうか。RPO・RTOの厳しさは、システムの規模だけでなく、**そのデータや停止が持つ業務上の価値の大きさ**によって決まる(点検成立)。すべてのシステムに同じ厳しさのRPO・RTOを一律に課すことは、コストの観点から現実的でないことも多く、システムごとに「どこまで守るべきか」を見極めて設計することが、本章の実務上の核心である。
### 実例 — チェックポイントという、身近な形のRPO
RPOという考え方は、実は本プロジェクトのごく身近な機能素にもすでに現れている。**FUNC-0436(保存時点のアンドゥチェックポイント設定/mark undo checkpoint at save)**は、ファイル保存を行った時点のアンドゥスタック上の位置に印(チェックポイント)を付け、以後「保存時点まで戻った」かどうかを判定に使えるようにする機能である。この「保存した時点まで戻れる」という性質は、「その保存の間隔が、失ってよいデータの最大量そのものになる」というRPOの考え方と、根っこの構造が同じである。エディタで最後に保存してから10分間の編集を、保存せずに失ってしまった経験のある読者は、身をもって「RPO=10分」という状況を体験したことになる。
### コラム — RPO・RTOを厳しくするほど、コストは直線的には増えない
RPOを24時間から1時間へ縮めることと、1時間から1分へ縮めることは、同じ「23時間分の短縮」と「59分の短縮」という数字の大小では比べられない、まったく異なる難易度を持つ。RPOを24時間から1時間に縮めるには、バックアップの取得頻度を1日1回から1時間に1回へ変えるだけで足りることが多いが、RPOを1時間から1分に縮めるには、単純な定期バックアップの延長ではもはや対応できず、変更が発生するたびに即座に複製する仕組み(継続的なデータ複製)そのものを新設する必要が出てくる。この「目標を厳しくするほど、必要な技術と費用が段階的に跳ね上がる」という関係は、実務ではしばしば「RPO・RTOを1桁縮めるごとに、コストは1桁では済まない規模で増える」という経験則として語られる。すべてのシステムに、最も厳しいRPO・RTOを一律に適用することが現実的でない理由は、この非直線的なコストの跳ね上がりにある。だからこそ第九章で扱うDRP・BCPの設計では、システムごとの重要度に応じてRPO・RTOの目標値を意図的に使い分けるという判断が、実務上欠かせない一手間になる。
---
> **定着量の目安(第四章)**: RPOとRTOの違いを、「どこまで戻すか(RPO)」と「どれだけ止められるか(RTO)」という一言でそれぞれ説明できるようにしておく。自分にとって身近なシステム(スマートフォンの写真データなど)を1つ選び、「もし今日データが失われたら、何時間分までなら諦められるか(RPO)」「復旧に何時間までなら待てるか(RTO)」を自分の言葉で見積もる練習をすると、この物差しの感覚が実感として定着する。
---
## 第五章: 物理分離システムの意味(水準五)
### なぜ「同じネットワーク上」では足りないことがあるのか
3-2-1ルールが示す「2種類の媒体」「1つは遠隔地」という考え方を、さらに一段深く掘り下げると、「そのバックアップは、元のシステムと同じネットワークから、常に書き換え可能な状態でつながっているのか」という問いにたどり着く。もし答えが「はい」なら、元のシステムに影響を与えるあらゆる異常(誤操作・障害・意図的な破壊)が、バックアップ側にも同じ経路を通じて及ぶ危険がある。この危険を断つための考え方が、物理分離である。
### エアギャップという考え方
**エアギャップ(air gap、水準五: システムやバックアップ媒体を、ネットワークから物理的に切り離し、通常の通信経路を通じてはアクセスできない状態に保つこと)**は、この物理分離のもっとも徹底した形である。ネットワークケーブルを物理的に外す、あるいは無線通信の機能そのものを持たない媒体(外付けディスクやテープなど)にバックアップを取り、使用しないときは通信経路から完全に切り離しておく——この状態では、ネットワークを経由するあらゆる異常が、原理上、そのバックアップに直接は及ばない。
### WORM(書込一度読取専用)という考え方
もう一つの重要な物理分離の形が、**WORM(Write Once Read Many、書込一度読取専用、水準五: 一度書き込んだデータを、その後は変更も削除もできない状態で保持する記録方式)**である。もともとはCD-Rのような、一度焼き込んだら内容を書き換えられない光学メディアで実現されていた性質だが、現在では磁気テープの専用モードや、クラウドストレージが提供する「オブジェクトロック」と呼ばれる機能などを通じて、デジタルデータにも同様の性質を持たせられるようになっている。証券業界などの規制業種で、記録の改竄防止のために法令上WORM相当の保存が求められる場面があることも広く知られている。
### 点検5 — オフライン保管と、常時接続のバックアップの違い
ある組織が、「バックアップは毎晩自動でクラウドストレージへ送信され、常時そこに保管されている」という運用をしていたとする。このバックアップは、エアギャップの考え方を満たしているだろうか。常時接続されたクラウドストレージは、遠隔地(第二章)という条件は満たしているものの、通常の通信経路を通じて日常的にアクセス可能な状態にあるため、エアギャップの条件——通常の通信経路からは切り離されている——は満たしていない(点検成立)。この組織が本当の意味での物理分離を実現するには、定期的にオフライン(通信経路から切り離された状態)の媒体へ複製し、使用が終わったら物理的に接続を切る、という運用を別途加える必要がある。
### よくある誤解 — 「物理的に切り離せば、リスクはゼロになる」
エアギャップという言葉には、「これさえやれば絶対に安全」という響きがつきまとうことがあるが、これは誇張である。物理的に隔離された環境であっても、リムーバブルメディア(USBメモリ等)の持ち込みや、保守作業を行う担当者自身の操作を経由すれば、汚染が及ぶ可能性が完全にはゼロにならないことが、情報セキュリティの実務では繰り返し指摘されている。多層防御(→BOOK-0363第三章)の考え方がそうであったように、エアギャップも「侵入や被害の確率と手間を大きく引き上げる」対策ではあっても、「ゼロにする」対策ではない、という誇張のない水準で理解しておく必要がある。この限界を正しく理解しておくことが、第十一章で扱う「なぜ現代でもなおエアギャップが見直されているのか」という議論の土台になる。
---
> **定着量の目安(第五章)**: エアギャップとWORMの違いを、自分の言葉で説明できるようにしておく(エアギャップ=通信経路そのものを切り離すこと、WORM=書き込み後の変更・削除ができない性質を持たせること)。あわせて、「物理分離すればリスクはゼロになる」という誤解がなぜ誤りなのかを、1つの具体例(リムーバブルメディアの持ち込みなど)で説明できるようにしておくとよい。
---
## 第六章: 補助技術の定量効果 — 増分バックアップは何をどれだけ縮めるのか(水準六)
### 検算で確かめる、という本章の目的
第三章では、増分バックアップが「毎回の書き込み量を最小にする」方式であることを見た。本章では、この効果がどれくらいの大きさなのかを、実際に数字を使って検算し、同時に「増分バックアップが縮めるのは、正確には何の時間なのか」という、誇張なく正確な理解を確立する。
### 前提条件
```
対象データの総量 : 480GB
転送速度(書込・読出とも): 200MB/秒(=0.2GB/秒、バックアップ・復元とも同じ速度と仮定)
日次の変更率 : 毎日、全体の2%が変更される(=480GB×0.02=9.6GB)
運用パターン : 日曜日にフルバックアップ、月曜日から木曜日まで毎日増分バックアップ
```
### 検算2 — フルバックアップ1回の所要時間
```
480GB ÷ 0.2GB/秒 = 2400秒 = 40分(検算成立)
```
### 検算3 — 増分バックアップ1回の所要時間
```
9.6GB ÷ 0.2GB/秒 = 48秒(検算成立)
```
### 検算4 — 1週間の「バックアップ取得」にかかる合計時間を比べる
もし毎日フルバックアップを取っていた場合(5日分)。
```
40分 × 5日 = 200分
```
日曜日にフル、月〜木に増分という、本章の運用パターンの場合。
```
フル1回(40分)+ 増分4回(48秒×4=192秒=3分12秒)
= 40分 + 3分12秒 = 43分12秒
```
削減率を検算する。
```
(200分 − 43.2分) ÷ 200分 = 156.8分 ÷ 200分 = 0.784 = 約78%(検算成立)
```
毎日フルバックアップを取り続ける場合と比べ、増分方式を使うと、1週間の「バックアップを取得する」合計時間は**約78%(およそ8割)短縮**される。これが、増分バックアップという補助技術の、定量的で誇張のない効果である。
### 検算5 — では、「復元」にかかる時間はどうなるか
木曜日時点の状態を復元する場合を考える。増分方式では、フルバックアップ(日曜日分)に加え、月・火・水・木の増分4回を、順番どおりすべて適用しなければならない(第三章・点検3で確認したとおり)。
```
フル(40分)+ 増分4回(3分12秒)= 43分12秒
```
もし仮に、木曜日ぶんだけを独立したフルバックアップとして保存していたとしたら、その復元にかかる時間は、フルバックアップ1回ぶんの時間と同じである。
```
480GB ÷ 0.2GB/秒 = 2400秒 = 40分
```
2つを比べると、増分方式による復元(43分12秒)は、木曜日専用のフルバックアップによる復元(40分)よりも、**わずかに長くなる**(3分12秒の増加)。
### よくある誤解 — 「バックアップが速くなれば、復元も同じだけ速くなる」
検算4と検算5を見比べると、本章の中心的な教訓が、誇張なく浮かび上がる。**変更分だけを書き込むためバックアップの取得時間は大きく短縮されるが、全体を復元する時間まで同じ割合で短縮するとは限らない。** むしろ、増分方式は「複数の増分を順番に適用する」という追加の手順を復元時に必要とするため、場合によっては復元時間がわずかに伸びることさえある。増分バックアップという補助技術がもたらす定量的な恩恵は、あくまで「日々のバックアップ取得にかかる時間と容量の節約」であり、「いざというときの復元の速さ」ではない、という区別を正確に持っておくことが、災害復旧の設計において誇張を避ける最初の一歩になる。
### 点検6 — 差分バックアップなら、この問題は起きるか
同じ条件で、増分ではなく差分バックアップ(直前のフル以降の変更分をまとめて複製する方式)を使っていた場合はどうなるだろうか。差分バックアップは、日を追うごとに1回あたりの書き込み量が増えていく(月曜は1日分、火曜は2日分…という具合に累積するため)代わりに、復元時に必要なのは「フル1つ+最新の差分1つ」だけで済む。したがって、差分方式は増分方式に比べてバックアップ取得の総時間短縮効果はやや小さくなるものの、復元の手順は常に一定(2ファイルの適用)で済み、増分方式のような「連鎖が長くなるほど復元が複雑になる」という弱点を持たない(点検成立)。どちらの方式を選ぶかは、「バックアップの取得にかけられる時間」と「復元の単純さ・確実さ」のどちらを優先するかという、組織ごとの設計判断になる。
---
> **定着量の目安(第六章)**: 本章の検算(検算2〜5)を、電卓を使わずに自分の手で再現できるようにしておく。特に「バックアップ取得時間の短縮率(約78%)」と「復元時間はむしろ増える場合がある」という、一見矛盾するように見える2つの事実を、同時に矛盾なく説明できるようになることが、本章の理解の目安である。
---
## 第七章: バイト同一移植と機械突合による復元検証(水準七)
### 「戻せたつもり」を許さない、という一貫した思想
→BOOK-0363第十章で予告された**バイト同一移植(バイトどういついしょく、水準七: 汚染前の既知の正常な状態を、1バイトの違いもなく複製することで、疑いのない土台をまず確保する復旧の手法)**は、本巻が扱うバックアップからの復元にも、そのまま当てはまる考え方である。復元とは、単に「ファイルが元の場所に戻っていること」ではなく、「戻された内容が、基準線(既知の正常な状態)と寸分違わず一致していること」を意味する。
### 復元検証の合格基準
本書が求める復元検証の合格基準は、既知の正常な状態(基準線)とハッシュ値等で突き合わせ、実行して比べた結果が完全に一致することである。「画面が動いて見える」ことは、→BOOK-0363第十章がすでに明確にしたとおり、復元が完了した証拠にはならない。
### ハッシュと機械突合という道具立て
前巻(BOOK-0364第二章)で扱われた**ハッシュ関数**(FUNC-0188・ハッシュ化の概念/hash concept)と**チェックサム**(FUNC-0189・チェックサム・CRC概念/checksum・CRC concept)は、復元検証においても中心的な道具になる。復元前の基準線から計算したハッシュ値と、復元後のデータから計算したハッシュ値が完全に一致すれば、「1バイトも変わっていない」ことを検算できる。
この考え方を、複数の時点の状態を比べる形に一般化した機能素が、総関数辞書には複数登録されている。**FUNC-1146(スナップショット突合状態復元検証/snapshot restore verify)**は、「処理開始前に対象状態(プレイヤー座標等)を退避しておき、処理完了後に現在の状態を退避スナップショットと突き合わせて完全一致するかを確認し、一致すれば『完全復元』、不一致なら『変化あり』としてログの文言を出し分ける」という、事後検証を伴う状態保存パターンであり、これはまさに「復元前」と「復元後」を機械的に突き合わせる、本章の思想そのものの実装例である。また**FUNC-0997(版差分抽出/version diff extraction)**は、2つの版(スナップショットや履歴時点)を比較し、追加・削除・変更されたカードの一覧を抽出する機能素であり、その不変条件は「追加+削除+変更+不変のカード数の合計は、旧版と新版の和集合のカード数に一致する(どのカードも分類漏れしない)」と定められている。復元検証の実務でも、「何が一致し、何が一致しなかったか」を1件も取りこぼさずに突き合わせることが、合格基準の核心になる。
### 保存則検査という、もう一つの機械突合
→BOOK-0363第九章・前巻第五章でも扱われた**FUNC-0769(保存則検査/conservation law check)**は、台帳全体の帳尻——発行合計から消滅合計を引いた値が、全所有者の残高の合計に一致するという等式——を検査する機能素である。この考え方は、復元検証にもそのまま応用できる。復元後のデータについて、「復元されたはずの総量」と「実際に存在を確認できた総量」が一致するかを機械的に検査することは、1件ずつファイルを目視で確認するよりもはるかに確実に、部分的な復元漏れを発見できる。前巻で扱った改竄検知の考え方(1件ずつの見た目ではなく、全体の帳尻を機械的に突き合わせる)は、判定の場面だけでなく、復旧が完了したかどうかを確かめる本章の場面でも、同じ強さを発揮する。
### 点検7 — 次の2つの報告のうち、復元検証として十分なのはどちらか
```
報告X: 「バックアップから全ファイルをコピーし直したところ、ファイル数が復元前の
一覧と一致していることを確認した」
報告Y: 「バックアップから全ファイルをコピーし直し、復元前に計算しておいた基準線の
ハッシュ値と、復元後の各ファイルのハッシュ値をFUNC-0997相当の機械突合で
比較したところ、追加0・削除0・変更0で完全に一致することを確認した。この
確認は、復元作業を行った担当者とは別の担当者が独立に再実行した」
```
報告Xは「ファイル数が一致している」ことしか確認しておらず、ファイルの中身が1バイトも変わっていないことまでは保証しない(ファイル数が同じでも、中身が壊れている可能性は残る)。報告Yは、ハッシュ値による内容の突き合わせと、独立した担当者による再確認という、→BOOK-0363第十章・点検10がすでに示した復旧完了の基準を満たしている(点検成立)。
---
> **定着量の目安(第七章)**: 「ファイルの数が合っている」ことと「ファイルの中身がハッシュ値で一致している」ことの違いを、自分の言葉で説明できるようにしておく。FUNC-1146・FUNC-0997・FUNC-0769という3つの機能素が、それぞれ復元検証のどの部分を担うかを整理してみると、機械突合という考え方の全体像が定着しやすい。
---
## 第八章: 復元テストの重要性(水準八)
### 「テストされていないバックアップは、存在しないのと同じ」という格言
実務ではしばしば、「テストされていないバックアップは、存在しないバックアップと同じである」という格言が語られる。この格言が伝えたいのは、復元できることを実際に確認していないバックアップは、存在しないバックアップと同じだけの価値しかない、という戒めである。
この格言が誇張ではないことは、これまでの章がすでに示している。第三章では、増分バックアップの連鎖のどこか1つが壊れているだけで、それ以降の復元が成立しなくなることを見た。第六章では、バックアップの取得が問題なく完了していても、復元にかかる時間は別の検算が必要であることを見た。第七章では、「戻せたつもり」を機械的に否定する仕組みが必要であることを見た。これらすべての章は、「バックアップという行為が完了していること」と「そのバックアップから、実際に元どおり復元できること」が、まったく別の事実である、という同じ結論に収束している。
### 復元テストの5つの型
復元テストにも、実務でよく整理される段階がある。
```
①チェックリスト式テスト : 復元手順書の記載内容を、担当者が机上で読み合わせる
②机上演習(ウォークスルー): 手順書に沿って、誰が何をするかを会話ベースで確認する
③シミュレーションテスト : 本番とは切り離した検証環境で、実際に復元操作を行ってみる
④並行運用テスト : 本番を止めずに、別環境へ並行して復元を行い結果を突き合わせる
⑤全面復旧テスト : 実際にシステムを止め、本番相当の環境で通しで復元を行う
```
①→⑤に進むほど、テストの現実性は高まるが、必要な準備とコストも大きくなる。すべてのシステムに毎回⑤を課すことは現実的でないことも多く、システムの重要度に応じて、どの型のテストをどの頻度で行うかを設計することが、実務上の判断になる。
### 点検8 — なぜ「バックアップが取れている」ことの確認だけでは足りないのか
ある組織が、「毎晩のバックアップジョブが、エラーなく正常終了したというログを、毎朝担当者が確認している」という運用を行っていたとする。この運用は、復元テストとして十分だろうか。バックアップジョブが正常終了したというログは、「書き込みの処理そのものが途中で止まらなかった」ことしか保証しておらず、書き込まれた内容が実際に復元可能かどうか、復元した結果が基準線と一致するかどうかまでは保証しない。第一章の入口の物語に立ち戻れば、「動いているように見える」ことと「本当に正しく動いている」ことが別の話であったのと同じ構造で、「バックアップが正常終了したように見える」ことと「そのバックアップから本当に復元できる」ことは別の話である(点検成立)。
### 実例 — 「使い捨て」であることの意味
第七章で紹介した**FUNC-1146(スナップショット突合状態復元検証)**の不変条件には、興味深い一節がある——「比較後は必ずスナップショットをnull等へクリアする(次回の退避と混同しない・使い捨てである)」。この「使い捨てである」という設計は、復元テストの実務にも通じる教訓を含んでいる。1回のテストで使った検証用の環境やデータを、次回のテストに使い回してしまうと、前回のテストの痕跡と今回の結果が混同され、「本当にゼロから正しく復元できたのか」が曖昧になる。復元テストは、毎回まっさらな状態から行い、前回の結果を持ち越さない——この規律が、テストの結果を信頼できるものにする。
### コラム — 復元テストの頻度も、RTOと同じ設計判断である
第四章で見たRPO・RTOと同様、復元テストをどれだけの頻度で行うかも、一律の正解があるわけではない。極めて重要なシステムでは四半期ごと、あるいは毎月の全面復旧テストが行われることもあれば、重要度がそこまで高くないシステムでは年に一度の机上演習にとどめることもある。大切なのは、「一度も試したことがない」という状態を作らないことであり、頻度そのものは、そのシステムが止まったときの影響の大きさに応じて設計すべき数値である、という考え方は、第四章のRPO・RTOの設計思想と地続きである。
---
> **定着量の目安(第八章)**: 「テストされていないバックアップは、存在しないのと同じ」という格言を、自分の言葉で説明できるようにしておく。復元テストの5つの型(①チェックリスト式〜⑤全面復旧テスト)を順に書き出し、それぞれどれくらいの現実性とコストを持つかを整理してみるとよい。
---
## 第九章: DRP(災害復旧計画)とBCP(事業継続計画)の違い(水準九)
### 2つの計画は、同じものではない
**DRP(災害復旧計画、Disaster Recovery Plan、水準九: IT・情報システムの復旧に焦点を当てた計画)**と**BCP(事業継続計画、Business Continuity Plan、水準九: 人・拠点・業務プロセスまで含めた組織全体の事業継続を扱う、より広い計画)**は、しばしば同じものと混同されるが、DRPはIT・情報システムの復旧に焦点を当てた計画であり、BCPは人・拠点・業務プロセスまで含めた組織全体の事業継続を扱う、より広い計画である、という包含関係にある。
### 図で確かめる、包含関係
```
┌───────────────────────────────────────────┐
│ BCP(事業継続計画) │
│ ・人員の安否確認と代替体制 │
│ ・代替拠点(オフィスが使えない場合の勤務場所) │
│ ・取引先・顧客との連絡体制 │
│ ・業務プロセスの手動代替手順 │
│ ┌─────────────────────────────────────┐ │
│ │ DRP(災害復旧計画) │ │
│ │ ・システムの復旧手順(本巻が扱う中身の大半) │ │
│ │ ・RPO/RTOの目標値 │ │
│ │ ・バックアップからの復元手順 │ │
│ └─────────────────────────────────────┘ │
└───────────────────────────────────────────┘
```
DRPはBCPの一部であり、「業務を止めないための計画」全体の中で、「情報システムをどう復旧させるか」という一角を担う専門分野、という位置づけになる。国際規格の側からも、この整理はおおむね裏付けられている。国際標準化機構(ISO)が策定した`ISO 22301`という事業継続マネジメントの国際規格は、組織全体の事業継続を扱う枠組みを示しており、情報システムの技術的な復旧計画(DRP)は、この枠組みの中に位置づけられる専門領域の一つとして扱われることが多いとされる。
### 点検9 — システムだけ復旧しても、業務は再開できるとは限らない
あるオフィスビルが水害に見舞われ、業務用サーバーは無事だったが、社員が誰もオフィスに立ち入れなくなったとする。この場合、サーバーの復旧(DRPの範囲)だけを完璧に行っても、業務は再開できるだろうか。サーバーが正常に復旧していても、それを操作する社員がオフィスに入れず、代替の勤務場所や在宅での接続手段が用意されていなければ、業務は再開できない。このシナリオは、DRP(システムの復旧)だけでは足りず、人員や拠点までを含むBCP側の備えが同時に必要である、という本章の核心を示している(点検成立)。
### コラム — なぜこの区別が実務で重要なのか
DRPとBCPを混同したまま「災害への備え」を1つの計画書にまとめてしまうと、システムの復旧手順書の中に、社員の安否確認や代替拠点の手配といった、性格の異なる項目が混在してしまい、担当者ごとの役割分担が曖昧になりやすい。→BOOK-0363第十二章で扱われた「指揮役・実行役・記録役・連絡役」という体制設計の考え方は、DRPとBCPのどちらの文脈でも必要になるが、DRPの実行役には主にIT技術者が、BCP全体の指揮には経営層や総務部門が関わることが多く、この違いを意識した体制設計が、実務上の混乱を防ぐ。
### コラム — BCPの演習は、DRPの演習だけでは代替できない
第八章で扱った復元テストの5つの型(①チェックリスト式〜⑤全面復旧テスト)は、あくまでDRPの側——システムが正しく復元できるかどうか——を確認する演習である。BCPの演習は、これとは別に、人と拠点の側を確認する必要がある。たとえば「主要な担当者が同時に出社できない場合、誰が代役を務めるか」「電話とメールの両方が使えない場合、どの手段で連絡を取るか」といった問いは、システムをどれだけ丁寧に復元テストしても答えが出ない。DRPの復元テストで「緑」の評価を得たシステムが、BCPの演習では体制の不備が見つかり「黄」にとどまる、という状況は珍しくなく、この2種類の演習は、どちらか一方で他方を兼ねることができない、独立した検証の軸である。
---
> **定着量の目安(第九章)**: DRPとBCPの関係を、「DRPはBCPの一部である」という一言と、その理由(システムだけ直っても、人や拠点が動かなければ業務は再開できない)をあわせて説明できるようにしておく。
---
## 第十章: クラウド時代の災害復旧 — マルチリージョンとフェイルオーバー(水準十)
### 「待機系をどれだけ温めておくか」という段階
クラウドサービスが普及する以前、災害復旧の備えは、遠隔地に予備の機器一式をあらかじめ購入し、平常時は電源を落として保管しておく、という高コストな形が主流だった。クラウド時代には、この「予備をどれだけ用意しておくか」を、コストと復旧速度のトレードオフとして、段階的に選べるようになっている。
```
段階 | 主な内容 | 相対コスト
--------------------|-----------------------------------------------|------------
バックアップ&リストア | バックアップからのみ復元。平常時は稼働環境を持たない | 最小
パイロットライト | 中核部分(データベース等)だけを最小構成で常時起動 | 小
ウォームスタンバイ | 縮小規模の環境を、常時稼働させておく | 中
マルチサイト | 複数の地域(リージョン)で、本番同等の環境を | 最大
(active-active) | 常時同時稼働させる |
```
段階が下に進むほど、平常時から稼働させておく環境の規模が大きくなり、コストは増えるが、障害発生時にはすでに動いている環境へ切り替えるだけで済むため、復旧にかかる時間は短くなる。備えの水準を上げるほど(バックアップ&リストアからマルチサイトへ)RTO・RPOは短縮されるがコストは増加するという、トレードオフの階段になっている。これらの数値はあくまで一般的な目安であり、実際の値は構成やデータ量によって大きく変わる、という誇張のない留保もあわせて添えておく。
### フェイルオーバーという言葉
**フェイルオーバー(failover、水準十: 主系統(現在稼働している系統)に障害が発生したとき、あらかじめ用意された副系統(待機系)へ自動的または手動で切り替えること)**という言葉は、この段階のいずれにおいても、実際に切り替えを行う操作そのものを指す。マルチリージョン構成では、ある地域(リージョン)全体が使えなくなった場合に、別の地域で稼働している系統へフェイルオーバーすることで、利用者から見た停止時間を最小限に抑える設計が可能になる。
### 実例 — 一時的な障害と、恒久的な障害を区別するという設計思想
フェイルオーバーを設計するうえで避けるべき典型的な誤りは、一時的な瞬断のたびに即座に切り替えを行ってしまい、切り替え自体のコストや、切り替え先での不整合のリスクを不必要に増やしてしまうことである。本プロジェクトの総関数辞書に登録されている**FUNC-0384(リトライ/retry with backoff)**は、「一時的な失敗(ネットワーク瞬断等)が予想される処理に対し、一定回数まで待機時間を挟みながら再実行する」という機能素であり、その罠の欄には「恒久的なエラー(認証情報が誤っている等、何度再試行しても成功しない種類の失敗)まで一律にリトライすると、無駄な待機と外部サービスへの負荷だけが増える(一時的エラーと恒久的エラーを区別せずに使う典型的な誤用)」と記されている。この教訓は、フェイルオーバーの設計にもそのまま応用できる——「一時的な障害なのか、恒久的な障害なのか」を見極め、一時的なものにはまずリトライで様子を見て、それでも回復しない恒久的な障害と判断できたときに初めてフェイルオーバーへ踏み切る、という2段構えの設計が、無用な切り替えの乱発を防ぐ。
### 点検10 — マルチサイト構成なら、復元テスト(第八章)は不要になるか
ある組織が、「複数の地域で本番同等の環境を常時同時稼働させるマルチサイト構成を導入したので、もう復元テストは不要になった」と考えていたとする。この考え方は正しいだろうか。マルチサイト構成は、ある地域全体の障害に対する備えとしては極めて強力だが、データそのものの破損(たとえば誤った書き込みや、意図的な改竄)は、複数の地域へ即座に複製されてしまうことがあり、「複数箇所で同時に稼働している」ことは「データの内容が正しい」ことを保証しない。したがって、マルチサイト構成を導入していても、第八章で扱った復元テストや、第七章で扱った機械突合による検証は、依然として必要である(点検成立)。フェイルオーバーの速さと、データそのものの正しさは、別の軸で守らなければならない。
---
> **定着量の目安(第十章)**: バックアップ&リストア→パイロットライト→ウォームスタンバイ→マルチサイトという4段階を、コストと復旧速度のトレードオフとして説明できるようにしておく。あわせて、「一時的な障害にはリトライ、恒久的な障害にはフェイルオーバー」という2段構えの考え方を、身近な例(スマートフォンの通信が一瞬途切れたときと、機種変更が必要なときの違いなど)に当てはめて説明してみるとよい。
---
## 第十一章: 現代最先端 — イミュータブルバックアップとエアギャップの復権(水準十一)
### バックアップそのものが標的にされるという時代
**ランサムウェア(ransomware、水準十一: 情報を暗号化するなどして利用不能にし、復旧と引き換えに金銭を要求する、身代金型の不正プログラムの総称)**という言葉の定義だけを、ここで確認しておく。本書は防御・復旧・教育に限定するという安全枠に従い、ランサムウェアがどのように展開されるか、どのように感染を広げるかという攻撃側の手順には一切立ち入らない。ここで扱うのは、あくまで「バックアップそのものが暗号化・削除の対象にされてしまう」という被害の型に対して、復旧側がどう備えるか、という防御的な論点だけである。
近年の被害事例では、バックアップそのものが標的にされ、復元の道を断ってから本体の暗号化を行うという被害パターンが、米国のCISA(サイバーセキュリティ・インフラセキュリティ庁)のような公的機関のガイダンスでも繰り返し警告されている。本書はその実行手順には立ち入らないが、「バックアップも攻撃対象になり得る」という前提に立って設計することの重要性だけは、防御側の教訓として明確に述べておく。この前提に立つと、「バックアップさえ取っておけば安心」という第一章の入口で確認した安心感そのものが、もう一段深く疑われなければならないことがわかる——バックアップが存在していても、それが同じ経路から書き換え・削除されてしまうなら、備えとしての意味を失うからである。
### イミュータブルバックアップという解決策
この課題に対する現代的な解決策が、**イミュータブルバックアップ(immutable backup、水準十一: 定めた保持期間の間、たとえ管理者権限を持つ操作からであっても、書き換えや削除ができない状態でバックアップを保持する方式)**である。第五章で扱ったWORM(書込一度読取専用)という考え方の現代版とも言え、クラウドストレージの「オブジェクトロック」機能や、専用のバックアップ装置が備える不変化(イミュータブル化)機能を通じて実現される。管理者権限を持つ操作からであっても変更・削除ができない、という点が重要であり、これは「管理者アカウントが乗っ取られた場合」という最悪のシナリオにおいてさえ、バックアップだけは守られる、という設計思想を体現している。
### エアギャップの復権
第五章で扱ったエアギャップという、一見すると古典的な物理分離の考え方が、ランサムウェア対策の文脈で、近年あらためて重要性を見直されている。ネットワークに常時接続されたバックアップは、たとえイミュータブル化されていても、そのバックアップシステム自体の設定や鍵が悪用されれば、理論上は影響を受ける経路が残る。これに対し、通常の通信経路から完全に切り離されたオフライン媒体は、そもそも遠隔からの操作が届かないため、この種の被害からもっとも隔たった場所に置かれることになる。第五章で確認したとおり、エアギャップも「ゼロにする」対策ではないが、複数の防御層(イミュータブル化+エアギャップ)を重ねることで、被害の確率をさらに引き下げる、という多層防御の考え方が、ここでも一貫して当てはまる。
### 3-2-1-1-0という拡張形
近年、業界でしばしば紹介される3-2-1ルールの拡張形に、**3-2-1-1-0ルール**と呼ばれる考え方がある。
```
3 : 少なくとも3つのコピーを持つ
2 : 2種類以上の異なる媒体に保存する
1 : そのうち1つは遠隔地に置く
1 : そのうち1つは、オフラインまたはイミュータブルな状態で保持する(本章の主題)
0 : 復元テスト(第八章)でエラーが0件であることを、毎回確認する
```
最後の「0」が、第八章で扱った復元テストの重要性と直接につながっている点に注目してほしい。どれだけ物理分離やイミュータブル化を重ねても、そのバックアップから実際に復元できることを確認していなければ、第八章の格言のとおり「存在しないバックアップと同じ」になってしまう。本章が扱う最先端の技術は、これまでの章で積み上げてきた基本の徹底の上に成り立っている、という事実を、この拡張形の最後の数字が静かに物語っている。
### 点検11 — なぜ「管理者権限からも変更できない」という性質が重要なのか
ある組織が、「バックアップへのアクセスは管理者アカウント1つに限定しており、そのアカウントは強固なパスワードで保護されている」という対策だけを講じていたとする。この対策は、イミュータブルバックアップと同等の効果を持つだろうか。パスワードがどれだけ強固であっても、その管理者アカウントの認証情報そのものが何らかの方法で奪われてしまえば、バックアップへの書き換え・削除の権限もそのまま奪われることになる。イミュータブルバックアップは、「認証情報が奪われた後であっても、定めた期間は変更・削除そのものが技術的に不可能である」という、権限の強さに依存しない、もう一段強い防御層を提供する点で、パスワード保護だけの対策とは性格が異なる(点検成立)。
---
> **定着量の目安(第十一章)**: イミュータブルバックアップとエアギャップの違いと共通点を、自分の言葉で説明できるようにしておく(共通点=いずれも「バックアップが標的にされても書き換えられない」という防御層である点)。3-2-1-1-0ルールの5つの数字を、それぞれ何を意味するか諳んじられるようにしておくと、本章と第二章・第八章のつながりが実感として定着する。
---
## 第十二章: 達人術 — 「一日で全システムを再構成せよ」と言われたら、何から手をつけるか(水準十二)
### 一日再構成プレイブックの「復旧」枠を、もう一段割る
→BOOK-0363第四章で示された一日再構成プレイブックを、あらためて思い出そう。
```
0〜2時間 : 判定 — 「緑を騙る赤」の特定
2〜6時間 : 封じ込め — 汚染の疑いがある資産を隔離
6〜18時間 : 復旧 — バイト同一移植と機械突合で正常部分を復元し、
境界だけを作り直す
18〜24時間: 再検定 — チェッカーで緑を再取得する
```
本巻が専門に担うのは、この12時間という、もっとも長い時間が割り当てられた「復旧」の枠である。この12時間を、本書がここまで積み上げてきた知識を使って、さらに具体的な段階表へと分解する。
### 完全な段階表
```
6h〜7h (1時間): 基準線の実在確認
既知の正常な状態(直近の緑のバックアップ)が、本当に存在し、読み出せる
ことを確認する。3-2-1ルール(第二章)が守られているなら、この時点で
1つの媒体が読めなくても、別の媒体・別の遠隔地のコピーへ切り替えられる。
7h〜8h (1時間): 基準線のハッシュ整合確認
直近のバックアップのハッシュ値(第七章)を、記録済みの値と突き合わせ、
バックアップ自体が汚染前の状態であることを検算する。ここが崩れていれば、
1世代前の基準線まで、判定(前巻)の技術を使ってさかのぼる。
8h〜14h (6時間): バイト同一移植による一括復元
疑う必要のない大部分を、基準線からバイト同一移植でまとめて復元する
(第七章)。増分・差分の連鎖を使う場合は、第三章・第六章の教訓に従い、
連鎖の各段をあらかじめ機械突合しておく。
14h〜17h(3時間): 境界だけの作り直し
判定(前巻)で汚染の疑いがあると確定した境界部分だけを、個別に
作り直す。→BOOK-0371が専門に扱う領域だが、本書の第十章で扱った
「一時的な障害か恒久的な障害か」の見極めと同じ判断が、境界の
再構成にも適用できる。
17h〜18h(1時間): 復元検証と申し送り
FUNC-1146・FUNC-0997・FUNC-0769相当の機械突合(第七章)で、復元後の
状態と基準線が完全一致することを確認し、次の18〜24時間(再検定)へ
引き継ぐための記録を残す。
```
まず既知の正常な基準線(直近の緑のバックアップ)の実在とハッシュの整合を確認し、疑う必要のない部分をバイト同一移植でまとめて復元し、最後に疑わしい境界だけを作り直して、再検定に十分な時間を残す——これが、本巻が示す「復旧」段階の考え方である。
### 点検12 — この段階表の最初の1時間を省略したら、何が起きるか
もし担当者が、基準線の実在確認(6h〜7h)を省略し、いきなり一括復元(8h〜14h)から着手していたとする。何が起きるだろうか。もし選んだバックアップの媒体が実は読み出せない状態だったり、その世代のバックアップ自体が汚染前のものではなかったりした場合、後になって発覚し、それまでの復元作業がすべて無駄になる。しかも、その発覚が18時間を過ぎてから起きれば、24時間という制約の中で取り返しがつかなくなる。「短く鋭く確認してから、厚く復元する」という→BOOK-0363第四章の思想は、本書の段階表でも、最初の2時間という小さな投資として、一貫して受け継がれている(点検成立)。
### 実例 — 決定的な再構成という、最後の一押し
再構成の最終盤で忘れてはならない性質が、**FUNC-0792(冪等な再生成/idempotent regeneration)**が示す考え方である。この機能素の定義は、「生成器を同じ入力に対して複数回実行しても、既存の出力ファイルと1バイトも変わらない結果を返す」というものであり、その罠の欄には「生成物にビルド日時やランダムなコメントID等を埋め込むと、入力データが1つも変わっていないのに再生成のたびに出力バイト列が変わり、バージョン管理上の無意味な差分(生成物diffノイズ)が蓄積する」と記されている。この教訓は、境界の作り直し(14h〜17h)にもそのまま当てはまる。境界を作り直す作業が、毎回微妙に異なる結果を生む(たとえば現在時刻や乱数を紛れ込ませてしまう)ようでは、17h〜18hの復元検証で「一致しない」という誤検出が続発し、貴重な時間を無駄にする。境界の作り直しそのものにも、決定的である(同じ条件からは常に同じ結果になる)という性質を求めることが、機械突合による検証を機能させる前提条件になる。
---
> **定着量の目安(第十二章)**: 本章の段階表(6h〜7h基準線確認/7h〜8hハッシュ整合/8h〜14h一括復元/14h〜17h境界作り直し/17h〜18h復元検証)を、時間配分ごと諳んじられるようにしておく。「なぜ最初の2時間を確認に使うのか」を、点検12の思考実験を使って、自分の言葉で説明できるようにしておくことが、本書全体の総仕上げになる。
---
## 三つの実践解(§16.21) — 紙とペン、そして自分の端末の標準機能でできる実践
理論を、実際に手を動かして確かめる方法を三つ紹介する。いずれも特別な工具や外部サービスを必要とせず、紙とペン、あるいは自分の端末に最初から入っている標準機能だけで完結する、安全な実践解である。攻撃的な操作は一切含まない。
1. **自分の3-2-1点検を実際にやってみる実践**: 自分にとって大切なデータ(写真・書類・作りかけの作品など)を1つ選び、現在何個のコピーがあり、何種類の媒体に保存され、そのうち遠隔地にあるものが何個あるかを、実際に数えて紙に書き出してみる。第二章の3-2-1ルールに照らして、何が満たされていて何が欠けているかを点検し、欠けている項目があれば、標準機能(OS標準のバックアップ機能や、既存のクラウドストレージへのアップロードなど)だけで補えないかを考えてみる。
2. **1つのファイルで復元リハーサルをしてみる実践**: 実際に、何か1つの重要でないファイル(テスト用の文書など)をバックアップ先から手元へ復元し、元のファイルと復元したファイルの中身が完全に一致するかを、標準のファイル比較機能(多くのOSに標準で付属する「差分」や「比較」の機能)で確かめてみる。これは第七章・第八章で扱った「復元検証」と「復元テスト」を、もっとも小さな規模で安全に体験する練習になる。
3. **自分にとってのRPO・RTOを書き出す実践**: 身近なシステム(スマートフォンの写真データ、個人のパソコンの作業データなど)を1つ選び、「もし今日それが失われたら、何時間分・何日分までなら諦められるか(RPO)」「復旧に何時間・何日までなら待てるか(RTO)」を、それぞれ具体的な数字で紙に書き出してみる。書き出した数字と、実際の現在のバックアップ頻度を見比べ、RPOの目標を満たせているかどうかを、第四章の検算1と同じ要領で確かめてみるとよい。
---
## まとめ — 「戻る場所」を、あらかじめ設計しておくという仕事
本書では、データが失われる理由が1つではないという事実からバックアップの必要性を確認し(第一章)、3つのコピー・2種類の媒体・1つの遠隔地という3-2-1ルールで「どう置くか」を具体化し(第二章)、フル・差分・増分という3方式のトレードオフを整理した(第三章)。続いて、RPO(どこまで戻すか)とRTO(どれだけ止められるか)という2つの物差しで設計を数値化し(第四章)、エアギャップとWORMという物理分離の意味を確かめ(第五章)、増分バックアップの効果を実際の検算で誇張なく確かめた(第六章)。そのうえで、バイト同一移植と機械突合による復元検証(第七章)、テストされていないバックアップは存在しないという格言(第八章)、DRPとBCPという2つの計画の違い(第九章)、クラウド時代のマルチリージョン・フェイルオーバー(第十章)、イミュータブルバックアップとエアギャップの復権(第十一章)をたどり、最後に「一日で全システムを再構成せよ」と言われたときの完全な段階表(第十二章)にたどり着いた。
判定(前巻)が「何が壊れたかを確定する」仕事だったのに対し、本巻が扱ってきたのは、一貫して「戻る場所を、あらかじめ設計しておく」仕事である。バックアップは、事故が起きてから慌てて用意するものではなく、事故が起きる前提で、あらかじめ静かに積み上げておくものである——この考え方こそが、本書全体を貫く一本の糸だった。
---
## 章末: 3-2-1ルールの図と、階段図
まず、第二章で扱った3-2-1ルールを、あらためて図の形で見てみよう。
```
元データ
│
┌─────┼─────┐
│ │ │
コピー1 コピー2 コピー3(遠隔地)
(内蔵) (外付け) (クラウド等)
└─2種類以上の媒体┘
└────1つは遠隔地────┘
全部で3つのコピー
```
続いて、本書全体の歩みを階段図としてまとめる。
```
[水準十二] 達人術・一日再構成の段階表
6h〜7h基準線確認〜17h〜18h復元検証(点検12)
▲
│ 「短く鋭く確認、厚く復元」の総仕上げ
[水準十一] イミュータブルバックアップ・エアギャップの復権
3-2-1-1-0/管理者権限からも書き換え不能(点検11)
▲
│ バックアップそのものが標的にされる時代への備え
[水準十] クラウド時代の災害復旧
パイロットライト/ウォームスタンバイ/マルチサイト(点検10)
▲
│ 待機系をどれだけ温めておくか、というコストの階段
[水準九] DRPとBCPの違い
DRPはBCPの一部(点検9)
▲
│ システムが直っても、人と拠点が動かねば業務は戻らない
[水準八] 復元テストの重要性
「テストされていないバックアップは存在しない」(点検8)
▲
│ 取れていることと、戻せることは別の話
[水準七] バイト同一移植と機械突合
FUNC-1146/FUNC-0997/FUNC-0769による復元検証(点検7)
▲
│ 「動いて見える」を疑う、判定と同じ思想
[水準六] 補助技術の定量効果
増分バックアップ=取得78%短縮/復元はむしろ微増(検算2〜5)
▲
│ 速くなるのは何で、速くならないのは何か
[水準五] 物理分離システムの意味
エアギャップ/WORM/オフライン保管(点検5)
▲
│ 同じ経路でつながっていれば、同じ運命を辿る
[水準四] RPOとRTO
どこまで戻すか/どれだけ止められるか(検算1・点検4)
▲
│ 感覚ではなく数値で設計する
[水準三] フル・差分・増分
書き込む量と復元の手順のトレードオフ(点検3)
▲
│ 3つの方式、それぞれの得意・不得意
[水準二] 3-2-1ルール
3つのコピー・2種の媒体・1つは遠隔地(点検2)
▲
│ 運命を共にしない場所に置く、という条件
[水準一] バックアップとは何か
データが失われる5つの原因/可用性という物差し(点検1)
横の広がり:
[水準三] フルバックアップ ←(手順は単純・書込量は最大)→ 増分バックアップ(逆)
[水準九] DRP(システム側) ←(包含関係)→ BCP(組織全体)
[水準十一] イミュータブル化(技術的に不可能にする) ←(補完)→ エアギャップ(経路を断つ)
現在のフロンティア(第二章コラム・第十一章):
2005年ごろ 3-2-1ルールが写真家ピーター・クロッグの著書を通じて広まったとされる
2010年代 クラウド事業者の資料を通じて、パイロットライト・ウォームスタンバイ・
マルチサイトという段階的なクラウド災害復旧の考え方が広く紹介されるようになった
2020年代 ランサムウェアがバックアップ自体を標的にする被害が公的機関からも
繰り返し警告され、イミュータブルバックアップとエアギャップの復権が
あらためて注目されている
2026年 本プロジェクト内で、_vaultスナップショット退避運用が波締めごとに
実測され続けている(本書執筆時点の実例)
※本書で扱ったRPO/RTO・3-2-1・復元検証の考え方は、未解決の謎ではなく、
現在進行形で実務に使われ続けている現役の設計原理という意味でのフロンティアである。
次の巻(情報防衛と復旧シリーズ): BOOK-0366(可用性・信頼性工学
─冗長化→段階的縮退→止まらないための設計) ─────▶
```
---
## 参照文献(定番指針・一般規格・本プロジェクトの実在記録)
1. ピーター・クロッグ(Peter Krogh)『The DAM Book: Digital Asset Management for Photographers』(2005年)。3-2-1ルールの起源としてしばしば紹介される、写真家自身の実践知をまとめた著作とされる。
2. 米国CISA(サイバーセキュリティ・インフラセキュリティ庁)による、バックアップの基本原則(3-2-1ルール等)とランサムウェア対策(#StopRansomwareガイダンス等)に関する公開資料群。
3. 国際標準化機構(ISO)が策定した`ISO 22301`(事業継続マネジメントシステムの国際規格)。DRPとBCPの包含関係を整理するうえでの、国際的な枠組みとして広く参照される。
4. 米国国立標準技術研究所(NIST)による、情報システムの緊急時対応計画に関する指針群(`NIST SP 800-34`系列)。RPO/RTOという考え方が、連邦情報システムの実務指針の中でも扱われていることで知られる。
5. 本プロジェクトの実在記録: `gakumon/NUMBER_REGISTRY.md`(波締めごとの`_vault`退避運用の実測記録)、`CLAUDE.md`(退避金庫の運用規約)。
6. 本プロジェクトの実在実装: `tools/check_conservation.js`(保存則監査器。FUNC-0769の実例、→BOOK-0363第九章・前巻第五章で詳述)。
7. 本プロジェクトの実在資産: `gakumon/DIC_FUNC_中核意味素辞典_第1巻.md`(FUNC-0384/0436/0638/0639/0662/0769/0792/0969/0994/0996/0997/1146の各カード)。
---
（本冊子は情報防衛と復旧シリーズ BOOK-0365。全12巻中の第6巻(バックアップと災害復旧)であり、「一日停止・全システム再構成」特命業務の「構成し直し」段階を担う。次巻BOOK-0366(可用性・信頼性工学)では、本書が扱いきれなかった「止まらないための設計」——冗長化・段階的縮退——を専門に掘り下げる予定。CATALOG_情報防衛と復旧シリーズ.md・GAKUMON_UNIVERSE.md 進捗台帳を参照。）
# BOOK-0365 情報防衛と復旧シリーズ 第6巻: バックアップと災害復旧 — 止めないためではなく、止まった後に必ず戻ってこられるようにするための一冊