Btrfsサブボリューム本番活用｜パッケージアップデート後のスナップショット切り戻し設計

なぜパッケージアップデート後の切り戻し設計が必要か

カーネルのマイナーアップデートやライブラリの大規模更新は、依存関係の変化によって稼働中サービスに影響を与えることがあります。ext4やXFSのような従来ファイルシステムでは、アップデート前の状態に戻すにはバックアップからのリストアが必要で、ダウンタイムを避けにくい構造でした。

Btrfsが提供するコピーオンライト（CoW）スナップショットは、この問題に対して低コストな解を提供します。アップデート直前のサブボリューム状態を瞬時にスナップショットとして記録し、問題が発生したときはそのスナップショットを読み取り専用から書き込み可能に変換してブートターゲットに切り替えるという流れが、比較的少ない手順で実現できます。

重要なのは「スナップショットを取る」だけでなく、「スナップショットから実際に起動できる設計にしておく」点です。ここを整えていないと、いざというときにgrubエントリが存在せず、切り戻しの手順が複雑になります。本記事ではその設計と手順を一通り整理します。

サブボリュームレイアウトの設計指針

切り戻しを確実に機能させるには、サブボリュームのレイアウトが鍵になります。Fedora・openSUSE・Ubuntu 24.04以降など、Btrfsをデフォルト採用するディストリビューションでは、インストール時点でおおよそ次のような構成が用意されます。

• @（または @rootfs）: ルートファイルシステム（/）
• @home: ホームディレクトリ（/home）
• @log や @cache: ログ・キャッシュ類

切り戻し設計で特に意識すべきポイントは2つあります。

1つ目は、ロールバック対象にしないサブボリュームを / の下にネストさせないことです。/var/log を @ サブボリューム内に含めると、ロールバック時にログも一緒に巻き戻ります。ログは障害調査の証跡として残したいケースが多いため、別サブボリュームとして切り出す設計が一般的です。同様に /var/lib/containers（Podman・Docker のデータ）や /var/lib/libvirt などもロールバックの対象外とすることを検討してください。

2つ目は、スナップショット保存先を専用サブボリュームにまとめることです。/.snapshots をマウントポイントとして独立させ、そこにスナップショットのサブボリュームを格納します。openSUSEがデフォルトで採用するsnapper方式では、この構造が前提になっています。snapperを使わず手動管理する場合も、同様のディレクトリ構成をとると運用が整理されます。

アップデート前スナップショットの作成手順

ここでは、snapperを使う方法と、btrfs subvolume snapshot コマンドを直接使う方法の両方を示します。

snapperを使う場合（openSUSE / Fedora向け）

snapperはアップデート前後のスナップショットをペアで記録する「pre/post」モデルを持ちます。zypperやdnfなどのパッケージマネージャと連携するプラグインが整備されており、アップデート実行時に自動でスナップショットを作成します。手動でpreスナップショットを作成する場合は次のコマンドを使います。

sudo snapper -c root create --type pre --description "before-update-$(date +%Y%m%d)"

アップデート実行後にpostスナップショットを作成し、ペアとして記録します。

sudo dnf upgrade   # または zypper dup
sudo snapper -c root create --type post --pre-number <preのID> --description "after-update-$(date +%Y%m%d)"

スナップショット一覧は sudo snapper -c root list で確認できます。

btrfsコマンドを直接使う場合

snapperを導入していない環境や、手順を自前で管理したい場合は、以下のように読み取り専用スナップショットを直接作成します。

sudo btrfs subvolume snapshot -r / /.snapshots/root_before_update_$(date +%Y%m%d)

-r フラグにより読み取り専用スナップショットとして作成されます。読み取り専用にしておくことで誤操作による変更を防ぎ、ロールバック時に書き込み可能なコピーに変換して使用するのが安全な手順です。

スナップショットからの切り戻し手順

アップデート後に問題が発生した場合の切り戻しは、大きく2通りのアプローチがあります。

snapperのロールバックを使う方法（grub-btrfsと連携）

openSUSEでは snapper rollback <スナップショットID> を実行後に再起動するだけで、次回起動時にスナップショットが @ として展開されたボリュームから起動します。内部的には次の処理が行われます。

• 現在の @ を新しいスナップショットとして保存
• 指定したスナップショットから書き込み可能なサブボリュームを作成
• それを新しい @（デフォルトサブボリューム）に設定

Fedoraでは grub-btrfs パッケージを追加することで、grubメニューにスナップショットの一覧を表示させ、起動時に選択する形のロールバックが可能になります。

手動でロールバックする方法

snapperを使わない構成でのロールバック手順の想定例を示します。以下はあくまで構成パターンの例であり、実際の環境に応じてサブボリューム名やマウントポイントを読み替えてください。

まずライブ環境（インストールメディアなど）で起動し、Btrfsパーティションをマウントします。

sudo mount /dev/sdXY /mnt

現在の @ を退避し、スナップショットから書き込み可能なコピーを新しい @ として作成します。

# 現状のルートを退避
sudo btrfs subvolume snapshot /mnt/@ /mnt/@.broken_$(date +%Y%m%d)

# ロールバック先スナップショットを書き込み可能コピーとして展開
sudo btrfs subvolume snapshot /mnt/.snapshots/root_before_update_YYYYMMDD /mnt/@

その後、/mnt/@/boot/grub2/grub.cfg（またはディストリビューションに応じたパス）の内容を確認し、UUIDやサブボリューム指定が正しく参照されていることをチェックしてから再起動します。grubの rootflags=subvol=@ パラメータが新しい @ を指していることが重要です。

よくあるつまずきと注意点

切り戻し設計において一般的に発生しやすい問題と、その対処の考え方を整理します。

/boot や EFIパーティションはBtrfsスナップショットの外

多くの構成では /boot や /boot/efi（EFIシステムパーティション）はBtrfsではなくfat32やext4上にあります。カーネルイメージや initramfs はここに置かれるため、Btrfsのスナップショットをロールバックしてもカーネルファイルは巻き戻りません。古いカーネルのgrubエントリが残っていない状態でロールバックすると、古いサブボリュームの内容と新しいカーネルの組み合わせになり、起動に失敗するケースがあります。

対策として、アップデート時に古いカーネルパッケージをすぐに削除しない運用が有効です。多くのディストリビューションでは直近2世代のカーネルを保持する設定がデフォルトになっています。

スナップショットの肥大化

CoWの性質上、スナップショット作成直後はほぼ容量を消費しませんが、元のサブボリュームとの差分が積み重なるにつれてディスク使用量が増加します。古いスナップショットを定期的に削除しないとディスクフルになります。snapperでは保持世代数をconfigファイルで指定できます（NUMBER_LIMIT や NUMBER_LIMIT_IMPORTANT）。手動管理の場合は btrfs subvolume delete と btrfs filesystem df を組み合わせて定期的に確認する運用が必要です。

データベースやコンテナのデータは別サブボリュームに

PostgreSQLやMySQLのデータディレクトリ、Podmanのコンテナストレージなどを @ サブボリュームの下に置いていると、ロールバック時にそのデータも過去の状態に戻ります。書き込み中のデータについては整合性の問題も発生し得ます。これらは別サブボリュームとして分離し、@ のロールバック対象から外す設計が推奨されます。

2026年時点の主要ディストリビューション差分

2026年10月時点での主要ディストリビューションにおけるBtrfsサポートの状況を整理します。

Fedora 40/41系

Fedora 33以降、デスクトップ向けインストールではBtrfsがデフォルトファイルシステムになっています。サブボリュームレイアウトは @（ルート）と @home の2分割構成です。snapperはデフォルトでは含まれておらず、dnf install snapper で追加します。grub-btrfs を組み合わせることでgrubメニューからのスナップショット起動が可能になります。2025年以降のFedora版では、dnfのトランザクションhookとsnapperの連携プラグイン（python3-dnf-plugin-snapper）が整備されており、dnf upgrade 前後の自動スナップショット作成が設定できます。

openSUSE Tumbleweed / Leap 15.6系

openSUSEはBtrfs + snapperの組み合わせを最も体系的に整備しているディストリビューションです。zypper によるパッケージ操作には自動的にpre/postスナップショットが記録され、snapper rollback コマンド1本で切り戻しが完結します。Leap 15.6ではsnapperのデフォルト設定で月次・週次・日次の保持世代数が設定済みです。Tumbleweedのようなローリングリリースモデルでは、この仕組みが特に重要な安全網として機能します。

Ubuntu 24.04 LTS以降

Ubuntu 24.04からインストーラーにおけるBtrfsレイアウトのサポートが改善されています。ただし、Canonicalの公式サポートはext4が主軸であり、Btrfsはインストーラー選択肢として存在するものの、snapperや自動スナップショット連携はディストリビューション側では標準提供されていません。Ubuntu環境でBtrfsのスナップショット管理を行う場合は、TimeshiftをBtrfsモードで使用するか、snapperを手動で追加する方法が一般的です。Timeshiftはsystemdタイマーによる定期スナップショットを管理GUIとともに提供しており、デスクトップ・サーバー双方で利用できます。

カーネルとBtrfsの機能追加状況

Linux 6.6以降のカーネルではBtrfsのRAID1Cや送受信（send/receive）周りの改善が続いており、6.8以降ではfolio対応やゾーンドストレージサポートが進んでいます。スナップショットと直接関係する機能としては、btrfs send によるスナップショットの別ホストへの転送の安定性向上が報告されており、リモートへのバックアップ転送と組み合わせた二重化設計の信頼性が高まっています。実際の運用環境に合わせてカーネルバージョンの機能差異を確認することを推奨します。