LVM スナップショットでデータボリュームを更新前に戻す

アプリケーションのアップグレードでは、プログラムの置き換えだけでなく、インデックスやリソースファイル、データ形式が変更されることもあります。旧版のインストールパッケージを残しておくだけでは、データボリュームを元に戻せるとは限りません。すでに LVM（論理ボリューム管理）を利用している物理サーバーなら、書き込みを停止して短期運用のスナップショットを作成し、オフラインでマージすることでアップグレード前の状態に戻せます。重要なのはスナップショット作成コマンドの成功そのものではなく、書き込みを止める範囲、空き容量、復元後の検証を漏れなく押さえることです。

1. 対象ボリュームとロールバックの範囲を確認する

本記事では Debian 13、ext4 ファイルシステム、従来型 LVM のデータボリュームを例に説明します。ルートファイルシステム、起動ボリューム、シンプールは対象外です。CloudUDP の標準構成は 1TB NVMe が 2 台、それぞれ直接接続されており、ハードウェア RAID はありません。ただし、これだけでシステムが LVM を使用しているとは判断できません。実際の構成は対象環境で確認する必要があります。

まず、マウント元、ファイルシステムの種類、論理ボリュームの属性、ボリュームグループの空き容量を記録します。

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

対象が通常のパーティションであれば、ここで本記事の手順の適用を中止してください。スナップショットを使うために既存データのある領域をフォーマットしてはいけません。出力にシンボリューム、キャッシュ層、その他の複雑な構成が含まれている場合は、そのストレージ構成に対応した手順を使います。

以降は、実際のデータボリュームを vgdata/appdata、マウントポイントを /srv/appdata、関連サービスを app.service と仮定します。これらの名前は必ず実環境の値に置き換え、ネストしたマウントや、ほかに書き込みを行うプロセスがないことも確認してください。コマンドは段階ごとに実行し、記事全体をコピーして一括実行しないでください。

スナップショットはバックアップではない

従来型のスナップショットは、コピーオンライトによって元ボリュームのブロックが書き換えられる前のデータを保持する仕組みであり、元ボリュームとその下位ストレージに依存します。ディスク障害からデータを切り離して保護するものではなく、ボリューム外の設定、プログラム、リモートのデータも対象には含まれません。

スナップショットをマージすると、作成後にボリューム内で行われたすべての書き込みが取り消されます。アップグレード後にすでに業務リクエストを受け付けている場合は、保持が必要な新しいデータを先にエクスポートし、旧版のプログラムと互換性があることを確認してください。そのままロールバックしてはいけません。

2. サービスを停止し、整合性のある復元ポイントを作る

アップグレード前に独立したバックアップを用意し、プログラムのバージョン、設定の概要、アプリケーションの稼働状態を記録します。スナップショットが保証するのは、指定したボリュームのブロックの状態だけです。複数のボリュームや外部データベースが関わる場合は、コンポーネント間で整合性を確保する範囲を別途設計する必要があります。

サービスを停止する前に、リクエストの流入、キューコンシューマー、定期実行タスクを一時停止し、サービス停止後も別のプロセスがデータを書き換えることがないようにします。以下では、アンマウントの成功を静止状態の条件とし、強制アンマウントや遅延アンマウントは使用しません。

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

使用中のためアンマウントできない場合は、カレントディレクトリ、開いているファイル、ほかのサービスを確認します。書き込み元をすべて取り除くまでは先に進めません。その後、スナップショットを作成します。

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

ここでの 20G は説明用のスナップショット領域であり、製品仕様でも、あらゆる環境に当てはまる推奨値でもありません。実行前に、ボリュームグループに十分な空き容量があり、preupgrade がまだ存在しないことを確認します。スナップショット容量は、ロールバックの判断に備える監視期間中に書き換えられるデータブロックの量から見積もるべきであり、元ボリュームの総容量に一定の割合を機械的に掛けて決めるものではありません。

元ボリュームを再マウントしたら、まず小さな検証用ファイルを作成し、制御された状態でアップグレードを行います。この時点でも実際の業務による書き込みは引き続き止めておきます。書き込みを許可すると、後でロールバックする際に追加のデータ引き継ぎ手順が必要になります。

3. スナップショットを読み取り専用で確認し、使用量を監視する

スナップショットの作成に成功したら、その内容を読み取れることを必ず検証します。次のオプションは本記事の ext4 の例に限ったものです。ro は読み取り専用を指定し、noload はマウント時のジャーナル再生を防ぎます。ほかのファイルシステムにそのまま適用することはできません。

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json は、実際に選定した、内容が安定している業務ファイルを表します。事前に、そのファイルが存在し、検証対象として意味があることを確認してください。チェックサム一覧は対象ボリュームの外に保存し、ロールバック後はマウントパスではなく、ファイルのチェックサム部分だけを比較します。

変更量からリスクを判断する

sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata
sudo vgs -o vg_name,vg_free

Data% は従来型スナップショット領域の使用率を示すもので、元ボリュームのファイルシステム使用率ではありません。アップグレードの前後で継続的に値を取得し、増加の速さを観察します。インデックスの一括再構築や大きなファイルの上書きなどは、領域を急速に消費する可能性があります。

あらかじめ設定した警戒しきい値に近づいたら、それ以降の書き込みを一時停止し、容量拡張を検討します。ボリュームグループに空き容量があり、スナップショットが有効であれば、検討結果に応じて容量を増やせます。

sudo lvextend -L +10G /dev/vgdata/preupgrade

領域を増やしても、業務上許容されるロールバック期限が延びるわけではありません。スナップショットがすでに無効になっている場合は、容量拡張で修復できるとは考えず、独立したバックアップから復元する手順に切り替えます。アラートの通知先と対応手順がないスナップショット監視は、信頼できる保護策にはなりません。

4. オフラインでマージし、復元結果を検証する

ロールバックを決めたら、まず業務リクエストの流入を止め、失敗時の状況を示す資料と、必ず保持すべき新しいデータを保存します。ボリューム外のプログラムや設定も、整合するバージョンに戻す必要があります。データボリュームだけを復元すると、古いデータと新しいプログラムが不整合な組み合わせになる可能性があります。

スナップショットが有効で、そのマウントポイントがアンマウント済みであることを確認してから、関連サービスをすべて停止し、元ボリュームをアンマウントします。以下の操作はデータを変更するため、実行前にボリューム名をもう一度確認してください。

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

マージが次回のアクティブ化時に実行されるよう予約された場合は、完了するまで状態を確認します。コマンドが成功を返しただけで業務を再開してはいけません。マージが成功するとスナップショットボリュームは消えます。その後、元ボリュームを再マウントして確認します。

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

ファイルのチェックサムは基準値と一致し、スナップショット作成後に作った検証用ファイルは消えているはずです。ただし、これらで証明できるのは指定したファイルが元に戻ったことだけであり、アプリケーションの正しさまで保証するものではありません。さらにプログラムのバージョン、主要レコードの件数、読み取り結果、制御された書き込みを 1 回確認したうえで、サービスを起動してログを点検します。

5. リハーサルの結果をアップグレード用チェックリストにまとめる

まず業務データを扱わないデータボリュームで一連の手順を一度試し、スナップショットの作成、容量の増加、マージの状態、アプリケーションの確認結果を記録します。本番環境のアップグレード前には、少なくとも次の項目を確認してください。

• 対象が既存の従来型 LVM データボリュームであり、マウント元とボリューム名が対応している。
• すべての書き込み元を停止でき、元ボリュームを正常にアンマウントできる。独立したバックアップも検証済みである。
• スナップショット領域の見積もりに変更量の裏付けがあり、ボリュームグループに拡張用の空き容量がある。
• 旧版のプログラム、ボリューム外の設定、復元チェックリストを入手できる。
• 新たに書き込まれたデータの保持方法と、業務を再開する条件が明確になっている。

アップグレードの検証に合格し、ロールバックに備えた監視期間が終了したら、スナップショットがマウントされていないことを確認し、lvremove /dev/vgdata/preupgrade で残っているスナップショットを削除します。すでにマージしたスナップショットを再度削除する必要はありません。

最終的に残すべきものは、ボリューム構成、復元ポイント、容量の記録、業務の検証結果をまとめた作業記録です。スナップショットは短期的なロールバックのための道具にすぎません。信頼性を生むのは、ボリューム名をもう一つ残すことではなく、繰り返し実行できる復元手順です。

よくある質問