ディスクスナップショットとrsync系バックアップをどこで選ぶか――方式比較と選定設計

ディスクスナップショットとrsync系バックアップのどちらを採用するかは、「何を・どの速さで・どこまで復旧させるか」という設計要件で決まります。スナップショットはブロックデバイス全体を時点コピーする方式であり、rsync系はファイル・ディレクトリ単位の増分同期です。この違いを曖昧にしたまま方式を選ぶと、障害発生時に復旧できない構成になるか、過剰なコストが発生します。本記事では、復旧シナリオ・RTO/RPO・整合性・コスト・検証・手順書という6つの設計軸で選定判断を整理します。

スナップショットとファイルバックアップそれぞれが得意とする復旧シナリオ

スナップショットが強い：インスタンス全体の即時復元

EBSスナップショットやLVMスナップショットが威力を発揮するのは、「OSを含むインスタンス全体を特定時点に戻す」シナリオです。アプリケーションのバグ修正デプロイ後にシステムが起動しなくなった場合、スナップショットからボリュームを復元してインスタンスにアタッチするだけで復旧が完了します。ファイルシステムのメタデータ・パーティション構成・ブートローダまで含めて丸ごと戻せるため、環境再構築の手間がありません。また、10台規模の本番クラスタでも同一スナップショットから複数ボリュームを並列起動できるため、大規模障害時の復旧スピードに優れます。

rsync系が強い：特定ファイルの選択的リストア

rsyncやrsnapshot、borgbackupといったファイルバックアップが得意とするのは、「特定のファイルやディレクトリだけを別の時点から取り出す」シナリオです。誤って設定ファイルを上書きした場合や、アプリケーションが生成した特定の日付のログファイルを復元したい場合、スナップショットではボリューム全体をマウントして目的ファイルを探す必要があり、手順が煩雑になります。一方、ファイルバックアップであれば転送先から直接コピーするだけです。世代管理もファイル単位で細かく設定でき、50世代分を1か月保持するような運用が容易に実現できます。

見落とされがちなハイブリッド設計の落とし穴

よくある判断ミスは、「スナップショットがあるからファイルバックアップは不要」という整理です。スナップショットは取得頻度がコストに直結するため、1日1回などに制限されることが多く、直前1時間分の変更ファイルが復元できない場合があります。また、スナップショットが暗号化ボリューム上のデータをブロック単位でコピーする都合上、特定のファイルだけを外部環境に転送する用途には不向きです。設計段階で「全体復元」と「部分復元」の両方のシナリオを想定し、どちらが業務上クリティカルかを先に決めておく必要があります。

EBSスナップショット・LVMスナップショット・rsync系の比較表

3方式の特性を構造的に整理する

3つの方式はそれぞれ動作レイヤー・適用範囲・コスト構造が異なります。技術選定の場面では、どの軸で優劣を比較するかを明確にしないと議論が発散します。以下の比較表は、構築担当者が最初に確認すべき判断軸を整理したものです。

判断軸	EBSスナップショット	LVMスナップショット	rsync系（rsync/borg等）
動作レイヤー	クラウドストレージAPI	ブロックデバイス（LVM）	ファイルシステム
取得粒度	ボリューム単位	論理ボリューム単位	ファイル・ディレクトリ単位
増分管理	ブロック差分（AWS管理）	COW差分（ローカル）	ファイル差分・ハードリンク
特定ファイル復元	△（ボリュームマウントが必要）	△（LVMマウントが必要）	◎（直接コピー可）
取得時のI/O影響	低（API経由・非同期）	中（COWオーバーヘッド）	中〜高（ネットワーク・CPU依存）
オフサイト転送	◎（S3/クロスリージョン）	×（ローカル完結）	◎（SSH/S3/クラウド対応）
整合性制御	アプリ側freeze必要	アプリ側freeze必要	アプリ側flush推奨
コスト発生源	ストレージ使用量	LVMボリューム容量	転送先ストレージ・転送量

LVMスナップショットを選ぶ場面の判断

LVMスナップショットはオンプレミス環境でEBSに相当するブロックレベル保護が必要なときに選択肢になります。ただし、COW（Copy-on-Write）の仕組み上、スナップショット取得後に元ボリュームへの書き込みが多いほどI/Oオーバーヘッドが増加します。一般的には書き込みが集中するDBボリュームへの適用は慎重に検討すべきです。また、LVMスナップショットはローカルディスクに依存するため、ホスト障害時のオフサイト保護には別途転送の仕組みが必要になります。rsync系と組み合わせて「LVMで時点コピー→rsyncで転送」とする二段構成が現実的な設計です。

RTO・RPO要件に対する方式の適合性マトリクス

RTO・RPO要件の定義と方式のマッピング

RTO（目標復旧時間）とRPO（目標復旧時点）は、バックアップ方式を決める前に業務側と合意すべき数値です。「1時間以内に復旧、直前30分以内のデータが保証できれば許容」という要件と「24時間以内復旧・前日データで可」とでは選ぶ方式が変わります。RTO 1時間以内を要求する環境では、スナップショットからのボリューム復元が現実的な選択肢になります。一方、RPO 15分を要求する場合はスナップショット取得頻度を15分間隔にするとコストが跳ね上がるため、WALアーカイブやbinlogレプリケーションとの組み合わせを検討すべきです。

SLA要件に応じた方式選定チェックリスト

以下は設計時に使える選定の判断フローです。RTOとRPOの要件値が決まったら、この順で方式を絞り込んでください。

1. 復旧対象は「インスタンス全体」か「特定ファイル・データのみ」か → 全体ならスナップショット優先、ファイル単位ならrsync系優先
2. RTO要件は1時間以内か → Yes: スナップショット必須。No: rsync系でも許容範囲の可能性あり
3. RPO要件は1時間以内か → Yes: スナップショット頻度またはDBレプリ・WALとの組み合わせを検討
4. オフサイト・クロスリージョン保護が要件か → Yes: EBSクロスリージョンコピーまたはrsync系をクラウドストレージ宛に構成
5. ファイル単位の世代管理（例：30世代以上）が要件か → Yes: rsync系またはborg/resticを採用
6. オンプレミス環境でブロックレベル保護が必要か → Yes: LVMスナップショット＋オフサイト転送の組み合わせ

マトリクスで見る適合パターン

RTO・RPOの組み合わせは4象限で整理できます。RTO短・RPO短（厳格）の環境ではスナップショット＋DBレプリの組み合わせが基本です。RTO長・RPO長（緩和）の環境ではrsync系のみでも業務要件を満たせるケースが多く、コストを抑えられます。RTO短・RPO長という組み合わせは一見奇妙ですが、「復旧は早く・データ保証は前日分で十分」という要件で実際に存在します。この場合はスナップショットを1日1回取得し、復元時はそこからインスタンスを即座に起動する構成が適合します。

バックアップ取得中の整合性確保設計（DB停止か否か）

クラッシュ整合性とアプリケーション整合性の違い

バックアップ取得中に書き込みが継続していると、バックアップデータはクラッシュ整合性（OSが突然停止した状態に相当）にしかなりません。PostgreSQLやMySQLなどのRDBMSは自己回復機能を持つため、クラッシュ整合性バックアップからも起動時にWAL/redoログで整合性を回復できますが、これは「起動できる」にすぎず「全データが保証された状態」とは異なります。アプリケーション整合性を保つには、バックアップ直前にDBをflushしてディスク書き込みを完結させ、その状態でスナップショットを取得する必要があります。

DB停止なしで整合性を確保する設計パターン

本番DBを停止せずに整合性を保つ一般的な設計パターンは3つあります。第一はPostgreSQLであれば専用のバックアップ開始・終了APIを使い、バックアップ中のWALアーカイブを確保する方法です。第二はMySQLであれば一時的に書き込みをロックしてからスナップショットを取得する方法ですが、ロック中は書き込み要求がブロックされるため、トランザクション量の多い本番環境では数秒でもサービス影響になりえます。第三はレプリカ側でバックアップを取得する方法で、プライマリへの影響をゼロに抑えられるため、本番の可用性を最優先にする環境で広く採用されています。rsync系バックアップの場合もこの考え方は同様で、取得対象のDBデータファイルを動的にコピーしても整合性は保証されません。

設計時の判断：どのパターンを選ぶか

DB停止の可否・レプリカの有無・ロック許容時間という3要素で判断します。レプリカがある環境ではレプリカ側バックアップ一択です。レプリカがなくロックを許容できる環境では、ロック時間を最小化するために事前にOSのページキャッシュをフラッシュしてからロック取得する手順が有効です。実際の設計では、バックアップウィンドウ（許容できる影響時間）を事前に業務側と合意しておくことが重要で、この合意がないまま手順を決めると後から「その秒数のロックは許容できない」という判断覆しが発生します。

コスト構造の違いと保管期間の設計

スナップショットのコスト構造

EBSスナップショットのコストはS3に保管されるブロック差分のサイズに比例します。初回フルスナップショットの後は変更ブロックのみが課金対象となるため、変更量が少ない環境ではコストが抑えられます。ただし保管世代数を増やすと差分の累積コストが線形に増加します。頻繁に大量書き込みが発生するボリュームでは1世代あたりのコストが大きくなるため、取得頻度と保管世代数の両方を設計段階で試算しておく必要があります。保管期間の設計では、週次・月次のスナップショットを長期保持し、日次スナップショットは7〜14日で自動削除するという階層保管が一般的な構成です。

rsync系のコスト構造

rsync系バックアップのコストは、転送先ストレージの使用量と転送量が中心です。borgbackupやresticは重複排除（deduplication）を備えており、同一内容のファイルブロックを共通化するため、世代が増えても実ストレージ使用量の増加を抑えられます。想定例として、1日1回バックアップを30世代保持する構成では、重複排除なしの場合はデータ量×30倍の容量が必要ですが、borgbackupを活用した場合の実容量は大幅に圧縮されることが多いです（ただし実測値は環境依存であり、事前の検証が必要です）。外部クラウドストレージへの転送コストも考慮が必要で、転送量課金があるクラウドでは大容量環境の運用コストが想定外に膨らむことがあります。

保管期間の設計と削除ポリシー

保管期間の設計は「いつまで戻れる必要があるか」というビジネス要件から逆算します。コンプライアンス要件が7年保管を求める場合はコールドストレージへの移行が不可欠で、ホットストレージ保管を継続すると年間コストが数倍になります。一方、システム障害対応用途なら直近30日あれば十分なことが多く、それ以上の保管は過剰投資です。設計時は「障害対応用の短期保管」と「コンプライアンス用の長期アーカイブ」を分離し、それぞれに適したストレージ層とバックアップ方式を割り当てる構成を検討してください。

バックアップ検証テストの自動化設計

バックアップ検証が設計に含まれていない問題

バックアップが取れていても、それが実際に復元できるかどうかは別問題です。よくある落とし穴として、スナップショットは取得できているが暗号化キーが失われており復元時に復号できない、rsyncバックアップのファイルパーミッションが転送先で変わっており起動できない、という問題があります。これらは実際に復元を試みるまで発覚しません。バックアップ検証を運用設計に組み込まずに本番稼働させているシステムは、「バックアップがある」と「バックアップから復旧できる」を混同している状態です。

自動検証の設計パターン

バックアップ検証の自動化は、取得したバックアップから定期的にインスタンスを起動し、アプリケーションの起動確認・DBのデータ整合性チェックを実行して結果をアラートとして通知するパイプラインとして設計します。EBSスナップショットであれば、スナップショットから新規ボリュームを作成してテスト用インスタンスにアタッチし、ヘルスチェックを自動実行する仕組みが実現可能です。rsync系であれば、転送先ディレクトリから別環境にrsyncでコピーして同様のヘルスチェックを行います。検証は週1回以上の頻度で実施し、検証失敗時はアラートで担当者に通知する設計にしておくことで、バックアップの品質を継続的に担保できます。

検証設計に含める項目

バックアップ検証テストの設計に含めるべき確認項目を整理します。

• ボリューム・ファイルの復元: バックアップソースからの復元が完了するか（エラーなし）
• OS・アプリの起動: 復元環境でOSが起動し、アプリケーションプロセスが立ち上がるか
• DBデータ整合性: DB起動後にテーブルが参照できるか、レコード件数が想定範囲か
• 設定ファイルの確認: 環境依存の設定ファイル（接続先・ポート等）が含まれているか
• 暗号化・権限: 暗号化ボリュームの復号ができるか、ファイルパーミッションが正しいか
• 復元所要時間の記録: 実測RTOとして記録し、要件値と乖離していないか定期確認

復旧手順書への方式別記載粒度設計

手順書は「判断フロー」と「操作手順」を分離する

復旧手順書の設計でよくある失敗は、判断フロー（何が起きているか、何を復元するか）と操作手順（どのコマンドを実行するか）が混在した文書になることです。判断フローが不明確な手順書は、障害発生時に読み手が状況を正しく認識できずに誤った手順を実行するリスクがあります。一方、操作手順だけに特化した手順書は、バックアップ方式や環境が変わるたびに大規模な改訂が必要になります。設計としては、「どの障害・どの範囲を復旧するか」を判断する前段フローと、「具体的な操作」を記載する後段手順を分離した構成が保守性の観点で優れています。具体的な操作の詳細は別ページや参照先に分離し、手順書本体には判断事項と確認条件を中心に記載する方針を推奨します。

方式別の記載粒度の違い

スナップショット復元の手順書では、「どのスナップショットIDを使うか」「ボリュームをどのインスタンスにアタッチするか」という判断事項が記載の中心になります。手順書には操作の逐次コマンドを網羅するよりも、「確認すべき状態」と「次のステップへの進む条件」を明記する方が実用的です。rsync系の手順書では、「どのパスのどの世代を取得するか」という選択基準と、転送後のパーミッション・所有者の確認事項が重要な記載項目です。手を動かす操作の詳細はウィキや参照先に分離し、手順書本体は判断事項に集中させる構成が保守しやすい設計です。

手順書の品質を維持するためのレビュー設計

手順書は作成時ではなくバックアップ検証テストと連動してレビューする設計にします。年4回の検証実施に合わせて手順書の棚卸しを行い、環境変更・方式変更が反映されているかを確認します。手順書のバージョン管理はGitで行い、変更差分をレビューする仕組みを作っておくと、誰がいつどのような変更をしたかを追跡できます。また、手順書は担当者以外が読んで実行できる粒度で記載されているかを定期的に確認することが重要です。担当者しか実行できない手順書は、その担当者が不在の障害時に役立ちません。手順書の最終目標は「担当者不在でも復旧できる」状態の担保です。その観点で、記載粒度の過不足を定期的に見直す設計にしておくことが、長期的な運用品質の維持につながります。