データベースを運用していると、「スナップショット」や「クローン」という言葉を耳にすることがあると思います。
どちらも「DBのコピー的なもの」みたいですが、違いがよくわかっていないかったです。
というこｔ今回は “クローン” と “スナップショット” の違いをまとめてみました！
スナップショット (Snapshot) とは？
スナップショット は、ある時点のデータベース状態を読み取り専用で保存する仕組みのことが多いです。
-
ポイントインタイムの状態を保存
- 「2023/10/05 15:00 の時点でのDBの状態」をぱっと切り出し、そのまま保存しておけるイメージ。
-
通常は読み取り専用
- 作ったスナップショットを直接書き換えることはできない場合が多い。
- 後から復旧するときなどに参照する用として使うケースがメジャー。
-
復元が目的
- 不測の事態やデータ破損があったとき、スナップショットから DBを“巻き戻す” のに使う。
- よくある例：Amazon RDS のスナップショット → 後で RDS インスタンスを新しく作成して復元。
メリット
- データの保護やバックアップ用途でわかりやすい。
- 特定時点の状態を簡単に再現できるので、障害時のリカバリが素早くなる。
デメリット / 注意点
- 基本的に読み取り専用で、そのまま別環境に書き込みたいときは別途手順が必要。
- スナップショットの保存にはストレージ容量がかかる（増分保存の仕組みがある場合もあるが、コスト管理に注意）。
クローン (Clone) とは？
クローン は、既存のデータベースをベースにして、書き込み可能な“複製”を素早く作る仕組みを指すことが多いです。
-
元のDBの物理データを使いまわしつつ、新規変更だけ差分で管理
- 例：Snowflake の “Zero-Copy Clone” などでは、元データを参照しながら、クローンで行った変更だけ別途保持するので、素早く複製できる＆コストが低い。
-
生成されたクローンは書き込み可能
- 実際にアプリケーション開発・テスト環境で使ったり、新しい機能の実験に使えたりする。
-
スナップショットと違い、編集が前提
- 切り出した複製元とは独立して操作できるので、自由に書き込み可能。
メリット
- 開発やテストで「本番DBのリアルなコピー」を手軽に用意できる。
- 差分ベースのクローンを提供する仕組みなら、フルコピーしなくてもいいので高速＆コスト削減。
デメリット / 注意点
- 差分管理の仕組みによっては元DBのストレージ消費とクローン分を合わせて管理する必要がある。
- クローン先で勝手に変更して本番データと混同しないように運用ルールが大事。
違いのまとめ
| 項目 | スナップショット (Snapshot) | クローン (Clone) |
|---|---|---|
| 用途 | バックアップ / 復元 | 複製DBを作って開発・テスト・検証などに利用 |
| 読み書き | 通常は読み取り専用 | 書き込み可能（複製DBとして機能） |
| 作り方 | 指定時点の状態を記録 | 元DBを参照しつつ差分を管理して高速に複製 |
| 主な利用シーン | 災害復旧、データ破損時のリカバリ、監査など | 開発環境・テスト環境の構築、新機能検証、本番の影響回避 |
| コスト | 増分管理の場合もあるが、フルバックアップに近い | 差分管理の仕組みがあればフルコピー不要でコスト削減可 |
使い分けのイメージ
-
障害対策やバックアップ用途
- 「スナップショット」 で定期的に保存しておけば、いざというときに巻き戻し可能。
-
開発・テスト環境を本番同様に作りたい
- 「クローン」 機能を使えば、本番の状態をコピーして実験できる。書き込みもOK。
実際には各データベースやサービスで用語が微妙に違うケースがありますが、多くの場合はこのように “スナップショット = 読み取り専用のバックアップ”、 “クローン = 書き込み可能な複製” というイメージです。
まとめ
-
スナップショット はバックアップやリカバリが目的：
- ある時点で「どうだったか」を記録し、読み取り用に保管。
-
クローン は開発やテストなど実際に書き込み可能な“複製”：
- 本番データと同じ状態を別環境で動かしたいときに便利。
どちらも DB のコピーっぽい動きをしますが、目的や読み書き可否が違うので、ユースケースに合わせて選びましょう！
もし何か追加の質問や実際のサービス事例などがあれば、コメントで教えてください！
この記事が参考になればうれしいです。