A btrfs snapshot is not a copy of anything. btrfs subvolume snapshot creates a new subvolume whose root points at the same extent tree as the source, so every extent the two share is referenced twice and stored once. Creation is a metadata operation measured in milliseconds whether the subvolume holds a gigabyte or ten terabytes.

That makes snapshots the cheapest rollback primitive on the box, and it is also why they are the most commonly over-trusted. Space grows with divergence, not with the size of the data; the cost arrives later, on somebody else’s write, on the same device that holds the original. A snapshot you never prune is a slow-motion disk-full incident, and a snapshot on the same disk is not a backup no matter how many of them you keep.

Shared extents, not copied blocks

Snapshots are subvolumes, and a subvolume is a subtree with its own root, so the snapshot machinery is the reference-counting machinery that makes reflinks work. Take a read-only snapshot with btrfs subvolume snapshot -r /data /snap/data-2026-09-16; the -r matters, because a writable snapshot starts diverging the moment anything writes to it, and a backup target should not be writable in the first place.

The first write after a snapshot is what costs. When either side overwrites a shared extent, the filesystem allocates a new extent for the writer and leaves the old one to the other side, so the price of a snapshot is paid by the next write, in units of the extents that write touches — not by the snapshot command. APFS clonefiles share extents under the same rule, and the fixture measures the shape: a 64 MiB clone costs 0 KiB, a plain 64 MiB copy costs 65536 KiB, and overwriting the first 8 MiB of the clone costs 8192 KiB. Rewriting that same 8 MiB a second time costs 0 KiB, because those extents already diverged.

Where the space actually goes

btrfs filesystem du is the honest accounting: it prints Total, Exclusive and Set shared for each argument, where Set shared is the space it shares with the others named on the command line. Right after a snapshot, Exclusive should be near zero and Set shared close to the origin’s Total. compsize gives the same split per file, and btrfs qgroup show -reF tracks exclusive and referenced bytes per qgroup when quotas are enabled.

Deleting the origin does not free the shared extents — they become the snapshot’s exclusive data, and the space changes owner. This is the most common support question about btrfs: a file is deleted and df does not move. Only when the last reference goes away does the space return, which is why retention policy and snapshot cadence must be designed together.

A restore point is not a replica

Snapshots live in the same filesystem on the same device as their source, so a controller failure, a dead disk, or a btrfs check gone wrong takes the data and every snapshot of it in one motion. They defend against exactly one class of accident — the write that should not have happened — and they are excellent at it: rollback is local, instant, and needs no network.

Real protection means an independent copy: btrfs send walks a snapshot and emits a stream that btrfs receive applies to another filesystem, with -p sending only the delta from a parent snapshot. Send that stream to a different machine or a different pool. The distinction: send is the replication mechanism, and the snapshot is just the object it replicates.

When it breaks

The classic failure is the delete that frees nothing: someone removes a 40 GB directory, df is unmoved, and they delete more to compensate. Run btrfs filesystem du -s across the subvolume and its snapshots and look for one whose Exclusive value accounts for the gap. If the snapshots are read-only, the fix is deleting snapshots, not more files.

The second failure is a full filesystem, which on btrfs is worse than on ext4. Metadata needs space of its own, and a copy-on-write filesystem with no free space cannot allocate the extent a write requires, so one at 100 percent can fail writes that would succeed elsewhere and can go read-only. Keep headroom — 5 percent is not paranoia — bound snapshot retention, and remember that a snapshot of a nearly full filesystem also commits you to space for its divergence.

Check it quickly

Confirm the snapshot shares rather than copies, and find what is holding the space:

btrfs subvolume snapshot -r /data /snap/data-$(date +%F)
btrfs filesystem du -s /data /snap/data-2026-09-16
compsize /snap/data-2026-09-16
btrfs filesystem usage /data

du prints a Total, Exclusive and Set shared triple per path: a fresh snapshot’s Exclusive should be a few MiB of metadata at most while Set shared tracks the origin’s Total. If Exclusive already equals Total, the snapshot is a full copy. btrfs filesystem usage then shows how much divergence the device can still absorb.

Sources