スナップショットは諸刃の剣！仕組みと「ストレージパンク」の教訓

インフラエンジニアとして、様々なサーバの設定変更を経験しましたが、作業の前に必ずやっていることがあります。

それはバックアップを取得することです。変更作業が失敗し、もとの状態に戻す必要がある場合にバックアップデータは活躍します。

ただ、バックアップ取得はデータをコピーするため、時間がかかります。そこで我々インフラエンジニアは「スナップショット」という方法を取ることがあります。

OSのアップデート、ミドルウェアの設定変更、アプリケーションのデプロイなど、作業には「失敗」のリスクがつきまといますが、そんな場合でもボタン一つで作業前の状態に戻せる「魔法の保険」、それがスナップショットなのです。

しかし、この便利な機能は、仕組みを正しく理解していないと、システム全体を停止させかねない「時限爆弾」にもなり得ます。

今回は、スナップショットの仕組みと、私自身の痛い失敗談を交えて、その正しい付き合い方を解説します。

スナップショットとは？「写真」ではなく「差分のメモ」

スナップショット（Snapshot）とは、ある特定の時点におけるストレージのデータ状態を記録したものです。よく「その瞬間の写真」に例えられますが、実際の仕組みはもう少し複雑で、賢いものです。

「ベース」を凍結し、「差分」を管理する

多くのスナップショット技術（VMwareやAWS EBSなど）は、Copy-on-Write（またはRedirect-on-Write）という仕組みを採用しています。

1. スナップショット作成の瞬間： システムは、その時点の元データ（ベースデータ）を「読み取り専用」としてロック（凍結）します。この時点ではデータのコピーは発生しないため、作成は一瞬で完了します。
2. 作成後のデータ変更： スナップショット作成後にファイルが変更されたり、新しいデータが書き込まれたりしても、凍結されたベースデータには書き込まれません。 すべての変更は、「差分ファイル（更新データ）」と呼ばれる別の領域に記録されていきます。
3. 状態を戻す（リストア/ロールバック） or スナップショット削除（コミット）： 作業に失敗して元の状態に戻したい場合は、システムが「差分ファイル」を破棄し、凍結しておいた「ベースデータ」の状態に戻すだけです。
   作業が成功し、現状を確定させたい場合は、スナップショットを削除し、「差分ディスク」の更新データをすべて、「ベースデータ」に上書きします。この作業によって状態を確定（コミット）させます。

つまり、スナップショットとは、丸ごとのバックアップではなく、「ある時点からの変更点だけを記録し続けるメモ書き」のようなものなのです。

💡 実務の現場メモ：基盤障害からデータを守る「真のバックアップ設計」

スナップショットが「差分の記録」である以上、ストレージ筐体の物理故障やデータストアの破損が起きた場合、スナップショットごと全データが吹き飛びます。

現場で求められる「真のバックアップ」とは、同一筐体内に依存せず、別ストレージやクラウド、別拠点へ物理的にデータを退避・世代管理する構成のことです。

現場でよく使われるバックアップ方式（フル・差分・増分）の使い分けや、RTO/RPOを考慮した設計の基本ルールは以下の記事で詳しく解説しています。

【実録失敗談】慢心が招いた「ストレージパンク」事件

仕組みがわかると、便利な点ばかりに目が行きがちです。しかし、私は過去にこの「差分管理」の仕組みを甘く見て、痛い目を見たことがあります。

あの日の夜間作業と、消し忘れたスナップショット

あれは、本番環境のLinuxサーバーにセキュリティパッチを適用する夜間作業でのことでした。

「念のため、スナップショットを撮っておこう」

私はいつものように作業前にスナップショットを作成し、安心してパッチ適用作業を開始しました。作業自体は何の問題もなくスムーズに完了し、動作確認もOK。「よし、終わった！」と安堵し、私はそのまま作業を終了してしまいました。

スナップショットを削除（コミット）するのを忘れたまま…。

静かに忍び寄る「容量圧迫」

それから数週間後、データベースのパフォーマンスが落ちているという報告を受け、調査を開始しました。そして、ストレージの監視アラートが鳴り響いたのです。

「【緊急】ストレージ使用率が95%を超過しました」

血の気が引きました。原因を調べると、ディスク容量を圧迫していたのは、あの夜に作成したスナップショットの「差分ファイル」でした。

そのサーバーは、日々大量のログを書き込み、データベースの更新も頻繁に行われるシステムでした。スナップショット作成後、数週間分のすべての「変更データ」が差分ファイルに蓄積され続け、ついに親元のストレージ領域を食いつぶしてしまったのです。

⚠️ 運用設計の視点：95%アラートが鳴る前に検知する「監視の鉄則」

ストレージの容量監視において、90%や95%の静的な閾値監視だけを設定していると、大量書き込みが発生した際に「検知した数十分後に即パンク」という事態に陥ります。

現場で本当に必要なのは、単なる使用率のしきい値だけでなく、「過去24時間での増加トレンド」や「差分ファイルの急激な増大」を捉える監視項目の設計です。

運用監視で泣かないための「アラート疲れを防ぎつつ致命傷を回避する閾値・項目設計ガイド」は以下を参考にしてください。

苦い教訓：スナップショットは「生もの」である

結果的に、緊急メンテナンス枠をもらってスナップショットを削除（コミット）し、事なきを得ましたが、一歩間違えばサービス停止の大事故でした。

この経験から学んだ教訓は一つ。 「スナップショットは、用が済んだらすぐに消せ！」

スナップショットは長期保存するためのものではありません。放置すればするほど差分データは肥大化し、ストレージ容量を圧迫するだけでなく、ディスクI/Oのパフォーマンスも低下させます。まさに「生もの」のように、鮮度が命なのです。

📌 現場の教訓：スナップショットの破綻を防ぐ「データストア設計」

スナップショットの消し忘れが命取りになる根本原因の1つは、データストアやボリュームのサイジングに「差分バッファ」が見込まれていないことにあります。

仮想化基盤やクラウドのディスク設計では、OSや実データだけでなく、スナップショット差分（最低でも実ディスクの20〜30%程度）や将来のデータ増加率を論理的に計算して容量を確保しておく必要があります。

経営層や上長レビューで突っ込まれないための「ストレージ・サーバーサイジングの具体的な計算式と根拠の残し方」は、こちらにまとめています。

まとめ：正しい知識と運用ルールを身につけよう

スナップショットは、インフラエンジニアにとって強力な武器です。しかし、使い方を誤れば自分自身を傷つけることになります。

以下のルールを徹底しましょう。

1. 作業前には必ず取得する： これはすべてのエンジニアの鉄則です。何かあった時にもとの状態に戻せる保険を作っておきましょう。
2. 作業が成功したら必ず削除する： 「後で消す」は禁物。作業後にその場で消しましょう。
3. 長期保存はバックアップで： スナップショットはバックアップの代わりにはなりません。長期保存が必要な場合は、ちゃんとしたバックアップソフトで別媒体にデータを退避させましょう。

仕組みを理解し、リスクを知った上で使いこなす。それが、プロのインフラエンジニアへの第一歩です。

🚀 この記事を読んだあなたへ：次に進むべき現場の実務ノウハウ

スナップショットの仕組みと「バックアップとの決定的な違い」を押さえたら、次はインフラの土台となる**「ストレージ全体のアーキテクチャ」**を整理しましょう。

DAS・NAS・SANの違いから、RAIDの選び方、クラウドストレージへのマッピングまで、18年の実務経験をもとに図解で網羅しています。