You've replaced the server disk, the system boots up, everything is in place, but the orders table is empty. The last snapshot is also from three days ago. This is when you realize that what you'd been calling a "backup" until yesterday was actually a snapshot, and a snapshot was never meant to take the place of a backup.
A snapshot is an instantaneous image of the state of disk blocks at a point in time. On LVM, ZFS, Ceph, and almost every modern cloud platform, this is done with copy-on-write: instead of copying the data, only the metadata is recorded, and the old blocks stay in place as long as they remain untouched. That's why creating one takes a few seconds, even for a 500-gigabyte disk. It's this speed that's deceptive.
A snapshot sits on the same storage
If a snapshot of a volume is taken on the same pool that the volume itself is in, you have two copies of the data that both depend on the same hardware. The RAID controller burns out, the pool suffers corruption, or someone mistakenly runs zpool destroy, and both are gone together. A snapshot is good against human error and logical corruption, but useless against physical failure.
I've seen this in practice many times: a team that takes a snapshot every night, has a green dashboard, and on the day the physical disk dies discovers that none of those snapshots can be restored. A snapshot is a rollback tool, not a disaster recovery strategy.
This is where they go wrong
The most common mistake is that the snapshot is taken on the same server it's supposed to protect, and then someone reinstalls that server. The sign is obvious too: after reinstallation, the snapshot list is empty and support says "the snapshots were deleted along with the volume." A snapshot is tied to the volume; if the volume goes, the snapshot goes too. If you're not keeping the snapshot on separate storage, you don't actually have a backup.
What a real backup must have
A backup means an independent copy, on separate media, with the ability to be restored in another environment. Three characteristics that a snapshot doesn't have:
- Geographic independence: The copy must be on another storage or datacenter. If it's in the same rack, the same fire takes both.
- Logical independence: You must be able to restore a single table or a single file separately, not the entire disk.
- Testability: A backup that has never been restored is not a backup; it's an assumption.
The tool doesn't matter either. pg_dump with the -Fc flag, which gives compressed output with per-table selection, or mysqldump --single-transaction for InnoDB without locking tables, both work. The point is to send the output somewhere that has no physical relationship to the main server; object storage was built for exactly this and also has versioning.
The right combination: snapshots for speed, backups for survival
These two aren't rivals. Keep snapshots for short windows: before a migration, before a database version upgrade, before a schema change. If the upgrade breaks, you roll back in seconds. This is something a backup can't provide, because restoring a 200-gigabyte database from object storage usually takes hours, not minutes.
Keep backups for the long horizon: daily, weekly, monthly, with retention off the server. A practical pattern I use myself: a snapshot every six hours with 48-hour retention, a daily logical dump with 30-day retention, and a monthly copy that goes to separate storage and stays for a year.
| Feature | Snapshot | Backup |
|---|---|---|
| Creation time | Seconds | Minutes to hours |
| Storage location | Same storage | Separate storage or site |
| Single-file restore | Hard or impossible | Direct |
| Resistant to disk failure | No | Yes |
| Space cost | Only changed blocks | All data |
The cost you have to accept is this: a real backup consumes space and bandwidth and has a restore time. If your data volume is several terabytes, keeping 30 daily copies means storage costs several times the server itself. This is where you should put numbers on RPO and RTO, rather than deciding intuitively.
Application-consistent snapshot
A crash-consistent snapshot is different from an application-consistent snapshot. If you take a snapshot in the middle of a database write, you may end up with a copy that's in a crash state and needs crash recovery to restore. For MySQL, before the snapshot run FLUSH TABLES WITH READ LOCK, take the snapshot, then UNLOCK TABLES. For PostgreSQL, it's enough to be in pg_start_backup() mode or use pg_basebackup. These details are what make the difference between "it was restored" and "it was restored but two hours of data were lost."
Where a snapshot is the right answer
If you only have a staging environment and want a rollback point before testing a change, a snapshot is the right choice and making a full backup is a waste of time. Also, for system disks that only contain config and binaries, a snapshot is enough; the real data is somewhere else.
But if you have customer databases on that same server, a snapshot is only one of three layers. The second layer is a logical dump on separate storage, the third layer is a copy outside that datacenter. On cloud infrastructure, this is done with a separate volume or a bucket in another region, and you don't need to build a complex architecture. If you're still working on a dedicated server with local disks, cloud infrastructure (IaaS) makes this separation of storage from compute easier.
A restore test, not a backup test
A dashboard that says "backup successful" is worthless. What has value is that once a month you restore a copy on a temporary server and see the application come up. I do this with a simple script that takes the latest dump, restores it on a temporary instance, runs a count query, and sends the result to the team chat. If that message doesn't arrive, it means you don't have a backup.
To understand which part of your infrastructure is actually covered, the practical guide to smart monitoring and alerting is a good starting point; the same tool you use for disk monitoring can also report a failed backup job. And if the number of servers has grown, infrastructure as code helps the definition of backups and snapshots be versioned like any other resource, rather than living in one person's head.
Frequently asked questions
Does a snapshot take the place of a backup?
No. A snapshot sits on the same storage where the main data is, so a disk failure or volume deletion destroys both together. A snapshot is built for quick rollback within minutes, not for recovery after a disaster.
What is the difference between a snapshot and a backup?
A snapshot is an instantaneous image with copy-on-write that's created in seconds and remains tied to the volume. A backup is an independent copy on separate media that can restore a single file or single table, but creating and restoring it takes time and space.
How often should I take a snapshot?
It depends on RPO, not on habit. If you can tolerate losing six hours of data, every six hours is enough. For high-transaction databases, an hourly snapshot along with WAL archiving or binlog is more logical so you have a precise recovery point.
How do I know my backup actually works?
Only by restoring it. Restore a copy on a temporary server, bring the application up, and run a real query. If you haven't done this, what you have is an assumption, not a backup.
Take a snapshot today and then ask: if this same disk is lost within the next hour, where is the last independent copy of your data and how many hours old is it? The answer to that question is the difference between a bad workday and a disaster.
Comments 0
No comments yet — be the first!