UbuntuでBtrfsを使う前に：インストールとスナップショット設計の基本

Ubuntu で Btrfs を使うべきか迷っているなら、最初に決めるべきことはファイルシステム名ではありません。 スナップショットを何に使うのか、どこまで自分で復旧できるようにするのかを先に決めるべきです。

この記事では、「ubuntu btrfs」で検索する人が最初に知りたい判断基準、サブボリューム設計、スナップショットの限界、安全な検証コマンドをまとめます。

TL;DR

  • Ubuntu で Btrfs を選ぶ価値は、サブボリュームとスナップショットを運用する意思がある場合に大きくなります。
  • シンプルに使いたいだけなら ext4 のままでも問題ありません。
  • Btrfs のスナップショットはバックアップではなく、同じストレージ上の復元ポイントです。
  • インストール前に @、@home、.snapshots の扱いを決めます。
  • 実ディスクを触る前に、一時イメージや VM で mkfs.btrfs とサブボリューム操作を検証します。

Btrfsを選ぶべき人、選ばなくてよい人

Btrfs は、OS 更新や大きな設定変更の前にスナップショットを取り、問題があれば戻す運用をしたい人に向いています。 一方で、ファイルシステムの構造を意識したくない人には、ext4 のほうが扱いやすいです。

判断軸Btrfsが向くext4が向く
変更前の復元点サブボリューム単位で扱いたい外部バックアップだけでよい
設計の手間@ や @home を理解できるできるだけ考えたくない
トラブル対応ライブ USB からマウントして戻せる復旧手順を増やしたくない
運用目的実験、開発環境、頻繁な更新安定した普段使い中心

「Btrfs のほうが新しいから選ぶ」ではなく、スナップショットとサブボリュームを使う理由があるかで決めるのが安全です。

UbuntuのBtrfsで混乱しやすい点

Ubuntu と Btrfs で検索すると、@ と @home の話がよく出てきます。 これは Ubuntu 系でよく使われるサブボリューム名ですが、Btrfs 自体がこの名前を要求しているわけではありません。

Btrfs の manpage では、サブボリュームは独立したファイル階層を持つ単位として説明されています。 スナップショットもサブボリュームの一種です。

混乱しやすいのは次の点です。

  • @ はルート用としてよく使われる名前だが、必須名ではありません。
  • @home は /home 用としてよく使われますが、作るかどうかは設計次第です。
  • インストーラーが常に理想のサブボリューム構成を作るとは限りません。
  • スナップショットはバックアップではなく、同一ファイルシステム上の復元点です。

インストール後に確認するなら、次を実行します。

findmnt -no SOURCE,FSTYPE,OPTIONS /
sudo btrfs subvolume list /

/ が Btrfs ではない場合、サブボリューム一覧は期待通りには出ません。 また、Btrfs であっても @ や @home が存在するとは限りません。

インストール前に決める3つのこと

Btrfs を選ぶ前に、次の 3 点を決めておくと後戻りが減ります。

  1. /home をルートと分けるか
  2. スナップショットをどこに置くか
  3. swap をどう扱うか

おすすめの最小構成は次のような形です。

@
@home
.snapshots

@ は /、@home は /home、.snapshots はスナップショット置き場として扱います。 ログ、Docker、仮想マシンイメージ、データベースを別サブボリュームにする設計もありますが、最初から増やしすぎると復旧手順が複雑になります。

swap は、迷うなら swap パーティションを別に用意するほうが単純です。 Btrfs 上の swapfile もサポートされていますが、制約を理解してから使うべきです。

fstabの例

サブボリュームを / と /home に割り当てる場合、/etc/fstab は次のような考え方になります。

UUID=YOUR-UUID / btrfs defaults,subvol=@,compress=zstd,relatime 0 1
UUID=YOUR-UUID /home btrfs defaults,subvol=@home,compress=zstd,relatime 0 2

YOUR-UUID は例です。 実際には blkid で確認した値に置き換えます。

blkid
findmnt -no SOURCE,FSTYPE,OPTIONS /

fstab の失敗は起動不能に直結します。 ライブ USB から対象パーティションをマウントし、/etc/fstab を戻せる状態を作ってから編集してください。

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

Btrfs スナップショットは、更新前に戻りたいときに便利です。 しかし、同じストレージ上にある限り、次の事故には弱いです。

  • ディスク自体の故障
  • 誤ったデバイスへの mkfs や dd
  • 暗号化ヘッダーやパーティションテーブルの破損
  • 端末の紛失

したがって、最低限の考え方は次です。

スナップショット: 直近の変更から戻るため
外部バックアップ: ディスク故障や誤操作から戻るため

Btrfs の send / receive を使えば別ディスクへ差分転送する運用もできます。 ただし、最初の記事としては、まず外付けディスクや NAS への通常バックアップを確実にするほうが現実的です。

実ディスクを触る前に安全に試す

mkfs.btrfs はブロックデバイスだけでなく、ファイルバックドイメージにも使えます。 実ディスクを触る前に、まず一時ファイルで挙動を確認します。

tmpdir="$(mktemp -d /tmp/ubuntu-btrfs-mkfs.XXXXXX)"
img="$tmpdir/btrfs-test.img"

truncate -s 512M "$img"
mkfs.btrfs -f --metadata dup --data single "$img"
btrfs inspect-internal dump-super "$img" | sed -n '1,40p'

rm -rf "$tmpdir"

この検証では、実際のディスクやパーティションテーブルには触れません。 確認した環境は Ubuntu 26.04 LTS、btrfs-progs v6.17.1 です。

guestfish が使えるなら、サブボリューム作成とスナップショット作成も一時イメージで試せます。

tmpdir="$(mktemp -d /tmp/ubuntu-btrfs-verify.XXXXXX)"
(
  cd "$tmpdir"
  guestfish -N test.img=fs:btrfs:1G:gpt <<'EOF'
mount /dev/sda1 /
btrfs-subvolume-create /@
btrfs-subvolume-create /@home
mkdir /.snapshots
btrfs-subvolume-snapshot /@ /.snapshots/pre-change ro:true
btrfs-subvolume-list /
umount /
EOF
)

rm -rf "$tmpdir"

この検証では、@、@home、.snapshots/pre-change がサブボリュームとして作られることを確認できます。 実ディスクを触る前にここまで試しておくと、どのコマンドが何を作るのかを理解しやすくなります。

実ディスク作業で直接コピペしてはいけないコマンド

次のようなコマンドは、対象を間違えるとデータを失います。 記事や検索結果から直接コピペしてはいけません。

sudo parted /dev/sda -- mkpart primary btrfs 100GiB 200GiB
sudo mkfs.btrfs -f /dev/sda3
sudo grub-install /dev/sda

実行前に必ず自分の環境でデバイス名を確認します。

lsblk -f
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,MODEL

NVMe なら /dev/nvme0n1p3 のような名前になります。 SATA や仮想ディスクなら /dev/sda3 のような名前になることもあります。 記事の /dev/sda3 は、あなたの環境の正解ではありません。

AnsibleはBtrfsの後に効く

「ansible ubuntu 26.04」で探している人は、Ubuntu 26.04 を入れた後の環境再現にも関心があるはずです。 Btrfs のスナップショットで変更前に戻れるようにし、Ansible で同じ設定を何度でも再適用できるようにすると、実験と復旧がしやすくなります。

最初は、ディスク操作ではなく、初回起動後の環境整備から始めます。

---
- hosts: localhost
  connection: local
  become: true
  tasks:
    - name: apt キャッシュを更新する
      ansible.builtin.apt:
        update_cache: true

    - name: よく使うパッケージを入れる
      ansible.builtin.apt:
        name:
          - btrfs-progs
          - curl
          - git
        state: present

実行例です。

ansible-playbook -i localhost, -c local site.yml

Ubuntu 26.04 の標準リポジトリには ansible と ansible-core が用意されています。 より新しい Ansible が必要な場合は、Ansible 公式ドキュメントの Ubuntu 向け PPA 手順を確認します。

また、Ubuntu 26.04 系では sudo-rs の差分にも注意します。 Ansible の become: true だけなら通常は問題になりにくいですが、sudo のプロンプト文字列を Expect で読むような自動化は見直し対象です。

最初の構築チェックリスト

Btrfs で Ubuntu を構築するなら、次の順に確認すると安全です。

  1. 重要データを外部へバックアップする
  2. VM または一時イメージで Btrfs コマンドを試す
  3. /、/home、スナップショット置き場の設計を決める
  4. 実ディスク名を lsblk -f で確認する
  5. インストール後に findmnt と btrfs subvolume list で状態を確認する
  6. fstab を編集する前にライブ USB から戻せる手順を用意する
  7. 初回起動後の設定は Ansible に寄せる

この順にすると、Btrfs の利点を使いながら、失敗時の被害を小さくできます。

まとめ

Ubuntu で Btrfs を使うなら、最初に必要なのは「Btrfs を選ぶこと」ではなく、復旧の設計です。 サブボリューム、スナップショット、外部バックアップ、fstab、Ansible の役割を分けて考えると、Btrfs はかなり扱いやすくなります。

Ubuntu 26.04 LTS 固有の前提（sudo-rs への移行、パッケージバージョン確認）や、Ansible で初回起動後の環境を再現する範囲は、 Ubuntu 26.04 LTSとBtrfs：Ansibleで再現できる安全な環境作り に分けて整理しています。

参考リンク