a snapshot

Imagine you could freeze your entire filesystem exactly as it is right now - every file, every directory - in an instant, without copying any bytes, and then keep using and changing it freely while that frozen view stays available to look back at. That frozen, read-only-as-of-now image is a snapshot. It is how you take a consistent backup of a live system, or roll an upgrade back if it goes wrong, in seconds rather than the hours a full copy would take.

On a copy-on-write filesystem a snapshot is almost trivial to create: it is just a saved reference to the current root of the block tree. Because the filesystem never overwrites blocks in place, every block reachable from that saved root stays alive and unchanged - the snapshot and the live filesystem simply share all those blocks. As you go on writing, new versions of changed blocks are written to fresh locations and the live root advances, while the snapshot's root keeps pointing at the old, shared blocks. Storage only grows as data diverges: a snapshot of a 1 TiB filesystem costs almost nothing at first and grows only by the size of what you subsequently change. (Older systems implement the same idea with copy-on-write at the volume layer, LVM-style, copying a block to a reserved area just before its first overwrite.)

Why it matters: snapshots give you cheap, consistent point-in-time recovery and clean backups of a busy system, and they underpin features like Btrfs/ZFS rollback and Time Machine-style histories. Two honest caveats. First, a snapshot is NOT a backup by itself - it lives on the same disk, so if that disk dies the snapshot dies with it; you still need to copy snapshots off to other media. Second, snapshots pin storage: a block referenced only by an old snapshot cannot be freed, so long-kept snapshots of a heavily-rewritten filesystem can silently consume large amounts of space.