"I take daily snapshots, I'm covered." That sentence precedes a remarkable number of permanent data losses. It is not absurd — snapshots are useful, fast, and regularly save the day. It simply rests on a category error.
What a snapshot actually is
A snapshot copies nothing. It plants a reference point in the volume and declares: from now on, any modification is stored alongside rather than overwriting what exists. That is why it is instant and costs almost no space initially.
The consequence is direct: the snapshot lives inside the volume it photographs. If the disk fails, if the storage array is lost, if the filesystem corrupts, the snapshot goes with everything else. It cannot save you from a problem that affects its own medium.
A snapshot answers one question perfectly: "how do I get back to the state of two hours ago, before that failed update?" It answers nothing at all for: "the server burned down, how do I recover my data?"
Replication: the second misunderstanding
Then comes the objection: "I replicate to a second server, so I do have a copy elsewhere." True, and it does not solve the problem.
Replication is built to be faithful. It reproduces the source state, mistakes included. You delete a directory by accident, the deletion is replicated. Ransomware encrypts your files, the encryption is replicated — sometimes before you have noticed anything at all.
The distinction is clean:
- Replication protects against hardware failure. That is availability.
- Backup protects against error and malice. That is recoverability.
Both are legitimate. Neither substitutes for the other.
What makes a copy a backup
Three properties, and you need all three.
Separate media. The copy must survive the complete destruction of the original — another machine, another building, another provider. A copy on a second disk in the same machine survives neither a fire, nor a power surge, nor a compromised admin account.
Independent retention. If deleting a source file makes it vanish from the copy on the next cycle, that is not a backup: it is a sync. You need to keep previous versions, over a depth that exceeds your detection delay. Corruption noticed after three weeks is only recoverable if retention exceeds three weeks.
A tested restore. A backup never restored is a hypothesis, not a guarantee. It is by far the most neglected of the three.
The ransomware case
This is the scenario that brutally separates strategies, because the attacker no longer just encrypts: they hunt your recovery options first.
Snapshots deleted, shadow copies wiped, backup server reached with credentials found on the compromised machine. If your backup server is reachable from the infected machine with write access and a shared password, it is compromised too.
What actually holds up comes down to three forms:
- A physically disconnected copy — an external drive in a drawer remains unbeatable for a homelab.
- A remote copy with separate credentials that the backed-up machine does not hold.
- A write-once copy that not even an admin account can alter before retention expires.
The snapshot that overstays
One last, counter-intuitive point: keeping a snapshot for a long time does not make you safer, it degrades things.
A snapshot retains every block modified since its creation. The older it gets, the more space it consumes — sometimes until the volume fills, causing an incident far worse than the one you thought you were guarding against. On some filesystems, the resulting fragmentation also hurts writes.
A snapshot is a short-term safety net: hours, a few days. Beyond that, it is the backup's job.
The phrasing that prevents the mistake
For every mechanism you have in place, ask one question: "what does this protect me from, and what does it not protect me from?"
The snapshot protects you from your recent mistakes, not from losing the medium. Replication protects you from hardware failure, not from your mistakes. Backup protects you from both — provided it is separate, versioned, and restorable.
Comments