Managing Storage Pools and Snapshots with ZFS and Btrfs
Traditional filesystems like ext4 or XFS rely on separate volume managers (LVM) or hardware RAID controllers to combine drives. ZFS and Btrfs combine filesystem and storage-management features, including checksums and snapshots. A snapshot is useful for recovery but is not a backup; keep a separate tested copy of important data.
ZFS vs Btrfs: Which Should You Choose?
| Feature | OpenZFS | Btrfs |
|---|---|---|
| Kernel Status | Out-of-tree kernel module; support and installation vary by distribution | Included in the upstream Linux kernel |
| Memory Planning | ARC uses available memory and can be tuned; ECC is recommended where supported but is not a strict ZFS requirement | Plan memory for the workload and filesystem cache |
| Redundancy Profiles | mirror, raidz1, or raidz2; choose based on failure and capacity requirements | RAID1/RAID10 are common choices; Btrfs RAID5/6 remains unsuitable for production data |
| Best For | Dedicated storage systems where its feature set is appropriate | Linux desktops, servers, and systems using its native filesystem tools |
Step 1: Install Utilities and Identify Disks
Install Storage Utilities and Identify Disks
PreparationThese package commands use Debian/Ubuntu; package names and ZFS kernel-module support vary by distribution. Identify disks using persistent IDs and verify their model, serial, size, and existing signatures before continuing.
sudo apt updatesudo apt install zfsutils-linux btrfs-progslsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS,SERIALls -l /dev/disk/by-id/⯠View Expected Console Output
ata-WDC_WD40EFRX_DISK1 -> ../../sdb
ata-WDC_WD40EFRX_DISK2 -> ../../sdc
Step 2: Create a Mirrored Pool or Filesystem
Create a Two-Disk Mirror
Pool CreationChoose one tab and use the persistent disk IDs verified in Step 1. The ZFS command omits force options so ZFS can stop if it detects an existing signature or another condition that needs investigation. Btrfs formatting is destructive even without a force flag.
sudo zpool create -o ashift=12 tank mirror \ /dev/disk/by-id/ata-WDC_WD40EFRX_DISK1 \ /dev/disk/by-id/ata-WDC_WD40EFRX_DISK2sudo zpool status tanksudo mkfs.btrfs -L data -m raid1 -d raid1 \ /dev/disk/by-id/ata-WDC_WD40EFRX_DISK1 \ /dev/disk/by-id/ata-WDC_WD40EFRX_DISK2sudo mkdir -p /datasudo mount -o compress=zstd:1,noatime LABEL=data /datafindmnt /data⯠View Expected Console Output
ZFS: pool tank reports ONLINE with a mirror-0 vdev.
Btrfs: findmnt /data reports the new Btrfs filesystem mounted at /data.
For Btrfs to mount after reboot, obtain its UUID with sudo blkid -s UUID -o value /dev/disk/by-id/ata-WDC_WD40EFRX_DISK1, add a corresponding UUID-based entry to /etc/fstab, then validate the file with sudo mount -a and findmnt /data before relying on it.
# Replace the value with the UUID returned by blkid.UUID=replace-with-the-filesystem-UUID /data btrfs defaults,compress=zstd:1,noatime 0 0Step 3: Organize Data into Datasets or Subvolumes
Separate Application Data from the Pool Root
OrganizationUse separate ZFS datasets or Btrfs subvolumes for application data and snapshot destinations. Btrfs compression is enabled by the mount option from Step 2; ZFS compression is configured per dataset.
⯠View Expected Console Output
ZFS datasets are listed below the pool, such as tank/appdata.
Btrfs subvolumes include appdata and snapshots.
Step 4: Create and Inspect Snapshots
Create a Snapshot Before a Planned Change
Recovery PointThese commands snapshot only the application-data dataset or subvolume, not the operating system root. Use the snapshot to inspect or recover files from that data. A full rollback is a separate, potentially destructive recovery action; plan it against the filesystem documentation and a verified backup before proceeding.
sudo zfs snapshot tank/appdata@pre-changesudo zfs list -t snapshotsudo zfs diff tank/appdata@pre-changesudo zfs set snapdir=visible tank/appdatasudo ls -la /tank/appdata/.zfs/snapshot/pre-change/sudo mkdir -p /root/recovery# Copy a reviewed file to a recovery location; inspect before restoring it.sudo cp -a /tank/appdata/.zfs/snapshot/pre-change/path/to/file /root/recovery/sudo btrfs subvolume snapshot -r \ /data/appdata /data/snapshots/appdata-pre-changesudo btrfs subvolume list /datasudo ls -la /data/snapshots/appdata-pre-change/sudo mkdir -p /root/recovery# Copy a reviewed file to a recovery location; inspect before restoring it.sudo cp -a /data/snapshots/appdata-pre-change/path/to/file /root/recovery/⯠View Expected Console Output
ZFS: tank/appdata@pre-change
Btrfs: read-only subvolume snapshots/appdata-pre-change
Step 5: Scrub and Review Filesystem Health
Verify Checksums and Redundancy
Integrity CheckA scrub checks data against filesystem checksums. ZFS or Btrfs can repair a damaged block only when the filesystem has a valid redundant copy; checksums without redundancy can detect some damage but cannot recreate lost data. Scrubs use disk I/O, so schedule them according to workload and maintenance policy.
⯠View Expected Console Output
Review the scrub summary for repaired, uncorrectable, or otherwise reported errors. A healthy result does not replace a separate backup.