A system update breaks something. On an ordinary filesystem, fixing that means identifying what changed, reverting packages, and hoping nothing else depended on the change. With Btrfs snapshots taken before the update, it means rebooting into the previous snapshot and being back where you started in under a minute.
That capability alone justifies the filesystem for many desktop and server users.
What changed in 2026
- Default adoption spread. More distributions shipped Btrfs as the default root filesystem with snapshot integration configured out of the box.
- Update integration matured. Automatic snapshots before package operations, with boot menu entries for previous states, became routine rather than manual setup.
- Redundancy caveats persisted. Certain parity configurations remained known-unreliable and unrecommended for data you care about.
- Compression became a default. Transparent compression enabled by default in more distributions, frequently improving performance.
Subvolumes and layout
A subvolume is an independently snapshottable portion of the filesystem. What you can roll back is determined entirely by how you divided things, which makes layout the decision worth thinking about before installation rather than after.
| Path |
Separate subvolume |
Reason |
| System root |
Yes |
The thing you roll back |
| Home directories |
Yes |
Roll back the system without losing your work |
| Variable data and logs |
Yes |
Excluded from system snapshots; churns constantly |
| Package cache |
Yes, excluded from snapshots |
Large, regenerable, pointless to snapshot |
| Temporary directories |
Yes, excluded |
No value in snapshotting |
| Container and virtual machine storage |
Yes |
Different snapshot cadence and heavy churn |
The critical separation is system from home. Rolling back a broken system update should not revert the document you were editing, and it will if they share a subvolume.
The exclusions matter for space. Log directories and package caches churn constantly, so including them in snapshots means every snapshot diverges rapidly and consumes space for data nobody will restore.
Snapshots in practice
Snapshot before system updates automatically. Most distributions with Btrfs defaults do this, and the boot menu entry for the previous state is what turns a broken update from an evening of recovery into a reboot.
Snapshot home directories on a schedule. Hourly during the working day, daily retained longer, with a retention policy pruning old ones. Recovering a file deleted an hour ago becomes trivial.
Set retention policies deliberately. Snapshots consume space as data diverges, and an unbounded collection eventually fills the filesystem — which on a copy-on-write filesystem degrades badly rather than failing cleanly.
Understand that snapshots are not backups. They live on the same drive. A drive failure, a theft, or a fire takes the snapshots with the data. Send snapshots to another system for actual backup, which the filesystem supports efficiently by transferring only differences.
Configurations to avoid
Certain parity-based redundancy modes have known reliability problems and have carried warnings for years. Do not use them for data you care about, regardless of how appealing the space efficiency looks.
Mirroring and striping configurations are well-tested and appropriate. For parity redundancy, either use a different filesystem — ZFS explained covers the main alternative — or run Btrfs on top of a separate redundancy layer.
Avoid filling the filesystem. Copy-on-write needs free space to work, and performance degrades sharply as capacity approaches full. Keep meaningful headroom.
Common mistakes
- System and home in one subvolume. Rollback loses your work.
- Snapshotting logs and caches. Space consumed on churning data nobody restores.
- No retention policy. Snapshots accumulate until the filesystem fills.
- Using the problematic parity modes. Known reliability issues.
- Treating snapshots as backup. Same drive, same fate.
- Running near full. Copy-on-write degrades badly.
FAQ
Do snapshots slow things down?
Creating one is instant. Having many has modest overhead. The larger effect is space consumption as data diverges.
Can I roll back individual files?
Yes. Snapshots are browsable as directories, so copying a single file out is straightforward.
Is it as reliable as the alternatives?
For the well-tested configurations, it is widely used in production. Avoid the specific modes carrying warnings.
Should I enable compression?
Generally yes. Modern algorithms frequently improve throughput because less data moves from disk.
Where to go next
For the alternative with stronger integrity guarantees, read ZFS explained. For the hardware underneath, NAS buying guide, and for virtualization on top, Proxmox homelab guide.