バックアップ・スナップショット・レプリケーションの違いとは？クラウド障害対策に必要な3つのデータ保護手法を整理する

「バックアップを取ってあるから大丈夫」と言いながら、実はスナップショットしか取っていないケースがある。あるいは「マルチAZで冗長化しているからデータは守られる」と思っていると、ランサムウェア侵害や誤オペレーションで詰む。この記事では、バックアップ・スナップショット・レプリケーションの本質的な違いを整理し、AWSとAzureの具体的なサービスと対応させながら解説する。「どの障害シナリオに何を使うべきか」を判断できるようになることがゴールだ。

なぜこの3つを区別しなければならないのか

オンプレ時代は「テープバックアップを週次で取る」「ディスクをRAIDで組む」「DR用のホットスタンバイを1台用意する」という構成で、役割が比較的明確だった。クラウドに移行すると、サービスの種類が増えて「どれが何の障害に対応しているのか」が見えにくくなる。

最初に一言で整理する：
・バックアップ: 論理的な破壊（削除・改竄・ランサムウェア）から復元する
・スナップショット: ある時点のディスク・DB状態を丸ごと保存し、短時間で巻き戻す
・レプリケーション: ハードウェア・AZ障害への自動フェイルオーバーに対応する

この3つはそれぞれ異なる障害シナリオへの対策であり、どれか1つで他を代替できる場面は限られている。

バックアップとは何か

1. バックアップが対処できる障害と限界

バックアップは「論理的なデータ損失」への最後の防衛線だ。テーブルを誤ってDROPしたとき、ランサムウェアでデータが暗号化されたとき、アプリのバグで大量のレコードが書き換わったとき——こういった場面ではレプリケーションは役に立たない。変更が即座に複製先にも伝わってしまうからだ。

バックアップの特徴は以下のとおり：
・独立した保管場所: バックアップ先をイミュータブル（書き換え不能）に設定することで、マルウェアによる破壊を防げる
・ポイントインタイムリカバリ（PITR）: 「1週間前の状態に戻す」など過去任意の時点への復元が可能
・RPOが数時間単位: バックアップ間隔（1日1回など）がRPOに直結するため、ミッションクリティカルな用途では他の手法との組み合わせが必要

2. AWSのバックアップ：AWS Backup

AWS Backupは、Amazon EC2・Amazon RDS・Amazon EFS・Amazon DynamoDB・Amazon EBS など複数サービスのバックアップを一元管理するマネージドサービスだ。オンプレでいう「NetBackup」や「Veeam」に相当するが、エージェントのインストールは不要で、ポリシーベースでスケジュール・保持期間を管理できる。

バックアッププランの作成例（AWS CLI）：

# バックアッププランの作成（日次・90日保持）
aws backup create-backup-plan \
  --backup-plan '{
    "BackupPlanName": "daily-backup-plan",
    "Rules": [
      {
        "RuleName": "daily-rule",
        "TargetBackupVaultName": "Default",
        "ScheduleExpression": "cron(0 19 ? * * *)",
        "StartWindowMinutes": 60,
        "Lifecycle": { "DeleteAfterDays": 90 }
      }
    ]
  }'

ランサムウェア対策としてVault Lockを有効にしておくと、バックアップの手動削除を禁止できる。Compliance Mode（一度設定すると解除不能）とGovernance Mode（管理者のみ解除可）の2種類があるため、要件に応じて使い分けること。

3. AzureのバックアップはAzure Backup

Azure BackupはRecovery Servicesコンテナーにデータを保管するサービスだ。Azure VM・Azure SQL Database・Azure Filesをポリシーベースで保護できる。GRS（geo-redundant storage）保管がデフォルトのため、リージョン障害に対しても一定の耐性がある。保持期間は最大99年まで設定可能で、コンプライアンス要件への対応にも使える。

スナップショットとは何か

1. スナップショットが対処できる障害と限界

スナップショットは「ある時点のディスク状態の丸ごとコピー」だ。OS・ミドルウェア・データをセットで保存できるため、設定変更前の保険として非常に有効だ。オンプレのVMwareスナップショットと感覚的に近く、経験者は最も直感的に理解しやすい概念だ。

注意点がある：
・論理破壊には無力: スナップショット取得前にランサムウェアが侵入していた場合、スナップショット自体がすでに感染済みになる
・ストレージ依存: スナップショットを保管するストレージ（EBS・Azure Managed Disks）自体の障害リスクがあるため、クロスリージョンコピーとセットで使うのが望ましい
・RTOが短い: EBSスナップショットからの復元は数分で完了することが多く、バックアップより高速な復旧が可能

2. AWSのEBSスナップショット

Amazon EBSのスナップショットはS3に増分保存される。最初のスナップショットはフルコピーだが、以降は差分のみ保存されるためコストを抑えられる。クロスリージョンコピーを組み合わせればDR構成にも応用できる。

# EBSスナップショットの作成（AWS CLI）
aws ec2 create-snapshot \
  --volume-id vol-0abc1234def56789 \
  --description "before-maintenance-20260621"

# 別リージョンへのコピー（DR対策）
aws ec2 copy-snapshot \
  --source-region ap-northeast-1 \
  --source-snapshot-id snap-0abc1234def56789 \
  --destination-region us-east-1 \
  --description "cross-region-copy"

Amazon Data Lifecycle Manager（DLM）を使えば、スナップショットの取得スケジュールと保持ポリシーを自動化できる。手動スナップショットに頼る運用は属人化しがちで取得漏れのリスクがあるため、DLMで自動化するのが定石だ。

3. AzureのManaged Disksスナップショット

Azure Managed Disksの増分スナップショットは、前回スナップショットからの差分のみを保存するため、ストレージコストを大幅に抑えられる。作成直後から読み取り専用でアクセス可能なので、バックアップの整合性検証も即時に実行できる。

レプリケーションとは何か

1. レプリケーションが対処できる障害と限界

レプリケーションは「データをリアルタイム（または準リアルタイム）で別の場所に複製し続ける」仕組みだ。AZ障害やハードウェア障害への自動フェイルオーバーに強い一方、論理的な破壊（誰かが誤ってデータを削除した場合など）には対応できない。削除操作が即座にレプリカにも反映されてしまうからだ。

レプリケーションの特徴：
・RPO最小（数秒以内）: 同期レプリケーションならデータ損失をほぼゼロにできる
・RTO最小（秒単位）: 自動フェイルオーバーにより、障害後の復旧が最速
・論理破壊に無力: 誤DELETE・マルウェア・アプリのバグによるデータ破壊は即座にレプリカに反映される

2. AWSのレプリケーション例

・Amazon RDS マルチAZ: プライマリとスタンバイを異なるAZに同期レプリケーション。プライマリ障害時に自動フェイルオーバー（切替所要時間: 通常60秒～2分）
・Amazon RDS Read Replica: 非同期レプリケーションにより読み取り専用のレプリカを作成。読み取り負荷分散とクロスリージョン展開に使える
・Amazon S3 クロスリージョンレプリケーション（CRR）: バケット内のオブジェクトを別リージョンへ自動コピー。DR構成や低レイテンシアクセスに活用できる

# RDS マルチAZ 確認（AWS CLI）
aws rds describe-db-instances \
  --query 'DBInstances[*].[DBInstanceIdentifier,MultiAZ,AvailabilityZone]' \
  --output table

3. Azureのレプリケーション例

・Azure SQL Database アクティブgeo-レプリケーション: 最大4つのセカンダリリージョンに非同期レプリケーション。手動または自動フェイルオーバーグループで切り替え可能
・Azure Blob Storage GRS/GZRS: ペアリージョンへのストレージ自動レプリケーション。書き込みから数秒以内に複製が完了するが、RPO保証は15分
・Azure Storage ゾーン冗長ストレージ（ZRS）: 同一リージョン内の3つのゾーンに同期レプリケーション。単一ゾーン障害に対してデータ損失ゼロで継続稼働できる

RPO・RTOで考える3つの使い分け

障害対策を設計するときは、まず「RPO（Recovery Point Objective: どこまでのデータ損失を許容するか）」と「RTO（Recovery Time Objective: どれだけ速く復旧する必要があるか）」を定義してから手法を選ぶのが正しい順番だ。

業務継続計画（BCP）では、この3つを組み合わせて「多層防衛」を構成するのが定石だ。

3層防衛として組み合わせる設計パターン

現場でよく採用される組み合わせを示す。WebアプリとRDSの標準的な構成を例にとると：

・レプリケーション（RDS マルチAZ）: AZ障害に自動対応。通常運用で意識する必要はなく、フェイルオーバーも自動実行される
・スナップショット（RDS自動バックアップ）: テーブルを誤って書き換えたときに特定時刻へ巻き戻す。RDSのPITRは5分単位で過去35日間まで復元可能
・バックアップ（AWS Backup）: ランサムウェア対策・長期保管要件・別リージョン保管でイミュータブルに保護

この構成でRPO・RTOを整理すると：
・ハードウェア障害 → RDS マルチAZ が対応（RPO≒0、RTO 約1分）
・誤オペレーション → RDS PITRが対応（RPO 5分、RTO 30分程度）
・ランサムウェア → AWS Backupのイミュータブルバックアップが対応（RPO 24時間、RTO 数時間）

よくある設計の誤りと対処法

【NG】「マルチAZにしているからバックアップは不要」

マルチAZはハードウェア障害への対策であって、論理的な破壊（誤DELETE、アプリのバグによるデータ上書き）には無力だ。AWS BackupでRDSの日次バックアップを別途取得することは必須だ。

【NG】「スナップショットをバックアップの代わりに使っている」

EBSスナップショットはS3に保存されるが、スナップショットを管理するAWSアカウント自体が侵害されると、スナップショットも削除されるリスクがある。Vault Lockを使ってスナップショットを削除不能に保護するか、別アカウントへコピーすることを検討すること。

【NG】「S3クロスリージョンレプリケーションをDRバックアップと見なしている」

S3のCRRで別リージョンにコピーしていても、オリジナルで削除されたオブジェクトはレプリカからも削除される（バージョニングを有効にすれば削除マーカーのみが作成されるが、意図的な削除には追加対策が必要）。DR専用バケットにはS3 Object Lockを組み合わせること。

オンプレからの移行チェックリスト

オンプレ環境からクラウドに移行する際、既存の保護設計をクラウドサービスに置き換える対応表として使ってほしい。

オンプレのRAIDはクラウドでは不要だ。EBSもAzure Managed DisksもAWS・Azure側で内部的に冗長化されており、ディスク単体障害はユーザーが意識しなくても対処される。

Linuxサーバー上でのバックアップコマンド（rsync・tar・mysqldump）や自動化スクリプトの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説している。

本記事のまとめ

バックアップ・スナップショット・レプリケーションの使い分けをまとめる。

・3つはそれぞれ異なる障害シナリオに対応しており、どれか1つで代替できる場面は限られる
・「レプリケーション × スナップショット × バックアップ」の3層で初めてクラウドの障害耐性が担保される
・設計の出発点はRPO・RTOの要件定義。業務部門と数字で合意してから手法を選ぶ
・オンプレの「テープバックアップ＋ホットスタンバイ＋RAID」からの対応関係を理解すると、移行設計がスムーズになる

クラウドのDR設計全体については、姉妹記事「AWS災害復旧（DR）設計入門 RPO・RTOの基礎からマルチリージョン構成まで オンプレ経験者のための実践ガイド」もあわせて参照してほしい。