A Btrfs snapshot is a new subvolume with the source’s initial contents, sharing existing file extents rather than duplicating every data block. Creation copies root metadata and may flush dirty source data, so it is not guaranteed to finish in milliseconds. More than two subvolumes or reflinks can reference the same extent; there is no fixed two-reference limit.

Snapshots make local recovery points economical, but their cost includes metadata and blocks retained by later divergence. They share the filesystem’s storage pool with the source, which may span several devices. Keeping many snapshots can retain deleted or overwritten data. A snapshot within that same filesystem is not an independent backup, even when it is read-only.

Shared extents, not copied blocks

Snapshots are subvolumes with their own roots. The example btrfs subvolume snapshot -r "$src" "$snap" requests a read-only snapshot; ordinary snapshots are writable. Read-only status prevents routine changes through that subvolume, not administrator deletion or underlying corruption. Snapshotting is not recursive: nested subvolumes appear as empty stubs, so their contents require separate handling.

When a shared extent changes, copy-on-write preserves the older contents for remaining references. Allocation depends on extent layout, compression, metadata and later snapshots, not simply application bytes written. The earlier APFS clone figures are not Btrfs measurements and have no recovered trace here. They cannot establish zero-cost creation or zero allocation on a repeated Btrfs overwrite.

Where the space actually goes

btrfs filesystem du reports file-extent Total, Exclusive and Set shared values using FIEMAP. Each argument defines its own recursively scanned file set; Set shared counts shared extents referenced by that set, accounting for overlaps, rather than only sharing with other arguments. compsize reports compression-oriented Disk Usage, Uncompressed and Referenced columns, not the same split. Qgroup accounting additionally requires enabled, consistent quotas.

Deleting the source does not release extents still referenced by snapshots or reflinks. Those extents become exclusive only if no other references remain. Subvolume deletion removes the directory first and cleans extents asynchronously; space need not return immediately. df gives filesystem-level capacity, not an attribution of every retained byte to one snapshot.

A restore point is not a replica

A local snapshot can preserve a useful filesystem view without providing application-consistent recovery. A database may need coordinated backup procedures, its logs and recovery after restoration; unsent application buffers are outside the snapshot. Source and snapshot also share underlying failure risks. Local rollback is neither a fixed-time guarantee nor a substitute for testing that the application can restart correctly.

btrfs send generates a stream for btrfs receive on another filesystem. Incremental -p operation relies on a suitable unchanged parent present at both ends; all participating snapshots must be read-only. Separate storage helps only against failures it does not share. Retention, successful receipt and content-verified restoration still matter; more frequent snapshots do not guarantee a fixed reduction in transferred bytes.

When it breaks

When deleting a large directory frees little space, inspect snapshot and reflink references before deleting more data. btrfs filesystem du -s and qgroups provide different accounting views; one Exclusive value need not explain the whole discrepancy. Only remove recovery points after checking retention and send dependencies. Several snapshots can collectively retain blocks that none owns exclusively by itself.

Copy-on-write needs allocation headroom for data and metadata. Review both with btrfs filesystem usage; unallocated device space and free space inside allocated block groups are different quantities. Neither a universal five-percent reserve nor a fixed order of exhaustion follows from these counters. An allocation failure alone also does not establish that the filesystem became read-only.

Btrfs roots share extents while divergence preserves old data; nested-subvolume omissions, retained references and independent recovery requirements remain explicit.
Btrfs shared extents — mechanism diagram.

Check it quickly

This limited inspection remains unexecuted. It requires authorized disposable source /mnt/btrfs-lab/data, an existing snapshots parent on the same Btrfs filesystem, tools and permissions. Keep all paths symlink-free and exclusively controlled throughout. An existing destination directory changes where Btrfs creates the snapshot; the guard rejects existing paths, including dangling symlinks. It is not a race-proof lock; stop if exclusive control is unavailable.

(
  set -eu
  src='/mnt/btrfs-lab/data'
  snap='/mnt/btrfs-lab/snapshots/data-2026-09-16'
  if [ -e "$snap" ] || [ -L "$snap" ]; then
    printf '%s\n' 'Refusing an existing snapshot destination.' >&2
    exit 1
  fi
  btrfs subvolume snapshot -r "$src" "$snap"
  btrfs filesystem du -s "$src" "$snap"
  compsize "$snap"
  btrfs filesystem usage "$src"
)

Snapshot inspection now uses the bound destination; reruns refuse it rather than removing it. File-extent counters do not measure total snapshot metadata. Exclusive equalling Total means currently unshared extents, not absence of snapshot history. This is not a divergence or restore test: separately record known fixture bytes, verify both views initially, change only the source, then verify old snapshot bytes and new source bytes. Those storage checks and application recovery remain held.

Sources