Btrfsスナップショットでシステム更新を安全にロールバックする｜容量管理と自動取得の設計判断

システム更新に潜むリスクとBtrfsスナップショットが果たす役割

システムパッケージの更新は定期的に行うべき作業ですが、カーネル・glibc・OpenSSLといったコアコンポーネントの更新は、想定外の挙動変化をもたらすことがあります。更新直後にサービスが起動しない、依存ライブラリのバージョン不整合で既存アプリケーションが動作しなくなる、といった事態は現場でも珍しくありません。

従来、こうしたリスクへの対策としてはLVMスナップショットやVM側のスナップショット機能が使われてきました。しかし2026年現在、FedoraやopenSUSE Tumbleweed・Leap、EndeavourOSなど主要ディストリビューションがBtrfsをデフォルトファイルシステムとして採用した結果、ファイルシステムネイティブなスナップショット機能を実用できる環境が整っています。

Btrfsスナップショットの最大の特徴は「コピーオンライト（CoW）」による効率性です。取得直後はスナップショット自体の実体はなく、変更が生じた部分だけが新たな領域に書き込まれます。そのため取得コストが低く、更新前に気軽に発動できます。この記事では「更新前に取得 → 更新 → 問題発生時にロールバック」という一連のシナリオを軸に、容量管理と自動取得の設計判断まで整理します。

サブボリューム設計がスナップショット運用の土台になる

Btrfsスナップショットを実用的に使うには、インストール時点でのサブボリューム設計が重要です。多くの現行ディストリビューションはデフォルトで @（ルートファイルシステム）と @home（ホームディレクトリ）を別サブボリュームとして切り分けています。

この分離が重要な理由は、スナップショットの粒度にあります。@ サブボリュームだけのスナップショットを取れば、/home 以下のデータはロールバックの影響を受けずに済みます。ユーザーが更新後に作成したファイルを消さずに、システム状態だけを元に戻せるという点で、実務上の扱いやすさが大きく変わります。

一方で /var/log や /var/cache の扱いにも設計判断が必要です。ログはロールバック後も追跡できるよう独立させるべきか、それともシステム全体と一緒に戻すべきか、運用方針によって結論が変わります。snapperのデフォルト設定では /var/log を別サブボリュームとして分離するケースが多いですが、手動構成の場合は意図的に設計する必要があります。

スナップショットの保存場所を決める

スナップショットは通常 /.snapshots/ のような専用ディレクトリ配下に別サブボリュームとして作成します。snapperはこの構造を自動で管理しますが、手動運用する場合の典型的な構造は次のとおりです。

/                       ← @ サブボリューム（ルート）
/.snapshots/            ← @.snapshots サブボリューム（スナップショット置き場）
/.snapshots/1/snapshot
/.snapshots/2/snapshot
/home                   ← @home サブボリューム

この構造を維持することで、スナップショット自体がスナップショットに含まれてしまう再帰的な入れ子の問題を回避できます。既存環境でサブボリュームが整理されていない場合、後から構成を変更するのはリスクを伴うため、新規構築の機会に設計を見直すか、検証環境で手順を確認してから本番適用することが望まれます。

更新前スナップショットの取得：手順と確認ポイント

更新作業の直前にスナップショットを取得します。snapperを使う場合の基本的な流れは次のとおりです。まず現在のスナップショット一覧を確認します。

sudo snapper -c root list

続いて更新前スナップショットを手動取得します。--description に日付と目的を入れておくと、後でロールバック対象を特定しやすくなります。

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

次にパッケージ更新を実行します。Fedoraであれば dnf upgrade、openSUSEであれば zypper dup です。更新完了後、更新後スナップショットも取得しておくと「更新前後の差分確認」が可能になります。

sudo dnf upgrade
sudo snapper -c root create --description "after-dnf-update-$(date +%Y%m%d)"

snapperには更新前後のスナップショットをペアにする「pre/post」タイプが用意されています。--type pre と --type post --pre-number <pre番号> を使うことで、2つのスナップショットを明示的にペアとして管理できます。パッケージ管理コマンドのプラグインを導入すると、この操作が自動化されます。

ロールバックの実施と再起動後の確認

更新後にシステムが正常に動作しない場合、Btrfsスナップショットを使ってロールバックできます。snapperのロールバック機能はGRUBのブートエントリを生成し、次回起動時に旧スナップショットから起動することで安全に元の状態へ戻します。

sudo snapper -c root rollback <スナップショット番号>
sudo reboot

再起動後は、元のサブボリュームが @ に戻っているかを確認します。

sudo btrfs subvolume show /

また snapper list でスナップショット一覧を確認し、現在どの時点の状態で動作しているかを把握します。ロールバック後に「Active」列や「Current System」の表示が切り替わっていることを必ず確認してください。

ロールバックが機能しない場面と回避策

ロールバックが有効に機能するのは、あくまでシステムサブボリューム（ルート）の範囲内です。データベースファイルが /var/lib/mysql に存在する場合、/var を同一サブボリュームに含めていればロールバック対象になりますが、別サブボリュームとして分離していれば影響を受けません。設計時点でどちらの挙動が望ましいかを明確にしておく必要があります。

カーネルアップデート後のロールバックでは、起動時のinitramfsが旧カーネルと整合していることが求められます。grub-btrfsやsdbootconfを使う環境ではスナップショットからの起動エントリが自動生成されますが、設定が正しく行われていない場合はブートメニューに旧エントリが現れないことがあるため、更新作業の前にブートエントリの生成動作を一度確認しておくことが望まれます。

容量管理の設計判断：「いつ消すか」を決めておく

Btrfsのコピーオンライトはスナップショット取得時の負荷を低く抑えますが、スナップショットを長期間保持すると差分データの積み上げで実質的な使用容量が増加していきます。「スナップショットを取りすぎて気づけばディスクが満杯」という状況は、現場でも発生しやすい失敗パターンです。

snapperのデフォルト設定には自動削除ポリシー（Timeline Cleanup）が組み込まれています。設定ファイルは /etc/snapper/configs/root にあり、保持するスナップショット数を世代単位で管理します。

TIMELINE_LIMIT_HOURLY="5"
TIMELINE_LIMIT_DAILY="7"
TIMELINE_LIMIT_WEEKLY="0"
TIMELINE_LIMIT_MONTHLY="0"
TIMELINE_LIMIT_YEARLY="0"

この設定では1時間ごとのスナップショットを5世代、日次を7世代保持し、週次・月次・年次は保持しない設定です。ストレージ容量が限られている環境では、日次のみ数世代という保守的な設定が安全です。残余容量の確認には以下のコマンドを使います。

sudo btrfs filesystem usage /

Data と Metadata の使用量を確認し、Free が逼迫していないかを定期的にモニタリングする仕組みを整えておくことが重要です。Btrfsはディスク残量が少なくなると突然書き込みエラーを引き起こす性質があるため、他のファイルシステムより早めのアラートラインを設定することが推奨されます。

自動取得の実装とsnapperを使った運用設計

手動でスナップショットを取得する運用は、更新作業を忘れずに行っている間は機能しますが、systemd timerやcronによる自動パッケージ更新との組み合わせでは手動操作が間に合わないケースがあります。

snapperにはsystemdのtimerによる定期的なスナップショット取得機能が標準で組み込まれています。インストール後に以下のtimerを有効化します。

sudo systemctl enable --now snapper-timeline.timer
sudo systemctl enable --now snapper-cleanup.timer

さらにパッケージマネージャプラグインと組み合わせることで「パッケージ操作のたびにpre/postスナップショットを自動生成」する運用が実現します。Fedora向けには python3-dnf-plugin-snapper パッケージが提供されており、インストールするだけで以降のdnf操作がスナップショット付きで記録されます。

sudo dnf install python3-dnf-plugin-snapper

openSUSEでは snapper-zypp-plugin が同様の役割を担います。

設計判断のポイント：自動化の範囲と人の関与

自動スナップショットは便利ですが、「ロールバックの判断」は依然として人間が行う必要があります。自動取得により「取り忘れ」は防げますが、問題発生時にどのスナップショットへ戻るかを判断するのは運用担当者です。スナップショット一覧に意味のある description がついていないと、複数のエントリが並んだときに「どれが何の前後か」を判断しにくくなります。自動生成エントリには日時とパッケージ操作の種別が入ることが多いですが、手動操作分にはdescriptionを必ず付与する運用習慣を組み込むことが推奨されます。

2026年現行環境での差分と注意点

2026年時点で、Btrfsスナップショットを取り巻く環境はいくつかの点で整理されています。

Fedora 40以降のデフォルト構成：Fedora 40からBtrfsが正式デフォルトファイルシステムとなり、インストーラが @ と @home の分離構成を自動で作成します。ただし、snapperのインストールと設定は手動で行う必要があり、自動化はされていません。Fedoraのデフォルトインストールで「すぐにスナップショット運用できる」とは言えない点に注意が必要です。

openSUSE Tumbleweed：snapperとzypp-pluginが標準搭載されており、インストール直後からスナップショット運用が有効な状態になっています。ロールバック機能もgrub-btrfsと統合されており、現時点で最も実用的な構成です。ローリングリリースモデルと組み合わせることで「更新を気軽に試せる環境」を構築できます。

systemd-boot環境での注意：GRUBではなくsystemd-bootを採用する環境（例：Arch Linuxのデフォルト構成）でのスナップショットからの起動には、grub-btrfs の代わりに別途の追加設定が必要になる場合があります。ブートローダとスナップショット機能の統合は環境によって異なるため、事前に検証環境で動作確認を行うことが重要です。

Btrfs RAID構成との組み合わせ：Btrfs RAID1やRAID10とスナップショットを組み合わせる場合、btrfs filesystem usage の出力解釈が単一ディスク環境と異なります。RAIDの冗長性とスナップショットは独立した仕組みであり、スナップショットはハードウェア障害への対策ではなく「論理的な状態変更」に対する保護として位置づけることが、運用方針を明確にする上で重要です。

Btrfsスナップショットは、適切なサブボリューム設計・容量管理ポリシー・自動化の組み合わせによって初めて実務に耐える運用になります。どれか一つが欠けても、「取ったが使えなかった」「ディスクが溢れた」という結果につながりやすいため、設計の段階で三点セットを揃えることを意識してください。