Skip to content
LinuxDeep Dive Published Updated 3 min readViews unavailable

Btrfs Copy-on-Write and Snapshots: What Is Shared, What Changes, and What Can Fail

A storage-accurate explanation of Btrfs extents, subvolumes, snapshots, reflinks, checksums, free-space behavior, consistency, and backup boundaries.

Btrfs copy-on-write (CoW) lets snapshots and reflink copies share existing data extents. A snapshot can therefore be created quickly and initially consumes little additional data space. It is not a full duplicate, an isolated backup, or a promise that later writes cost nothing. Metadata, changed extents, retention, and failure domains determine the real behavior.

Sharing happens at extent level

Files reference extents. A reflink copy or snapshot initially points to many of the same extents as its source. When one reference is modified, Btrfs allocates new extents for the changed region and updates metadata while the other reference keeps the old data. Reference counting allows old extents to be freed only after no live subvolume or snapshot uses them.

A tiny overwrite can cause more allocation than the changed byte count because of extent boundaries, metadata, checksums, compression, and fragmentation. Database-style repeated random writes can amplify CoW work. Disabling CoW for selected files changes checksum and snapshot behavior and must be decided before data is written; it is not a universal performance switch.

Subvolumes are independently addressable file trees inside one file system. A snapshot captures one subvolume, not every sibling mounted beneath it. If /var/lib/app is a separate subvolume under a snapshotted root, it is not recursively captured merely because its mountpoint appears in the directory tree.

Snapshot consistency is application-specific

Creating a read-only snapshot gives a stable Btrfs view at a point in the file-system transaction history. It does not force an application to put multi-file state into a recoverable logical checkpoint. Databases may need their own snapshot hook, flush, freeze, or backup API. Open files and buffered application state require the same care as on any crash-consistent storage snapshot.

btrfs subvolume snapshot -r /srv/app /snapshots/app-2026-08-09
btrfs subvolume show /snapshots/app-2026-08-09

Confirm mount points and subvolume boundaries first. Give automation an unambiguous destination, verify the new snapshot is read-only when it will be sent as a backup base, and never parse human-oriented command output when a stable machine interface is available.

Free space is shared and delayed

Deleting a large file from the active subvolume does not release extents still referenced by a snapshot. Operators often discover this only when the same file system approaches exhaustion. Track snapshot retention, exclusive/shared referenced bytes with quota-group tooling where appropriate, and unallocated versus chunk free space. The generic df view alone cannot explain every Btrfs allocation constraint.

Snapshot deletion is also a metadata operation whose reclaim may continue after the command returns. Avoid deleting many snapshots simultaneously on an already stressed system. Reserve space and test recovery behavior before utilization becomes critical.

Checksums detect corruption in data and metadata. Redundant profiles may let a scrub repair a bad copy from a good one, but a checksum is not redundancy and RAID level semantics differ across data and metadata profiles. Monitor device errors and scrub results, and understand the support status of the chosen profile.

A local snapshot is not a backup

Snapshots on the same file system share devices, controller paths, administrative authority, and often the same encryption boundary. Device loss, destructive commands, credentials compromise, or file-system-wide corruption can affect both. Use read-only snapshots as efficient sources for btrfs send, transfer them to an independently protected destination, verify the receive side, and test restoration.

The reliable mental model is shared immutable history with new allocations for divergence. That model explains speed, retention growth, delayed frees, partial subvolume coverage, and why a snapshot is an excellent recovery primitive but not the entire recovery plan.

Related:

Sources:

Comments