Snapshot、Backup、Replication、Versioning、Archiveは何が違うか
毎日スナップショットが作られているからといって、別途バックアップが常に要るわけではありません。逆に、毎日あるいはそれより頻繁にスナップショットを作っているからといって、いまの保護体系が十分だとも言えません。判断の基準はスナップショットという名前ではありません。運用データと一緒に消えるのか、同じ管理者権限で全部消せるのか、障害が見つかる前の時点まで履歴が残っているのか、破損していない状態で復元できるのかを見なければなりません。[1]
とくにランサムウェアやCredentialの窃取まで考えるなら、「複製が存在する」と「事故の後も複製を使える」は別の問題です。CISAは、到達できるバックアップもランサムウェアによって削除または暗号化されうることを前提に、オフラインのバックアップと定期的な整合性・復元の検証を併せて勧めます。[2] だから問いを「SnapshotかBackupか」から「どの事故が起きたとき、いまの復旧地点も一緒に失うか」へ変えるほうが良いです。
SNIAの現在の用語定義で見ると、Snapshotは特定時点の複製であり、Backupは失われたり到達できなくなった原本を復旧するために保存するデータであり、Replicationは可用性と冗長性のために複製を継続して維持する構造です。Versioningは複数時点のバージョンを残すことで、Archiveは長期保存に焦点があります。[3]
したがって、AWSがEBS Snapshotを増分バックアップと呼んだり、AzureがSnapshotに基づくDisk Backupを提供したりすることは、用語の誤りではありません。Snapshotという仕組みが実際のBackup Strategyを実装している場合です。ただし同じ製品でも、Snapshotがどの保存領域に置かれるか、誰が削除できるか、どの状態を取得するかは別の問題です。[4]
区分 | 主な目的 | Separation | Control Independence | History / Retention | Immutability | Recoverability | Application Consistency | 運用Owner |
|---|---|---|---|---|---|---|---|---|
| Snapshot | 特定時点への復元・巻き戻し | 実装による | 実装による | 複数のSnapshotを残せば可能 | 別機能である場合がある | Volume・Filesystemの復旧機能に応じて強い | Crash-consistentのこともApplication-consistentのこともある | Snapshotの方針・寿命・復元責任が必要 |
| Backup | 原本の喪失・到達不能時の復旧 | 方針として設計する | 独立させられる | 保存方針が重要な構成要素 | 必要に応じて適用 | 復旧が存在目的 | Backupの方式とアプリケーションによる | 作成だけでなく復元まで責任が必要 |
| Replication | 可用性と冗長性 | 遠隔の対象なら高められる | 構造による | 最新状態が中心。Journal・Delayがあれば変わる | 一般的な中核属性ではない | Failoverには有利 | 複製方式による | 複製遅延・状態・Failoverの責任 |
| Versioning | 以前のバージョンの保存 | 同じ保存先のことがある | 同じ管理Planeであることが多い | 本来の強み | 別の削除保護が要ることがある | ファイル・Object単位の復元に有用 | 複数コンポーネントの整合は別途確認が要る | 保存期間・削除権限の責任 |
| Archive | 長期保存 | 別の階層に置ける | 強く分離できる | 長期保存が本来の目的 | WORMなどと組み合わせ可能 | 復旧はできても即時の運用復元を目標にしない | 保存単位による | 保存・廃棄・アクセス方針のOwnerが必要 |
毎日取るかより先に見る七つ
作成周期より先に見る軸が七つあります。
一つ目はSeparationです。Production Volumeが消えたときSnapshotも消えるかを見ます。物理的に同じディスクにあるCopy-on-write Snapshotと、原本のストレージから分離されたマネージドSnapshotは、同じFailure Modeを持ちません。Snapshotという語だけでこの条件を推し量ってはいけません。実際の保存場所とFailure Domainを確認しなければなりません。
二つ目はControl Independenceです。データとSnapshotが物理的に分かれていても、同じアカウント、同じ管理者Credential、同じ削除権限で一緒に取り除けるなら、Credentialの窃取や内部者の誤りに脆くなります。NIST CP-9には、別途保存だけでなく、バックアップ情報の保護と削除・破棄に対する二重承認のような統制が別項目として置かれています。物理的な分離と管理権限の分離は別の問題だという意味です。[1]
三つ目はHistoryとRetentionです。論理的なデータ破損は発生と同時には見つかりません。月曜にデータが汚染され木曜に見つけたなら、水曜と木曜のSnapshotをどれだけ正常に作っていても、すでに破損した状態です。したがって最後のSnapshotが一つあるという事実より、十分な期間にわたって複数の復旧地点が残っているかが重要です。Versioningもこの領域で意味を持ちます。
四つ目はImmutabilityです。Immutableとは、定めた期間のあいだRecovery Pointを変更したり削除したりできないようにする属性です。AWS Backup Vault LockやAzure Immutable Vaultはこれを実装した例です。一部のサービスは、管理者権限があってもロックされた保存方針を迂回できないよう設計されます。実装とロックの状態によって強度は変わります。[5]
ここで三つの用語を分けなければなりません。ImmutableをOfflineやAir-gappedと同じ言葉として使うと、保護モデルをきちんと説明できません。そしてImmutableだからといってデータが正しいという保証も生まれません。すでに破損したデータを保存すれば、破損した状態がそのまま変更不能に保たれるだけです。整合性検査と実際の復元試験が別に必要な理由です。[1]
五つ目はRecoverabilityです。Backup ConsoleにCompletedと出るのは、作成の処理が終わったという証跡です。復元できるという証跡とは違います。NIST CP-9は、バックアップ情報の信頼性と整合性を試験し、選んだシステム機能をBackupから復元して正常に復旧するかを確認する統制を別に置きます。[1]
六つ目はApplication Consistencyです。稼働中のサーバーでStorage Snapshotを取ると、ディスクに書かれたブロックは捉えても、メモリやOS・アプリケーションのキャッシュに残るデータは取り逃します。AWSの公式文書も、EBS SnapshotにアプリケーションやOSがキャッシュしたデータは含まれないと明記します。[6]AzureとGoogle CloudもCrash-consistent SnapshotとApplication-consistent Snapshotを分けます。とくにDB、複数のVolumeを併用するアプリケーション、ファイルとDBの状態がつながったシステムでは、「Volumeを開ける」と「アプリケーションのデータが一貫している」は同じ言葉ではありません。[4]
七つ目はOwnerです。スケジュールだけあって担当者のいないバックアップは、障害が起きるまでは正常に見えます。誰が失敗したBackup Jobを確認するのか、保存方針を変えるのか、復元を実施するのか、定期検証の結果を承認するのかが決まっていなければなりません。NISTが頻度・保存・試験・削除の統制をそれぞれ組織に定義させる理由も、Backupを単なるStorage機能より運用統制として見るからです。[1]
- Separation
- 原本が消えたとき復旧地点も一緒に消えるかを問う軸です。
- Control Independence
- 同じアカウントと同じ管理者権限で復旧地点まで全部消せるかを問う軸です。
- History / Retention
- 破損を数日後に見つけても、その前の正常な時点が残っているかを問う軸です。
- Immutability
- 定めた保存期間のあいだ、復旧地点の変更と削除を防ぐ属性です。
- Recoverability
- 作成が終わった記録ではなく、実際に取り出して使えるかを問う軸です。
- Application Consistency
- アプリケーションが理解できる状態で取得されたかを問う軸です。
- Owner
- 失敗した処理の確認、保存方針の変更、復元の実施、定期検証の承認を誰が担うかを問う軸です。
概念 | 意味 | 互いに同じでない理由 |
|---|---|---|
| Offline | 平常時の運用ネットワークとシステムから直接到達できない状態 | Offlineの媒体もつなぎ直せば変更できる |
| Immutable | 定めた保存期間のあいだ変更と削除を防ぐ属性 | オンラインのStorageでもImmutableにできる |
| Air-gapped | 運用環境と強い隔離境界を置く構造 | 物理的な切断だけでなく、Vendorがlogical air gapという名でIdentity・Controlの隔離を実装することもある |
監視から復旧・改善までつながる運用 — サービス指標とアラートを基準に対応し、変更履歴と事後報告を次の改善につなげます。
Failure Domainを見ると「別途」の意味が変わる
別途Backupという表現を、必ず別のVendorへもう一つ複製するという意味に読む必要はありません。原本と復旧地点が、Storage、Region、Account、IAM、Credential、KMSのどの領域を共有するかを描いてみると判断が変わります。
同じRegionにあっても、Credentialの窃取やVolumeの喪失に対して十分に独立したBackupはあり得ます。逆に別のRegionへ複製していても、同じ管理者Credential一つで両方を消せるならControl Independenceは低いです。
Region障害まで防ぐべきシステムなら、そのRegionとFailure Domainを共有しない復旧地点が要ります。しかしこの事実を、すべてのシステムがCross-RegionやCross-Vendorでなければならないという規則に変えてはいけません。NISTも、バックアップの頻度や別途保存のような統制を、組織の要求とリスクに合わせて定義させます。Google Cloud Backup Vaultも、同じRegion、別のRegionなど複数の配置方式を提供します。[1]
この記事では同じ理由で3-2-1を合格線として使いません。複製の数を数える前に、その複製が実際に同じ事故で一緒に消えるかを確認するほうが重要です。
Failure Mode × Protection Mechanism Matrix
下の表は製品ごとの保証表ではありません。各仕組みの一般的な性格を置いた出発点であり、実際の結果は保存場所と権限、保存、遅延、不変性、整合性の設定によって変わります。[3]
Replicationはこの表でとくに注意が要ります。正常なデータを速く複製すれば障害時の可用性は上がりますが、誤って削除したデータや論理的に破損したデータも同じだけ速く複製されます。Journalや遅延複製のように過去の状態を別に保存する実装なら性格は変わります。しかし複製があるからバックアップもあると自動的に判断してはいけません。SNIAもReplicationを、継続的なCopyの維持と可用性・冗長性の文脈で定義します。[3]
Failure Mode | Snapshot | Backup | Replication | Versioning | Archive |
|---|---|---|---|---|---|
| 運用者の誤り | ◎ 以前の時点が残っていれば | ◎ | △ 誤りも即座に複製される | ◎ | ○ |
| Credentialの窃取 | △ 同じ権限で削除できれば脆い | ◎ 独立した権限と削除統制があるとき | △ 対象も同じ権限なら脆い | △ バージョン全削除の権限確認が要る | ○ 独立統制のとき |
| Ransomware | △ 到達と削除の可否に左右される | ◎ Offline・Immutable・統制の独立性があれば強い | △ 暗号化されたデータも複製される | ○ 削除保護があるとき | ○ 隔離・保存方針による |
| 論理的なデータ破損 | ◎ 破損前の時点が残っていれば | ◎ | △ 最新状態を複製し続ければ破損も伝わる | ◎ | ○ |
| Storage / Volumeの喪失 | ◎ 原本Storageと独立に保存されていれば | ◎ | ◎ Secondary Copyが生きていれば | △ 同じStorageにしかなければ一緒に失う | ○ |
| Account / 管理Planeの問題 | △ 同じAccountならアクセス自体が塞がれる | ◎ 別の統制境界があるとき | ○ 独立したSecondary管理Planeなら | △ | ○ 独立管理のとき |
| Region / AZの障害 | △ Snapshotの実際の配置による | ○ その障害ドメインと分離されていれば | ◎ 遠隔複製なら | △ | ○ 保存場所による |
| Backup自体の破損 | ○ 独立した別のRecovery Pointなら | △ Backupという名前だけでは解決しない | △ | ○ 別の時点が正常なら | ○ 独立したCopyなら |
| Application Inconsistency | △ Application-aware Snapshotが要る | ○ 一貫したBackup方式のとき | △ Replicationの方式による | △ 単一ファイル・Objectのバージョンだけでは足りない | △ 保存単位による |
サービス構成から運用基準まで — ネットワークとサーバーを設計し、デプロイ経路、アクセス権限、バックアップ基準を整えます。
実際の復元は五段階で証跡が強くなる
Backupがきちんと作られたかを確かめるとき、最も弱い証跡は一覧を見ることです。NISTは一歩進んで、Backup Mediaの信頼性と情報の整合性を確認し、Sample Backupを実際の復元試験に使うよう求めます。これをアプリケーション運用の観点へ広げると、五段階のRestore Evidence Ladderになります。[1]
1段階から4段階までは、NISTのBackupの信頼性・整合性の確認と、選ばれたシステム機能の復元試験を実務の流れに解いたものです。5段階の中核の利用者ジャーニーはNISTの文言をそのまま移したものではなく、システム機能の復旧を利用者から見た結果まで確認するための、この記事の運用上の拡張です。特定のSLIや目標時間まで定めるのはこの記事の範囲ではありません。[1]
このLadderの目的は、毎回Production全体を複製して巨大なDR訓練をしようという話ではありません。Backupの一覧確認だけをしてきた組織と、復元したサービスで実際の作業ができるか確かめた組織とでは証跡の水準が違う、という事実を示すためにあります。
Level | 確認すること | 何を証明するか | まだ証明できないこと |
|---|---|---|---|
| 1. Backupの一覧とメタデータ確認 | Recovery Pointの時刻、状態、サイズ、Retention、暗号鍵と方針 | BackupのジョブとRecovery Pointが記録上存在する | データを実際に読めるか |
| 2. 標本ファイルの復元 | 任意のファイル・Object・Volumeの一部を別の場所へRestore | データの取得、権限・暗号鍵・基本のRestore経路が動く | DBとアプリケーション全体の整合 |
| 3. DBの整合性検証 | DBエンジンに合ったIntegrity Check、Transaction・Index・関係の検証 | アプリケーションのデータストアが使える状態である | サービス全体が実際に起動するか |
| 4. アプリケーションの起動 | 隔離した環境で設定・Secret・Dependencyとともに実行 | 選んだシステム機能を復旧できる | 利用者が重要な業務を終えられるか |
| 5. 中核の利用者ジャーニー検証 | ログイン・照会・登録・処理など代表的な流れを実行 | 復元したデータとアプリケーションがEnd-to-Endで使える状態である | すべての機能とすべての障害状況 |
自分のSnapshot方針が十分かを見る方法
毎日Snapshotが作られているなら、新しい製品を探す前に、いまの方針へ七つの問いを投げます。Production Storageが失われてもRecovery Pointは残るか。Production管理者のCredentialを窃取されたとき、Recovery Pointまで全部消せるか。破損を数日後に見つけても、その前の正常な時点が残っているか。必要なRecovery Pointに削除・変更の防止統制があるか。DBとアプリケーションが理解できる一貫した状態で取得されているか。最近のRecovery Pointを実際に復元してみたことがあるか。Backupの失敗とRestore Testに責任を持つ人が決まっているか。
ここですべて満たすなら、Snapshotだから別途Backupをもう一つ買うべきだという結論を自動的に出す理由はありません。そのSnapshot体系そのものが相当なBackup機能を担っています。逆に複数の項目で答えが曖昧なら、問題はSnapshotの作成頻度ではありません。いまのRecovery Pointが原本の失敗からどれだけ独立しているかが証明されていない、ということです。
復旧の戦略は名前より失敗条件で評価するほうが安全です。Snapshotは実装と運用の仕方によって、優れたBackup Strategyの一部になります。ただしその価値は「毎日作成」という設定画面ではなく、原本との分離、統制の独立性、保存の履歴、不変性、アプリケーションの整合性、そして実際のRestore Evidenceで判断しなければなりません。
