
もっち
- 関東大手SIer勤務
- 10システム、仮想サーバ約200台の基幹系システムが稼働する仮想化基盤のインフラ運用リーダー
以下3点について、ブログで役立つ情報を発信
- インフラ技術・システム運用
- キャリア・マネジメント
- エンジニア実務・仕事術


もっち
以下3点について、ブログで役立つ情報を発信
インフラエンジニアとして、様々なサーバの設定変更を経験しましたが、作業の前に必ずやっていることがあります。
それはバックアップを取得することです。変更作業が失敗し、もとの状態に戻す必要がある場合にバックアップデータは活躍します。
ただ、バックアップ取得はデータをコピーするため、時間がかかります。そこで我々インフラエンジニアは「スナップショット」という方法を取ることがあります。
OSのアップデート、ミドルウェアの設定変更、アプリケーションのデプロイなど、作業には「失敗」のリスクがつきまといますが、そんな場合でもボタン一つで作業前の状態に戻せる「魔法の保険」、それがスナップショットなのです。
しかし、この便利な機能は、仕組みを正しく理解していないと、システム全体を停止させかねない「時限爆弾」にもなり得ます。
今回は、スナップショットの仕組みと、私自身の痛い失敗談を交えて、その正しい付き合い方を解説します。
この記事の想定読者
この記事を読むことでのメリット
サーバを守る「最後の砦」であるバックアップや、それを支えるストレージなど、興味のある方は、以下の記事もチェックしてみてください。


スナップショット(Snapshot)とは、ある特定の時点におけるストレージのデータ状態を記録したものです。よく「その瞬間の写真」に例えられますが、実際の仕組みはもう少し複雑で、賢いものです。
多くのスナップショット技術(VMwareやAWS EBSなど)は、Copy-on-Write(またはRedirect-on-Write)という仕組みを採用しています。

つまり、スナップショットとは、丸ごとのバックアップではなく、「ある時点からの変更点だけを記録し続けるメモ書き」のようなものなのです。
仕組みがわかると、便利な点ばかりに目が行きがちです。しかし、私は過去にこの「差分管理」の仕組みを甘く見て、痛い目を見たことがあります。
あれは、本番環境のLinuxサーバーにセキュリティパッチを適用する夜間作業でのことでした。
「念のため、スナップショットを撮っておこう」
私はいつものように作業前にスナップショットを作成し、安心してパッチ適用作業を開始しました。作業自体は何の問題もなくスムーズに完了し、動作確認もOK。「よし、終わった!」と安堵し、私はそのまま作業を終了してしまいました。
スナップショットを削除(コミット)するのを忘れたまま…。
それから数週間後、データベースのパフォーマンスが落ちているという報告を受け、調査を開始しました。そして、ストレージの監視アラートが鳴り響いたのです。
「【緊急】ストレージ使用率が95%を超過しました」
血の気が引きました。原因を調べると、ディスク容量を圧迫していたのは、あの夜に作成したスナップショットの「差分ファイル」でした。
そのサーバーは、日々大量のログを書き込み、データベースの更新も頻繁に行われるシステムでした。スナップショット作成後、数週間分のすべての「変更データ」が差分ファイルに蓄積され続け、ついに親元のストレージ領域を食いつぶしてしまったのです。
結果的に、緊急メンテナンス枠をもらってスナップショットを削除(コミット)し、事なきを得ましたが、一歩間違えばサービス停止の大事故でした。
この経験から学んだ教訓は一つ。 「スナップショットは、用が済んだらすぐに消せ!」
スナップショットは長期保存するためのものではありません。放置すればするほど差分データは肥大化し、ストレージ容量を圧迫するだけでなく、ディスクI/Oのパフォーマンスも低下させます。まさに「生もの」のように、鮮度が命なのです。
スナップショットは、インフラエンジニアにとって強力な武器です。しかし、使い方を誤れば自分自身を傷つけることになります。
以下のルールを徹底しましょう。
仕組みを理解し、リスクを知った上で使いこなす。それが、プロのインフラエンジニアへの第一歩です。
インフラエンジニアとして、設計書の理解は欠かせません。設計書について興味のある方は以下の記事もチェックしてみてください。


この記事が気に入ったら
フォローしてね!