はじめに

「バックアップは取れています」と自信を持って言えるシステムはたくさんあります。しかし「リストアできます」と言い切れるシステムは、驚くほど少ないのではないでしょうか。

本書『データ保護完全ガイド ―あらゆるデータの保全と回復を可能にする』は、この一点を約400ページかけて執拗に問い直してくる本です。著者は「Mr. Backup」の異名を持つ W. Curtis Preston 氏。1993年からデータ保護一筋というキャリアの持ち主で、本書は氏が「10年以上前から書きたかった」と語る集大成にあたります。

読み終えたあとに残るのは個別の製品知識ではなく、「自分たちが守ろうとしているものは何で、どこまで壊れることを許容するのか」を決めないまま技術選定に入ることの危うさ、という設計上の教訓です。

この記事では、設計・アーキテクチャに関心のあるエンジニア向けに、本書の骨格と特に示唆に富んだ論点を整理してご紹介します。

書誌情報

項目	内容
邦題	データ保護完全ガイド ―あらゆるデータの保全と回復を可能にする
原題	Modern Data Protection: Ensuring Recoverability of All Modern Workloads
著者	W. Curtis Preston
監訳	佐野泰之
訳者	池田祥孝
出版社	オライリー・ジャパン
発行	2023年12月（原書は O'Reilly Media より2021年4月）
ISBN	978-4-8144-0055-3

著者は現職としてデータ保護サービス（DPaaS）ベンダに所属していますが、本文中で特定製品名をほぼ挙げないという方針を貫いています。
30年のキャリアのうちベンダ勤務は今回が初めてであり、だからこそ競合製品も同じだけ知っている、という自己申告どおり、記述は終始フラットです。

本書の全体像

全16章は、大きく4つのブロックに分かれています。

ブロック	章	内容
なぜ・何を守るのか	1〜3章	データへのリスク／SLAを決めるまでにすべきこと／バックアップとアーカイブは全く別物
基本概念とデータソース	4〜8章	バックアップとリカバリの基本／ディスクと重複排除／従来型データソース／データベース／最新のデータソース
方式論	9〜11章	バックアップとリカバリの方法／アーカイブの方法／ディザスタリカバリの方法
製品と選定	12〜16章	データ保護ターゲット／商用製品の課題／従来型ソリューション／最新ソリューション／リプレースまたはアップグレード

「要件定義 → 概念整理 → ワークロード別の実装 → 方式の比較 → 製品カテゴリの選定」という流れになっており、章の順番そのものが著者の主張になっています。
最終章で著者は「16章だけ読みに来た人は、まず前の章に戻ってほしい」と釘を刺しています。

設計者として刺さった論点

1. 「バックアップの成功」は指標ではない

本書を貫くテーゼは冒頭から明示されます。

誰もバックアップできていることなど気にしない

気にされるのは、リストアできるかどうかだけである、と。

これは単なる標語ではなく、章立て全体の設計思想になっています。
バックアップジョブの成功率は運用の健全性指標ではあっても、システムの価値を測る指標ではありません。
測るべきは「どれだけ速く戻せるか」と「どれだけデータを失うか」の2つだけだ、というのが著者の立場です。

著者自身が、キャリア2ヶ月目にOracleのバックアップ設定漏れで6週間分の発注データを失いかけたエピソードを1章の冒頭に置いています。
バックアップの本を、著者の失敗談から始める。この構成自体がメッセージになっています。

2. 3-2-1ルールを設計の検算式として使う

著者は3-2-1ルールを「バックアップ設計における E=mc²」と表現します。データのバージョンを 3つ以上持ち、2種類 以上の異なるメディアに保存し、そのうち 1つは別の場所に置く。

面白いのは、これを「守るべき規範」ではなく「設計の妥当性を検算するための式」として使う点です。設計に迷ったら3-2-1に照らしてみる、という使い方が全章を通じて繰り返されます。

この検算を通すと、普段バックアップと呼んでいるものの多くが脱落します。

同一ディスク上の別パーティションへのコピー → メディアが同じなので不可
ファイルシステムやハイパーバイザのスナップショット → オリジナルに依存する「仮想コピー」であってコピーですらない
SaaSのバージョン履歴やごみ箱 → 保護対象と同じシステム上にあるので不可
同一クラウドアカウント・同一リージョン内のバックアップ → 「離れた場所」の要件を満たさない

最後の項目については、2014年に消滅した codespaces.com の事例が引かれています。3重冗長と多数のバックアップを備えながら、すべてが同一アカウント・同一リージョンにあったため、特権アカウントを奪われた時点で全滅しました。

冗長化は「ハードウェア障害」しか守ってくれません。RAIDもレプリケーションもマルチAZも、DROP TABLE の打ち間違いと暗号化には無力です。著者は「レプリケーションはエラーを直さない、エラーの伝播効率を上げるだけだ」と皮肉っています。

3. バックアップとアーカイブは、目的が違う別のシステム

3章はほぼ丸ごとこの主張に費やされています。著者はここでかなり厳格な線引きをします。

	バックアップ	アーカイブ
目的	オリジナルを直前の正常な状態に戻す	参照用の資料として引き出す
操作	リストア（Restore）	リトリーブ（Retrieve）
必要な情報	サーバ名・パス・日付（単一時点）	内容とメタデータ（期間範囲）
典型的な問い	「昨日の時点のこのファイルを戻して」	「過去3年でこの語を含むメールを全部出して」

重要なのは、保存期間ではなく「なぜ・どのように保存したか」が両者を分けるという点です。古いバックアップが時間の経過で自動的にアーカイブに変わることはありません。著者はこれを「グレープジュースは放っておいてもワインにならない」と表現しています。

この区別を曖昧にした代償として、実例が紹介されています。メールアーカイブを持たない企業が3年分のe-discovery請求を受け、週次のExchangeバックアップから155回のリストアを繰り返す羽目になり、コンサルティング費用だけで200万ドルを費やしたという話です。

アーカイブシステムなら1クエリで済んだものが、バックアップシステムしかないと156週分の総当たりになる。検索用インデックスを持たないデータストアに全文検索をさせるのと同じ構図で、エンジニアには直感的に理解しやすい失敗例だと思います。

4. RTO/RPO と RTA/RPA を分けて測る

4章の指標の議論は、SLOの設計に慣れた方ほど頷ける内容です。

RTO（目標復旧時間） … 合意された、復旧までの許容時間
RPO（目標復旧時点） … 合意された、許容データ損失量（時間で表現）
RTA（復旧時間実績） … 実際に測定された復旧時間
RPA（復旧点実績） … 実際に測定されたデータ損失量

著者が繰り返し指摘するのは、多くの組織でRTAとRPAがRTO/RPOから大きく乖離しており、しかもそれが測定されていないという点です。目標だけが立派で実績が測られていない状態は、SLOを定義してSLIを計測していないのと同じことです。

RTOの計測範囲についての注意も実務的です。RTOはインシデント発生時点から業務が正常化するまでの時間であり、データ転送時間はその一部でしかありません。機材の調達、契約の調整、アプリケーションの再起動と検証、これらすべてが含まれます。

テクニカルエディターによる補足として、RPOを3で割った頻度でバックアップを回すという経験則も紹介されています。バックアップは現実に失敗するので、2回連続で失敗してもRPOを割らないようにするための余裕、という考え方です。

5. 「バックアップ不要」の俗説を1つずつ潰す

4章後半の俗説リストは、設計レビューのチェックリストとしてそのまま使えます。

RAIDがあるから不要 … RAIDはボリュームを守りますが、その上のファイルシステムは守りません。削除・暗号化・論理破壊には無力です。
レプリケーションしているから不要 … レプリケーションは「起きたこと」を忠実に複製します。良いことも悪いことも等しく伝播します。
IaaS/PaaSはクラウド側が取ってくれる … バックアップ「できる仕組み」は提供されますが、代わりに取ってくれるベンダはありません。
SaaSは不要 … 著者がここが最も誤解されていると指摘する点です。主要SaaSのサービス契約書でバックアップ・リカバリ・リストアという語を探してみてほしい、と。あるのはバージョン管理とごみ箱であって、3-2-1を満たすバックアップではありません。
バックアップは何年も保存すべき … リトリーブできない仕組みで長期保存すると、法的開示要求が来たときに前述の200万ドル案件になります。著者の推奨は18ヶ月程度です。
テープは死んだ … これについては後述します。

6. 不変性（Immutability）とエアギャップ

ランサムウェアの登場がこの分野の優先順位を根本から書き換えた、という主張が本書の通奏低音になっています。

不変性についての指摘で最も鋭いのは、保管期間を後から短縮できる製品は不変ではないという一点です。攻撃者がバックアップ管理者権限を奪ったとき、データを削除できなくても保管期間を0日に変更できれば結果は同じです。「不変性対応」を謳う製品には、管理者が保管期間を短縮できるかを必ず確認せよ、という実践的な問いが提示されています。

仮想エアギャップの具体策も列挙されています。

バックアップサーバのRDPを無効化する、あるいはVPN経由のみに限定する
バックアップサーバに本番と異なるOSを使う（本番がWindows中心ならバックアップはLinux）
ターゲットストレージをOSのマウントポイントとして直接見せない
ファイルシステムではなくオブジェクトストレージのプロトコルを使う
クラウドの不変ストレージを併用する
テープを使う（物理的な距離に勝るエアギャップはない）

多要素認証を超えた「多人数認証」の提案も印象的でした。リストア、バックアップポリシーの変更、保管期間の短縮といった破壊的操作に2人の承認を要求するという考え方です。コードレビューの必須承認者数と同じ発想で、権限の集中を運用で薄める設計です。

7. 重複排除：ソース側かターゲット側か

5章は重複排除の解説に多くのページを割いています。仕組み自体はエンジニアには馴染みやすく、データをチャンクに切り、暗号学的ハッシュを計算し、ハッシュテーブルを引いて既出なら参照だけ増やし、未知なら圧縮して書き込む、という流れです。コンテンツアドレスによる同一性判定なので、Gitのオブジェクトストアを知っていればすぐ理解できます。

設計上の分かれ目は、重複排除をどこで行うかです。

	ターゲット重複排除	ソース重複排除
実行場所	バックアップ先のアプライアンス	バックアップ元のクライアント
導入	既存システムに追加できる（進化的）	システム全体の入れ替えが前提（革命的）
ネットワーク	フルバックアップが丸ごと流れる	固有チャンクのみ流れる
クライアント負荷	ほぼなし	チャンク化とハッシュ計算の分だけ増える
適する場面	既存資産を活かしたい	リモート拠点、帯域が細い環境

もう一つ重要なのが重複排除のスコープです。バックアップセット単位、ホスト単位、アプライアンス単位、サイト単位、グローバルと段階があり、下に行くほど重複を多く見つけられますが必要リソースも増えます。ハッシュテーブルが大きくなりすぎるとルックアップが遅くなるため、多くの製品はスコープに上限を設けています。

暗号化と重複排除の順序についての注意も実務的です。バックアップソフト側で暗号化してから重複排除アプライアンスに送ると、重複排除率は1:1になります。順序を間違えると効果がゼロになる、という分かりやすい落とし穴です。

8. データベース保護と整合性モデル

7章は、アプリケーション寄りのエンジニアにとって最も実用的な章かもしれません。バックアップ方式が整合性モデルによって決まる、という整理が明快です。

即時整合性（強整合性） … 従来型RDBMS。単一ストレージ共有かシェアードナッシングのクラスタ構成
結果整合性 … 多数ノードにシャーディングされ、レプリカ数は通常3
ハイブリッド整合性 … NoSQL系。読み取り時にAPIで整合性レベルを指定できる

結果整合性のマルチノードDBでは、ノードを1台ずつバックアップすると参照整合性が壊れるという指摘が重要です。リストア後にクラスタ全体が整合するまで数日かかったという実例も挙げられています。全ノードのスナップショットを同時に取ってからまとめて退避する、というのが定石です。

従来型DBのバックアップ方式は次のように整理されています。

方式	概要	主な注意点
コールドバックアップ	DBを停止してデータファイルを取得	最も安全だが運用上の制約が大きい
レプリカ分割	レプリカを切り離してから取得	実質コールドだが本体は稼働できる
ホットバックアップモード	稼働中にモード切替して取得	Oracleの `alter database begin backup` が代表
スナップ＆スイープ	DB連携のスナップショットを取ってから退避	FSスナップショット単体では不十分
ダンプ＆スイープ	ダンプ出力をファイルとして退避	最も一般的。ただしスクリプト品質に依存
ストリーム・トゥ・バックアップ	バックアップ製品へ直接ストリーム	エラー処理を製品任せにできるが導入障壁が高い

ダンプ＆スイープについての警告が現場的です。自作スクリプトはエラー処理が手薄になりがちで、ダンプが失敗しているのにファイルシステムのバックアップだけが成功し、全体としては成功に見えるという状態が生まれます。スケジューラの設定ミスで一度も動いていなければ、エラーすら出ません。また、常に完全な世代が1つ残るよう、バックアップ2世代分のストレージを確保することが推奨されています。

主要DBごとの推奨方式（Oracle の RMAN、SQL Server と DB2 の backup database、PostgreSQL の pg_dump + WAL、MongoDB Atlas の継続的バックアップ、Cassandra の nodetool snapshot、DynamoDB の PITR）も一覧で整理されており、リファレンスとして手元に置く価値があります。

9. ディザスタリカバリはランサムウェアで最優先事項になった

11章がおそらく本書で最もページ数の多い章です。論点はシンプルで、ハリケーンでデータセンターが消えた場合は物理的な再建に時間がかかることを誰もが理解しますが、ランサムウェアの場合は物理的に何も壊れていないため、同情はされず「早く戻せ」と言われるだけです。その圧力が、身代金の支払いという選択肢を魅力的に見せてしまいます。だからこそ短いRTAを実現するDRプランが必要になる、という展開です。

リカバリサイトの選択肢は3つに整理されます。

自社構築 … 環境コストが最低でも2倍。最新のDR技術を活かしにくい
リカバリサイト・アズ・ア・サービス … 専有型は高価、共有型は広域災害時に「取り付け騒ぎ」のリスク
パブリッククラウド … 平時はストレージ費用のみ、発動時にコンピュートを確保

著者はクラウドを明確に推しています。1PB・1000VMの環境なら、平時はレプリケートされた1PBのストレージだけ払い、1000VM分は災害宣言まで払わない、という経済性が理由です。

サイトの温度についても整理されています。

	事前リストア	RTA/RPA	コスト
コールドサイト	なし	長い	最安
ウォームサイト	あり（電源は落とす）	中程度	バランス型
ホットサイト	あり（常時稼働・同期）	ほぼゼロ	最高

大半の組織にはウォームサイトが妥当、というのが著者の見解です。災害後に直近のインクリメンタルだけを追加適用してRPOに滑り込ませる、という運用がコストと速度の折り合いをつけます。

10. DR手順書は「担当者が全員いない前提」で書く

11章後半のDR手順書（runbook）論は、ドキュメント設計論として読めます。

合格基準は明快です。DRプランを知っている人が誰もいない状況で、ITが分かる人間が最初から最後まで実行できること。
満たすべき性質として、正式版であること・正確であること・アクセス可能であること・組織に浸透していること・常に更新されていること・適応可能であること・監査可能であること・テスト済みであることが挙げられています。

特に最後の点が重要で、著者は「テストされていない手順書は理論に過ぎない」と切り捨てます。
しかもテストはDR担当者ではなく、普段その作業をしないITジェネラリストにやらせるべきだ、と。
質問が出た箇所はすべて手順書の記述不足のサインとしてメモを取れ、という指針は、そのままオンボーディングドキュメントの検証方法として使えます。

11. テープは死んでいない（ただし用途は変わった）

12章のテープに関する記述は、本書で最も意外性のある部分でした。著者の主張は「テープは遅くも脆くもない、むしろ速すぎる」というものです。毎秒数十MBのバックアップストリームで毎秒1GB級のテープドライブを満足させられるはずがなく、往復動作による摩耗と失敗がテープの信頼性が低いという誤解を生んできた、という説明です。

データで示される部分も説得力があります。

メディア	UBER（未修正ビットエラー率）
光メディア	10⁻⁸ 〜 10⁻¹²
SATAディスク	10⁻¹⁴
エンタープライズディスク	10⁻¹⁵
エンタープライズSSD	10⁻¹⁶
LTO-8	10⁻¹⁹

LTO-8はSATAディスクより5桁、つまり1万倍もビットを正しく書けるという主張です。長期保存についても、磁性粒子の体積と媒体温度から導かれる物理的な議論として、テープが30年、通電中のディスクが5年という数字が示されます。電力面でも、スロットに収まったテープは電力を消費しないのでコピーを20本作っても消費電力は増えませんが、ディスクは2本作れば2倍かかります。

結論として著者が推すのは、テープをプライマリターゲットではなく長期アーカイブの保管先として使うという位置づけです。インクリメンタルを直接テープに流すのはトラブルの元だが、数TBのアーカイブをディスクからストリーミングするなら理想的だ、と。カリブ海の島のデータセンターがハリケーンに襲われ、最後に残ったのがテープだった、というエピソードで章は締めくくられます。

12. 製品カテゴリの地図

14〜16章は製品カテゴリの整理と選定基準です。著者は特定製品名を挙げず、カテゴリごとの構造的な長所と短所を論じます。

カテゴリ	向いている環境
従来型バックアップ	レガシーUnix、旧DB、仮想化、IaaS、Kubernetesが混在する環境
ターゲット重複排除	既存システムを活かしつつオフサイト複製を実現したい
仮想化セントリック	Windows中心・仮想化中心の環境
HCBA（ハイパーコンバージド）	オンプレでスケールアウトしたい、初期投資を抑えたい
DPaaS	オンプレの設計・保守・拡張を一切やりたくない
フルマネージドMSP	運用ごと委託したい

選定の考え方として、著者は「島の例え」を出します。目標は「1日1000台の車を島に出入りさせること」であって、「橋を作ること」ではありません。橋を指定して入札をかけると、優れたトンネルや安価なフェリーを見逃します。要件を伝えて解決策を提案させろ、という調達論です。アーキテクチャ選定一般に通じる話だと思います。

責任分界点の整理も実務的です。ハードウェア／ソフトウェア／設定／監視／運用という5つのタスクについて、どこまでが自社でどこからがベンダかを事前に確認せよ、と。DPaaSではハードウェアとソフトウェアがベンダ側に移りますが、設定・運用・監視は依然として自社の責任です。ここを誤解したまま導入すると事故になります。

気になった点

網羅性を優先した結果、個々のテーマの掘り下げは浅くなっています。
著者自身も「各章で1冊書けた」「素案を見たオライリーのスタッフに2000ページになると言われた」と認めているとおりで、特定製品やワークロードの実装詳細を求めて読むと物足りなく感じるはずです。

また自然災害の例がほぼ米国のものに限られており（竜巻街道、シンクホールなど）、日本の読者にはやや遠い話に感じられます。とはいえ地震・台風・水害という論点自体はそのまま当てはまるので、読み替えの負担は大きくありません。

ユーモアと皮肉の多い文体なので、淡々とした技術書を好む方には賑やかに映るかもしれません。逆に言えば、この分野の教科書としては異例に読みやすい部類です。

どんな人におすすめか

おすすめできる方

バックアップは動いているが、リストアを一度もテストしたことがない方
RTO/RPOという言葉は知っているが、自社の実績値を測ったことがない方
SaaSやマネージドサービスのデータ保護責任がどこにあるか整理したい方
DR計画をゼロから設計する立場にある方
設計判断の根拠を、製品カタログではなく原理から説明できるようになりたい方

あまり向かない方

特定製品の設定手順やコマンドリファレンスを求めている方
単一ワークロードの深掘りだけが目的の方

まとめ

本書から持ち帰るべきものを3つに絞るなら、次のようになると思います。

測るべき指標はリストアの速度と損失量だけ。 バックアップの成功率は健全性の目安であって、価値の指標ではありません。
3-2-1ルールを検算式として使う。 設計に迷ったら、3つのバージョン・2種類のメディア・1つの別拠点、という式に自分の構成を通してみる。
バックアップとアーカイブを混ぜない。 リストアとリトリーブは目的も検索キーも違う操作であり、片方の道具で両方をやろうとすると必ず高くつきます。

そして最後に、どのデータを守るべきか迷ったときの2つの問いです。

そのデータは組織にとって価値があるか
そのデータは既に3-2-1準拠の方法でバックアップされているか

この2つに答えられれば、あとは方式の選択の問題になります。逆にこの2つを飛ばして製品比較から始めると、本書が13章で列挙している「商用データ保護製品の課題」をそのまま抱え込むことになります。

バックアップは、平時には誰からも評価されない領域です。しかし一度事故が起きれば、その設計品質がそのまま組織の生存確率になります。その設計を根拠を持って語れるようになりたい方に、本書は十分な材料を提供してくれます。

参考

W. Curtis Preston『データ保護完全ガイド ―あらゆるデータの保全と回復を可能にする』佐野泰之監訳／池田祥孝訳、オライリー・ジャパン、2023年
原書：Modern Data Protection: Ensuring Recoverability of All Modern Workloads, O'Reilly Media, 2021