1. はじめに
要件に「バックアップは3-2-1ルールに準拠すること」と書かれているケースが増えています。
しかし、3-2-1ルールはもともと物理媒体を前提にした経験則のため、クラウドにそのまま当てはめると解釈が分かれます。
本記事では、提案書に記載することを想定して、次の流れで整理します。
- 3-2-1ルールは何のためにあるのか（どのようなデータ損失に備えるルールなのか）
- 要件としての3-2-1を、AWSでどう実現するか
2. 3-2-1ルールは何のためにあるのか
2.1 ルールの概要
3-2-1ルールは、写真家のピーター・クロー氏が2005年の著書『The DAM Book』で紹介した、バックアップの経験則です。国際規格や法令ではありません。
| 数字 | 内容 |
|---|---|
| 3 | データのコピーを3つ持つ（本番データ＋バックアップ2つ） |
| 2 | 2種類の異なる媒体に保存する |
| 1 | 1つは別の場所（オフサイト）に保管する |
2.2 データ損失の原因の分類
データ損失の原因は、大きく次の2つに分けられます。
| 分類 | 内容 | 例 |
|---|---|---|
| 物理障害 | 機器・設備・拠点の障害により、データにアクセスできなくなる、またはデータが失われる | ディスク故障、ストレージ装置の障害、AZ障害、リージョン障害、自然災害 |
| 論理障害 | 機器は正常だが、データそのものが誤った状態になる | 誤削除・誤更新、アプリのバグによるデータ破損、ランサムウェアによる暗号化 |
2.3 3-2-1ルールの本質は「物理障害で、すべてのコピーを失わないこと」
3-2-1ルールの各数字は、主に物理障害に備えるためのものです。
| 数字 | 備える物理障害 | 考え方 |
|---|---|---|
| 3 | 単一のコピーの故障 | コピーが1つ壊れても、ほかのコピーから戻せる |
| 2 | 媒体・装置の障害 | 本番と同じ装置の障害で、バックアップも一緒に失われないようにする |
| 1 | 災害・拠点障害 | 拠点ごと失われても、離れた場所のコピーから戻せる |
つまり、3-2-1ルールの本質は、1つの原因で、すべてのコピーが同時に失われないようにすることです。
2.4 3-2-1ルールだけではカバーしきれない原因
一方で、論理障害や、セキュリティ・運用面の原因には、3-2-1ルールだけでは十分に備えられません。
| 損失の原因 | 分類 | 例 | 3-2-1での扱い |
|---|---|---|---|
| 論理障害 | 論理障害 | 誤削除、誤更新、アプリのバグ | 保持期間について明示されていない |
| 悪意ある削除・改ざん | セキュリティ | ランサムウェア、認証情報の漏洩、内部不正 | 明示されていない |
| バックアップ自体の不備 | 運用 | 取得失敗、戻せないバックアップ | 明示されていない |
要件として3-2-1ルールが求められている場合でも、これらの原因への備えが必要かどうかは、別途お客様と確認しておくことをおすすめします。
3. クラウドにおける3-2-1ルールの解釈
物理媒体を前提としたルールのため、クラウドでは次のように読み替えます。
| 元のルール | クラウドでの解釈 |
|---|---|
| 3つのコピー | 本番データ＋バックアップ＋そのコピー |
| 2種類の媒体 | 本番のストレージとは独立した保存先（バックアップ専用のストレージ） |
| 1つはオフサイト | 別リージョン |
4. 要件としての3-2-1をAWSで実現する
4.1 構成概要
東京リージョン（ap-northeast-1）の本番環境を、大阪リージョン（ap-northeast-3）で保護する構成です。
[東京リージョン]
本番データ（EC2/EBS、RDS/Aurora、DynamoDB、EFS、S3 など） ← コピー①
│ AWS Backup（バックアッププランによる自動取得）
▼
バックアップボールト ← コピー②（別の保存先）
│ クロスリージョンコピー
▼
[大阪リージョン]
バックアップボールト ← コピー③（オフサイト）
4.2 各要件への対応
| 要件 | 実現方法 | 利用サービス・機能 |
|---|---|---|
| 3つのコピー | 本番データ、東京のバックアップ、大阪へのコピーの3つを保持 | AWS Backup |
| 2種類の媒体 | 本番のストレージ（EBS、RDSのストレージなど）とは独立したAWS Backupのボールトに保存 | AWS Backup ボールト |
| 1つはオフサイト | バックアッププランのコピー設定で、大阪リージョンへ自動コピー | クロスリージョンコピー |
AWS Backupを使うことで、複数のサービスのバックアップを1つのバックアッププランで一元管理できます。バックアップ対象はタグで指定するため、リソースを追加した際の設定漏れも防げます。
4.3 「スナップショットやレプリカだけでは不十分」「永久増分・重複排除」への対応
バックアップの要件として、スナップショットやレプリカとの違いや、永久増分・重複排除の活用が求められることがあります。こうした要件は、オンプレミスのバックアップ製品を前提にしている場合が多く、クラウドでは解釈を補って説明する必要があります。
「スナップショットやレプリカだけでは不十分」の意図
AWS Backupでも、EBSやRDSのバックアップの実体はスナップショットです。そのため、文面どおりに読むと「スナップショットを使う提案は要件を満たさない」と受け取られるおそれがあります。
しかし、この要件の意図は、スナップショットという技術を否定することではなく、次のような懸念にあると考えられます。
| コピーの種類 | 懸念 |
|---|---|
| レプリカ | 誤削除や破損したデータも、そのまま複製先に反映される |
| 個別に取得したスナップショット | 取得や削除が手作業や個別の設定に依存し、世代管理や保持のルールが担保されない |
本記事の構成では、AWS Backupのバックアッププランにより、取得・保持・別リージョンへの複製をポリシーに基づいて一元的に管理します。提案書では、個別のスナップショットではなく、ポリシーに基づいて管理されたバックアップであることを明確に説明することが重要です。
永久増分
AWSの多くのサービスでは、バックアップが永久増分方式で取得されます。
| サービス | 方式 |
|---|---|
| EBS（EC2） | 初回はフル、以降は変更されたブロックのみを保存 |
| RDS | 初回はフル、以降は増分 |
| EFS、S3（AWS Backup） | 初回はフル、以降は増分 |
DynamoDBのように、毎回フルで取得するサービスもあります。また、クロスリージョンのコピーが増分になるかどうかは、リソースの種類や暗号化キーの設定によって異なります。提案するシステムのリソースごとに、公式ドキュメントで確認してください。
重複排除
AWS Backupは、専用のバックアップ製品のような「重複排除機能」を明示的に提供しているわけではありません。ただし、ブロック単位の永久増分により、同じリソースの世代間で変更のないデータは重複して保存されないため、保存容量とコストの削減という点で、重複排除と同等の効果が得られます。
4.5 S3のデータをバックアップする場合の「2種類の媒体」の考え方
S3のデータをAWS Backupでバックアップする場合、「バックアップの保存先も結局はAWSのストレージ基盤であり、同じ媒体ではないか」と指摘されることがあります。実際、EBSスナップショットがS3に保存されるように、AWS Backupのバックアップデータも、利用者からは見えないAWS管理のストレージ基盤に保存されます。
この指摘に対しては、「2種類の媒体」の目的（2.3）に立ち返って説明します。
| 観点 | 説明 |
|---|---|
| 媒体・装置の障害 | S3（One Zone系のストレージクラスを除く）は、複数のAZにデータを冗長化して保存します。個々のディスクや装置の障害はサービス側で吸収されるため、物理的な装置の違いを利用者側で確保する必要性は、オンプレミスより低くなります。 |
| 管理・操作の独立性 | バックアップデータは、元のバケットとは別のリソース（バックアップボールト）として管理されます。バケットの削除や、誤ったライフサイクルルール・バケットポリシーの設定など、元のバケットに対する操作の影響を受けません。 |
| 拠点の独立性 | 物理的な基盤まで分離する必要がある場合は、クロスリージョンコピーにより、別リージョンのストレージ基盤にもコピーを保持します。 |
つまりS3については、「2」で物理的な基盤の違いを主張するのではなく、「2」は管理・操作の独立性として説明し、物理的な分離は「1」（別リージョン）で担保するという整理が妥当です。
5. 設計時の注意点
- 暗号化キーを保護しましょう。 KMSキーが削除されたり、キーポリシーでアクセスできなくなったりすると、バックアップを復元できません。クロスリージョンコピーでは、コピー先リージョンのキーの設定も必要です。
- サービスごとの対応状況を確認しましょう。 クロスリージョンコピーへの対応や、増分バックアップかどうかは、リソースの種類やリージョンによって異なります。公式ドキュメントの「Feature availability」や各サービスのバックアップの仕様を必ず確認してください。
- コストを見積もりましょう。 コピーごとにストレージ費用とリージョン間のデータ転送費用が発生します。保持期間と取得頻度は、RPO・RTOや保持期間の要件から逆算して決めましょう。
6. まとめ
- データ損失の原因は、物理障害と論理障害に大きく分けられます。
- 3-2-1ルールの本質は、物理障害によって、すべてのコピーが同時に失われないようにすることです。
- AWS Backupのバックアッププランとクロスリージョンコピーで、要件としての3-2-1を満たせます。
- 「スナップショットやレプリカだけでは不十分」「永久増分・重複排除」といった要件にも、ポリシーに基づく一元管理と永久増分方式の説明で対応できます。
- S3のバックアップでは、「2」を管理・操作の独立性として説明し、物理的な分離は別リージョンへのコピーで担保します。
さいごに
本記事の内容は執筆時点の情報に基づいており、正確性・完全性を保証するものではありません。実際の構築・運用はご自身の責任のもとで行ってください。
最後まで読んでいただきありがとうございました。