ある会社では、毎晩バックアップ処理が実行されていました。管理画面を見ると、ここ数週間ずっとSuccessと表示されており、担当者は毎朝その画面を確認し、失敗していないことを確認していました。
ところがある日、利用者から「重要なファイルの内容がおかしい」という連絡が入りました。調べてみると、そのファイルが壊れ始めたのは、その日に起きた障害が原因ではありませんでした。数日前から少しずつ壊れた状態になっていたことが分かりました。その間もバックアップ処理は毎日正常に完了しており、つまり、直近のバックアップにも、その一つ前のバックアップにも、すでに壊れた状態のデータが含まれていました。
このような状況で、「バックアップは毎日成功しています」という事実だけを確認しても、問題は解決しません。必要なのは、どの時点まで戻れば、必要な状態を取り戻せるのかを判断することです。さらに、その時点のデータを本当に取り出せるのか。取り出したデータを利用できる状態まで戻せるのか。ということまで考える必要があります。
ここに、Backup（バックアップ）を考えるときの最も重要な出発点があります。
1.1 なぜBackupを取るのか
Backupとは、データやシステムの状態を、必要なときに利用できるよう別の形で保持しておくための仕組みです。
しかし、Backupを作ること自体が最終目的ではありません。
現場では、
- バックアップ処理が成功している
- バックアップファイルが存在する
- 30日分保存している
- 別のストレージにもコピーしている
といった説明を聞くことがあります。
しかし、それだけで、「必要になったときに復旧できる」とは言えません。
例えば、バックアップファイルが存在していても、実際にRestoreしたことが一度もなければ、本当に利用できるかどうかは分かりません。復旧手順が担当者の頭の中にしか残っていなければ、その担当者が不在のときに復旧できないかもしれません。データをRestoreできても、アプリケーションの設定や認証情報など、動作に必要な別の要素が失われていれば、利用者が使える状態まで戻らない可能性があります。
つまり、「Backupが存在すること」と「Recoveryできること」は別の問題です。
本書では、BackupをRecovery（復旧）に必要な手段の一つとして考えます。
BackupはRestore（リストア・復元）して利用することを前提とするため、BackupとRestoreは切り離して考えるものではありません。
Backupだけを設計し、Restoreを考えないというのは、「避難用の出口は作ったが、実際にその扉が開くかは確認していない」という状態に近いと考えることができます。
ただし、ここでさらに一つ注意が必要です。Restoreできたからといって、それだけでRecoveryが完了したとは限りません。この違いについては、次の節で詳しく見ていきます。
Backupという考え方は本書だけのものではない
ここまでの説明は、「筆者がBackupをそのように定義しているだけ」という話ではありません。米国国立標準技術研究所、NIST（National Institute of Standards and Technology）は、情報システムのセキュリティや運用に関する多くの技術文書を公開しています。その一つである、情報システムの復旧計画について扱った NIST SP 800-34 Rev.1 でも、BackupはRecoveryを支える活動の一つとして扱われています。
重要なのは、NISTという名前や文書番号ではなく、この考え方そのものです。標準やガイドラインは、その考え方を確認したり、設計を見直したりするための根拠として使います。
1.2 Backup / Restore / Recoveryは同じではない
Backup、Restore、Recovery。現場では、この3つの言葉が曖昧に使われることがあります。しかし、設計するときには分けて考えた方が分かりやすくなります。
Backupとは、復旧に利用するためのデータや状態を保持することです。
Restoreとは、そのBackupなどを使ってデータや状態を戻す操作です。
Recoveryとは、必要なデータや機能を実際に利用できる状態まで取り戻すことです。
簡単に整理すると、次のようになります。
Backup
↓
利用する復旧時点を選ぶ
↓
Restore
↓
戻したデータやシステムを確認する
↓
利用できる状態へ戻す
↓
Recoveryこの図は、Backup、Restore、Recoveryの違いを理解しやすくするために、本書で簡略化したものです。
重要なのは、Restore成功 = Recovery成功ではない、ということです。
Restoreには成功した。しかしRecoveryは終わっていない
例えば、ある業務システムでデータベース障害が発生したとします。バックアップファイルは残っていました。担当者は手順に従ってRestoreを実施し、データベースそのものは正常に戻りました。ここまでなら、Restore成功です。
ただし、ここで戻ったのはデータベースであり、業務システム全体が利用できる状態まで戻ったことを意味するわけではありません。
しかし、その後アプリケーションを起動しようとすると動きません。調べてみると、
- 必要な設定が失われている
- 証明書が利用できない
- サービスが利用する認証情報が分からない
といった問題が残っていました。
データベースは戻っています。しかし、利用者は業務システムを使えません。この場合、Restoreは成功しています。しかし、Recoveryはまだ完了していません。
新人のうちは、
データが戻った
＝復旧した
と考えがちです。
しかし実際のシステムは、データだけで動いているわけではありません。アプリケーション、設定、認証、ネットワーク、名前解決、鍵や証明書など、さまざまな要素が組み合わさって動いています。Chapter 1では、これらすべてを詳しく扱いません。ここではまず、Restoreすることと、Recoveryすることは同じではないと理解できれば十分です。
1.3 何を守り、何に備えるのか
「バックアップがあるから安心」という言葉は、現場では少し危険です。なぜなら、何を守ろうとしているのかによって必要な備えが変わるからです。さらに、それがどのような理由で失われる可能性があるのかによっても必要な備えは変わります。
まず考えるのは、何を守る必要があるのかです。
例えば、
- ファイル
- データベース
- システムの設定
- 仮想マシン
- 業務システム
など、守る対象はいろいろあります。
ただし、本書の後半ではさらに広い視点で考えることになります。今の段階では、「データだけ守ればよい」と決めつけず、そのシステムが復旧するためには何が必要なのかという問いを持つことが重要です。
その次に考えるのが、何に備えるのかです。
同じファイルを守る場合でも、
- ストレージが故障する
- 利用者が誤って削除する
- データが徐々に壊れる
- 悪意ある変更を受ける
- 拠点そのものが利用できなくなる
では、必要な備えが同じとは限りません。
例えば、「ディスクが壊れた」という問題と、「利用者が3日前に必要なファイルを削除していた」という問題では、戻したい状態が違います。さらに、「10日前からデータが少しずつ壊れていた」のであれば、単に最新データを戻すだけでは問題が解決しません。したがって、何を守るのか × 何に備えるのかによって、必要な保護の考え方は変わります。
このような「どのような形で失われる可能性があるのか」は、必要に応じてLoss Scenario（損失シナリオ）という言い方で考えることもできます。最初からこの言葉を覚える必要はありません。
まずは、
何を守るのか。
何が起きたら困るのか。
という2つの問いを持ってください。
最初に考える問い
| 想定する問題 | 最初に考える問い | 詳細を扱う章 |
|---|---|---|
| ストレージ障害 | 何を、どの状態まで戻す必要があるか | Chapter 2 |
| 誤削除 | 削除前の状態は残っているか | Chapter 2以降 |
| 論理破損（冒頭の例） | いつから問題が始まったか | Chapter 2以降 |
| 拠点喪失 | 同じ場所を失っても復旧手段は残るか | Chapters 7–8 |
この表は、「この障害なら必ずこの製品を使う」という対応表ではありません。Chapter 1では、特定の障害に対する具体的なRecovery方法までは解説しません。具体的な方法は、後の章で扱います。
1.4 「何世代残すか」だけでは足りない
バックアップ設計について話していると、「何世代保存していますか？」という質問がよく出ます。
例えば、
- 7世代
- 14世代
- 30世代
といった形です。世代数はもちろん重要です。しかし、何世代残しているかだけでは、必要な状態へ戻れるかどうかは分かりません。
例えば、毎日1回バックアップを取得し、7世代保持するとします。単純に考えれば、おおよそ1週間分の状態を残せます。
ところが、今日になってデータの破損が発見されました。調査すると、破損が始まったのは10日前だったとします。この場合、直近7世代すべてに壊れた状態が含まれている可能性があります。
つまり、バックアップが7世代あることと、必要な正常状態まで戻れることは同じではありません。
ここで重要になるのが、どこまで過去へ戻れるのかという考え方です。
本書では、このような復旧可能な時間範囲を考える際に、Recovery Windowという言葉を使うことがあります。ただし、用語を覚えることよりも重要なのは考え方です。
過去 現在
正常 ───── 問題発生 ───── Backup継続 ───── 発見
↑
戻したい状態この図で重要なのは、問題が発生した時刻と、問題を発見した時刻が違うことです。
障害は、発見された瞬間に始まるとは限りません。例えば、
- データが少しずつ壊れていた
- 誤った設定が数日前に投入されていた
- 利用者が削除したことに誰も気付いていなかった
- 侵害された状態がしばらく発見されなかった
ということがあります。
そのためRetention（保持）を考えるときには、
- 何個残すのか
- どれくらい過去まで戻れるのか
- 問題に気付くまでどれくらい時間がかかり得るのか
を分けて考える必要があります。
30世代あれば十分なのか
ここで、「それなら30世代あれば安全なのでは？」と考えるかもしれません。しかし、そう単純ではありません。
システムによって、
- データの変化量
- バックアップ頻度
- 障害を発見できるまでの時間
- 戻す必要のある時点
は違います。
毎日1回のバックアップで30世代と、1時間ごとのバックアップで30世代では、戻れる時間範囲はまったく違います。
また、障害がすぐ発見できるシステムと、数週間後に初めて問題が分かるシステムでも、必要な保持の考え方は変わります。
したがって、「何世代なら正解」という数字を一律に決めることはできません。重要なのは、必要な状態へどこまで過去に戻れる必要があるのか。そして、問題を発見するまでに、どれくらい時間がかかる可能性があるのか。という問いです。本章では、すべてのシステムに共通する固定ルールとして扱いません。
1.5 最新のBackupを戻せばよいとは限らない
バックアップが複数残っているとき、「一番新しいものを戻せばよい」と考えるのは自然です。
実際、単純な機器故障などでは、最新状態へ戻したい場合も多くあります。
しかし、最新のバックアップが常に最も適した復旧点とは限りません。
例えば、利用者が重要なデータを削除したとします。その削除後にバックアップが作られていれば、最新のバックアップには削除済みの状態が保存されています。
論理破損の場合も同じです。
壊れた状態がバックアップされていれば、最新のバックアップをRestoreしても壊れた状態が戻ってきます。悪意ある変更や侵害についても同様の問題が起きる可能性があります。そのため、どのバックアップが新しいかだけではなく、どの時点が必要な状態だったのかを考える必要があります。NISTが公開しているサイバー攻撃からの復旧に関する技術文書でも、正しいバックアップ版や既知の良好な状態を選ぶ必要性が扱われています。
では、どの時点を信用するのか
ここまで読むと、「では、どのバックアップが正常なのか、どう判断するのか」という疑問が出てきます。特にサイバー攻撃や長期間気付かなかった破損では、いつから信用できない状態になったのかそのものが分からないことがあります。この問題はChapter 1だけでは解決しません。Recovery Point（復旧の対象として選ぶ時点・状態）のどれを信用するのか、どの状態を正常と判断するのかという問題は、後の章で改めて扱います。ここでは、最新だから正しい、と決めつけないことだけ覚えてください。
1.6 Backup成功とRecovery成功は別である
バックアップ製品の画面に、
Backup completed successfullyと表示されていたとします。
これは重要な情報です。バックアップ処理が失敗しているのであれば、当然その原因を調べる必要があります。しかし、Successという表示があることと、Recoveryできることは同じではありません。その表示から確認できるのは主に、そのバックアップ処理が、定められた条件で完了したことです。
一方、
- 必要なデータを実際に取り出せるか
- 必要な時点まで戻せるか
- 復旧後のシステムを利用できるか
- 復旧に必要な周辺要素が揃っているか
といったことは、バックアップ処理の成功表示だけでは分かりません。これらは、バックアップ処理の成功とは別に確認すべき事項です。
例えば、バックアップジョブが30日間すべて成功していたとします。それでも、一度もRestoreしていないのであれば、「30日間バックアップ処理が成功した」ことは確認できても、「そのバックアップから本当に戻せる」ことまでは確認していません。
「取れている」と「戻せる」は別の確認
バックアップ運用では、取れていることの確認と、戻せることの確認を分けて考える必要があります。「取れているか」を見るのであれば、バックアップジョブの結果や保存先の状態などを確認することになります。しかし、「戻せるか」を確認するためには、実際のRestoreやRecoveryを考える必要があります。したがって、バックアップ設計では、「取れたか」だけでなく、「戻せることを確認しているか」まで考えます。
具体的に、
- どこまで試験するのか
- 何を成功と判断するのか
- どのような頻度で確認するのか
といったRecovery TestやExerciseについては、後のChapters 15–16で詳しく扱います。
Chapter 1では、Backup Success ≠ Recovery Successという点を理解できれば十分です。これは、この本全体を読むうえで何度も戻ってくる重要な考え方です。
1.7 この本でこれから何を学ぶか
ここまでで、Backupについて考えるための基本を整理しました。重要なのは、次の6点です。
- Backup、Restore、Recoveryは同じではない。
- BackupはRecoveryに必要な手段の一つとして考える。
- 何を守り、何に備えるのかによって必要な保護は変わる。
- Retentionは単純な世代数だけで考えない。
- 最新のBackupが最適なRecovery Pointとは限らない。
- Backup処理の成功だけではRecovery成功を証明できない。
次のChapter 2では、混同しやすい、Backup / Replication / Snapshot / Archiveの違いから整理していきます。
本書の中心は、特定のバックアップ製品の使い方ではありません。Backupを出発点として、Restore、Recoveryへ進みます。
本書では、Backupを主にRestoreやRecoveryに使うデータやシステム状態のコピーとして扱います。交換用機器、代替設備、代替拠点など、より広い復旧資源も実際のRecoveryでは重要になり得ますが、それらの計画全体は本書の主な対象には含めません。対象外とすることは、重要でないという意味ではありません。
Recoveryではさらに、サイバー攻撃によってシステムやデータの信頼性が失われた場合の復旧や、組織として必要な業務を再開するための復旧について考えます。また、Recoveryとは別の目的や要件として、ArchiveやRetentionについても扱います。
本書が扱う範囲を大まかに表すと、次のようになります。
Backup
↓
Restore
↓
Recovery
Recoveryでさらに考えること
├─ Cyber Recovery
└─ Business Recovery
別の目的・要件として
├─ Archive
└─ Retentionこの図は一本道の正式な手順を示すものではありません。本書が扱う範囲を、最初に理解しやすくするための見取り図です。
この本の目的
本書の目的は、「どのバックアップ製品を使えばよいか」を決めることではありません。
また、「何世代残せば安全なのか」という一つの数字を示すことでもありません。
さらに、「この製品をこの通り操作すれば復旧できる」という製品マニュアルでもありません。
本書で考えていくのは、
何を守る必要があるのか。
何が起きたら、それを失うのか。
どの状態まで戻す必要があるのか。
そのために何を残す必要があるのか。
Recoveryに必要なもの自体を、どう守るのか。
そして、本当に戻せることをどう確認するのか。
という問題です。
目標は、
単に、
「バックアップがある状態」
を作ることではありません。
目標は、
想定する損失が発生したときに、必要な状態へ戻れるよう設計することです。
Backupは、そのために必要となる重要な手段の一つです。しかし、Backupだけを考えていてもRecovery設計は完成しません。
Recoveryには、Backupデータだけでなく、復旧に必要な設定や手順、復旧作業を実行できる担当者も関係します。
これからの章では、Backupを取る技術から一歩進んで、組織が必要な状態へ戻るために、何を考え、何を設計し、何を確認しなければならないのかを順番に学んでいきます。Chapter 1は、そのための最初の土台です。
Chapter 1を読み終えた時点で考えてみてください
自分が担当しているシステムについて、次の質問に答えられるでしょうか。
- 何をBackupしていますか。
- そのBackupは何を守るためのものですか。
- 何が起きたときに使う想定ですか。
- どれくらい過去まで戻れますか。
- どのRecovery Pointを選べばよいか判断できますか。
- 実際にRestoreしたことがありますか。
- Restore後にシステムが利用できるところまで確認したことがありますか。
- Backupが利用できなくなった場合、別のRecovery手段はありますか。
すべて答えられなくても問題ありません。むしろ、「バックアップは取っている。でも、この質問には答えられない」ということに気付くことがChapter 1の目的の一つです。その疑問を、これからの章で一つずつ分解していきます。