A colleague says the nightly LVM snapshot of the server's data volume is the backup. Why is an LVM snapshot sitting in the same volume group not a backup, and what is it actually good for?
answer
- same disks, same volume group
- stores differences, not data
- unchanged blocks read from the origin
- origin gone, snapshot worthless
- a source to copy from, not a copy
basics
~20 sAn LVM snapshot stores only the blocks that changed since it was taken and reads everything else from the origin volume, on the same disks in the same volume group. Lose the origin or the disks and the snapshot is worthless. It is a stable point-in-time source to copy from, not a copy.
solid answer
~50 sA classic LVM snapshot created with `lvcreate -s` is not a second copy of the data. It is a copy-on-write exception area: LVM only saves a chunk into the snapshot when that chunk is about to be overwritten on the origin, and every unchanged block you read through the snapshot device is served from the origin logical volume. That means it shares the same physical volumes, the same volume group, and the same failure domain — a failed disk, a fat-fingered `vgremove`, a filesystem corruption on the origin, or a stolen server takes the snapshot with it. What a snapshot buys you is a *frozen, readable view* while the origin keeps taking writes, so a backup tool can stream a consistent image off to another machine, and a rollback point for a risky upgrade. The backup is the bytes that land somewhere else.
go deeper
Be ready to say that a snapshot only stores changed blocks and reads the rest from the origin, so it lives and dies with the origin's disks. Name its real use: a stable point-in-time source to copy data off the machine.
Explain the copy-on-write mechanics behind the claim — the exception area, the redirect of unchanged reads to the origin, and the write penalty that makes long-lived snapshots expensive for the production volume.
Show you would design the procedure: short-lived snapshot, off-host copy, verification, retention on the copies. Be able to say what failure classes a snapshot covers (a bad upgrade) versus what only a real backup covers (hardware, datacentre, ransomware, late-discovered corruption).
Own the policy: what recovery point and recovery time each tier of storage gets, whether snapshot-based backups are trustworthy enough to be the fleet standard, and how you prove restorability rather than assuming it. Argue the failure-domain rule, not the tool.
## What `lvcreate -s` really allocates When you run something like `lvcreate -s -L 5G -n db-snap vg0/db`, LVM carves 5 GiB of free extents out of the volume group `vg0` and turns them into a *copy-on-write* (COW) exception area, plus a new device-mapper device `/dev/vg0/db-snap` that you can mount and read. Crucially, nothing is copied at creation time. Creating a snapshot of a 2 TB volume takes about a second, because at that instant the snapshot's contents are defined entirely by the origin: "everything, as it looks right now". The snapshot only starts consuming space when the origin changes. Before a chunk of the origin is overwritten, device-mapper reads the old contents of that chunk and writes them into the snapshot's COW area, recording the mapping in an exception table. Reads through the snapshot device consult that table: if the chunk was modified since the snapshot was taken, you get the preserved old copy from the COW area; if not, the read is redirected straight to the origin logical volume. ## Why that makes it a view, not a copy That redirection is the whole argument. A snapshot is a *differences* store plus a pointer back to the origin. Consequences a candidate should be able to state plainly: - **Same disks.** The COW area is allocated from the same volume group, which means the same physical volumes, which usually means the same disks or the same array. A disk failure that kills the origin's extents kills the snapshot's ability to reconstruct anything. - **Same host.** You cannot carry a snapshot to another machine. There is no self-contained artifact to move; the useful bytes are spread across origin extents and COW extents inside one VG. - **Dependent lifetime.** Remove or overwrite the origin and the snapshot is meaningless. LVM will not even let you casually delete an origin that still has snapshots attached. - **It can evaporate.** If the COW area fills up, LVM marks the snapshot invalid and all reads from it fail. A "backup" that can silently disable itself because the origin got busy is not a backup. - **It costs the origin.** Every first write to a chunk while the snapshot exists turns into read-old-chunk, write-to-COW, then the real write. Keeping snapshots around indefinitely as "retention" degrades the production volume. ## What it is genuinely for Two jobs, both real: 1. **A stable source for a backup.** The origin filesystem keeps accepting writes while your backup tool reads a motionless image through the snapshot device. You mount it read-only and stream it to somewhere else — another host, object storage, a tape robot: ``` lvcreate -s -L 5G -n db-snap vg0/db mount -o ro /dev/vg0/db-snap /mnt/snap tar -C /mnt/snap -cf - . | ssh backup-host 'cat > db.tar' umount /mnt/snap lvremove -f vg0/db-snap ``` The backup is the file on `backup-host`. The snapshot was scaffolding, and it should be short-lived. 2. **A rollback point for a risky change.** Snapshot before a package upgrade or a schema migration, and if the change goes wrong, merge the snapshot back over the origin with `lvconvert --merge`. This is protection against *your own change*, not against hardware. ## Framing it in an interview The crisp formulation is failure domains. A backup must survive the loss of the thing it is backing up; a snapshot lives inside that thing. Snapshots protect against logical mistakes that you notice quickly, on hardware that still works. Backups protect against the hardware, the datacentre, the ransomware, and the mistake you notice three weeks later. A serious setup uses both: a snapshot to get a consistent read, a copy elsewhere to be the actual backup, and retention on the copy rather than on the snapshot. One more nuance worth knowing: thin snapshots (in an LVM thin pool) change the space mechanics — they allocate from a shared pool instead of a fixed COW area, so they are cheap to keep — but they change nothing about this argument. They still live in the same volume group and still depend on the same physical volumes.
- So what does a correct snapshot-based backup procedure look like end to end?Quiesce or freeze the filesystem briefly, create the snapshot, thaw immediately, mount the snapshot read-only, stream its contents to storage on another machine, verify the copy, then remove the snapshot. Retention lives on the off-host copies; the snapshot exists for minutes, not days. Long-lived snapshots slow the origin and risk filling their COW area.
- Does using an LVM thin snapshot instead change whether it counts as a backup?No. A thin snapshot allocates from the shared thin pool rather than a fixed copy-on-write area, so it is much cheaper to keep and does not become invalid on its own. But it still lives in the same volume group on the same physical volumes as the origin, so it dies with them. Cheap to retain is not the same as safe to rely on.
A snapshot is a bookmark plus a list of the edits made since you placed it — not a photocopy of the book. Burn the book and the bookmark tells you nothing.
saying these in an interview costs you the question
- Says a snapshot is a full second copy of the volume
- Thinks the snapshot survives losing the origin LV
- Believes snapshots protect against disk failure
- Keeps snapshots for weeks as backup retention
- Assumes the snapshot's size equals the data it holds