スナップショット完全ガイド:COW/ROWの仕組みとアプリケーション整合性、クラウド事例とバックアップとの違いを徹底解説

スナップショットとは

スナップショット(snapshot)は、ある時点のデータの「写し」や「状態」を保存する機能を指します。ITの文脈では主にファイルシステム、ブロックデバイス(ディスク/ボリューム)、仮想マシン(VM)などの状態を短時間で確定し、後からその時点に復元できるようにする仕組みを意味します。スナップショットは瞬時に取得でき、保存容量が少なく済むことが多いため、バックアップや検証、テスト、障害対応に広く使われます。

基本的な仕組み:COW と ROW

スナップショット実装の内部は主に以下の方式に分かれます。

  • コピーオンライト(Copy-on-Write, COW):スナップショット作成時は元データをそのまま残し、新しい書き込みがあった際に元データのブロックを別場所にコピーして保存してから上書きします。ZFSやBtrfsの一部、従来型のCOW実装で見られます。
  • リダイレクトオンライト(Redirect-on-Write, ROW):新しい書き込みは別の場所に書き込まれ、メタデータのポインタだけを切り替えます。これにより書き込み時のオーバーヘッドが低減されることがあります。ストレージアレイや一部のスナップショット設計で採用されます。

実装によってパフォーマンス影響、容量利用、復元手順が変わるため、導入時に仕様を確認することが重要です。

スナップショットの種類(概要)

  • ファイルシステムスナップショット:ZFS、Btrfs など。ファイルシステムレベルでの瞬時スナップショットが可能で、非常に効率的なことが多い。
  • ブロック/ボリュームスナップショット:LVM、各種SAN/NAS、クラウドのディスクスナップショット(AWS EBS、Azure Managed Disk、GCP Persistent Diskなど)。ブロックレベルでの差分を取る。
  • 仮想マシンスナップショット:VMware、Hyper-V、KVMなどのハイパーバイザーで取得するVM全体の状態(ディスク、メモリ、デバイス状態)の保存。
  • アプリケーション/データベース対応スナップショット:VSS(Windows Volume Shadow Copy Service)やデータベースのトランザクションログ同期を利用してアプリケーション整合性を担保したスナップショット。

アプリケーション整合性(Application-consistent)とクラッシュ整合性(Crash-consistent)

スナップショットは取得時点の状態を保存しますが、アプリケーションの整合性を保証するかは別問題です。

  • クラッシュ整合性:ディスク上のブロックがその時点での状態で保存されるだけ。OSやアプリケーションは通常の突然のクラッシュ後と同等の状態で、再起動やログリプレイが必要な場合がある。
  • アプリケーション整合性:VSS(Windows)やデータベースのクエッシュフラッシュ、トランザクションの一時停止などを行い、スナップショット時点でアプリケーションが整合的な状態になるように取得する。復旧時にデータ整合性の担保が容易になる。

ミッションクリティカルなデータベースやトランザクション処理系は、可能ならアプリケーション整合スナップショットを利用するべきです。

スナップショットとバックアップの違い

  • 目的の違い:スナップショットは短時間での復旧や点検、テスト用の「ローカルな」機能が主。バックアップは長期保存、オフサイト保管、災害復旧を目的とすることが多い。
  • 耐障害性:スナップショットは同一ストレージ上に保存されるケースが多く、ストレージ障害や論理破損、ランサムウェアの影響を受けるリスクがある。一方でバックアップは別媒体・別拠点に保管することでリスクを分散する。
  • コストと速度:スナップショットは高速で取得・復元できるが、長期保持や大量保持には不向き。バックアップは取得コストや時間がかかるが、長期保持と法規制対応に強い。

運用上の注意点と落とし穴

  • スナップショットの肥大化:差分が積み重なると容量が増える。特に更新が多いボリュームでは急速に消費される。
  • パフォーマンス低下:スナップショットの取り扱い(COWや複数の差分チェーン)により書き込みや読み出しのレイテンシが増えることがある。VMスナップショットを長期間放置すると特に影響が出やすい。
  • スナップショットの削除/統合コスト:スナップショットを削除する際、バックグラウンドでブロックの統合(マージ)が発生し、I/O負荷や時間を要する場合がある。
  • 依存関係(スナップショットチェーン):複数世代の差分があるとチェーンが長くなり、復元や削除時に複雑性が増す。
  • セキュリティとコンプライアンス:スナップショットにも個人情報や機密情報が含まれるため、暗号化やアクセス制御、保存期間の管理が必要。

クラウドにおけるスナップショット(例)

  • AWS EBS:初回はフルコピー相当だが、以降は差分ブロックのみを保存(インクリメンタル)。スナップショットはS3相当の内部ストレージに保存されるが、ユーザーが直接S3オブジェクトを見ることはできない。AMI作成やリージョン間コピーも可能。
  • Azure Managed Disk:スナップショットは既定でインクリメンタル(容量効率型)になっている場合がある。スナップショットをもとにディスクを作成して復元。
  • GCP Persistent Disk:スナップショットはインクリメンタルで、リージョン間のレプリケーションや自動スケジュールが可能。

各クラウドの料金体系や整合性オプションはサービスごとに異なるため、運用前にドキュメントで確認してください。

実例コマンド(代表的なもの)

  • LVM(簡易例):lvcreate --size 1G --snapshot --name snap01 /dev/vg01/lv01(注意:現在は LVM thin snapshot の使用が推奨される場合あり)
  • ZFS:zfs snapshot pool/dataset@snapname(ZFS はCOWベースで効率的なスナップショットを提供)
  • Btrfs:btrfs subvolume snapshot /mnt/src /mnt/snap
  • Linux 上でのファイルシステム凍結(アプリケーション整合性):fsfreeze -f /mountpoint(フリーズ後にスナップショットを取得し、解除する)

実行方法やオプションは環境ごとに異なるため、導入前に公式ドキュメントを確認してください。

ベストプラクティス

  • スナップショットは短期の復旧やテスト用と割り切り、長期保管や災害対策は別途バックアップを設計する。
  • アプリケーション整合性が必要なシステムは、VSS やデータベースのトランザクション整合処理を組み合わせる。
  • スナップショットの世代数や保持期間をポリシー化し、自動削除・集約を行う。
  • 削除・統合時のパフォーマンス影響を考慮し、負荷が低い時間帯にスケジュールする。
  • 定期的にリストア試験を行い、実際に復元できることを検証する(「復元の信頼性」を確認)。
  • スナップショットも暗号化とアクセス制御を行い、脅威や法規制に備える。

まとめ

スナップショットは短時間での状態保存と迅速な復元を可能にする強力なツールですが、「万能」ではありません。実装方式(COW / ROW)、アプリケーション整合性の取り扱い、保存場所、運用ポリシー、そしてスナップショットとバックアップの役割分担を正しく理解して設計・運用することが重要です。特に本番環境では、スナップショットの取り方・保持方針・復元検証を明確にし、定期的に見直すことを推奨します。

参考文献