Almost every cloud provider offers, with one click, the ability to take a snapshot of a disk or an entire virtual machine. It is fast, cheap and reassuring. Many projects stop there, convinced they are protected. In reality a snapshot solves some problems and leaves others uncovered, often the most serious ones.
What a snapshot is
A snapshot is a picture of a disk's state at a precise moment. In most services the first snapshot copies all used blocks, later ones only the changed blocks. That is why they are quick to create and take up relatively little space.
Snapshots are excellent for some purposes:
- going back after a failed system update;
- cloning a server to create a test environment;
- moving a disk to another zone or region;
- having a recent restore point, hourly or daily.
The limits of snapshots
Same account, same fate
A snapshot usually lives in the same account and often in the same region as the resources it protects. If someone obtains the account's administrator credentials, they can delete the servers and the snapshots in the same minute. The same goes for a gross human error, such as a script that deletes every resource with a certain prefix, or for a problem with the provider: a failed payment, a suspended account, a dispute.
A backup that can be destroyed together with the original using the same credential is not a real backup.
Data consistency
A snapshot taken while a database is writing is called crash-consistent: it matches what you would find if you pulled the server's power at that moment. Modern databases are designed to recover from this situation, but it is not guaranteed for every application, and data held in memory and not yet written to disk is lost.
For a reliable database restore you need application-consistent backups: a dump made with the database's own tools, or a snapshot preceded by briefly freezing writes, or the automatic backups of a managed database service, which include the logs for point-in-time recovery.
Granularity
To recover a single deleted file from a snapshot, you often have to create a new disk from the snapshot, attach it to a machine, find the file and copy it. It works, but it is slow. A file-level backup lets you recover a document in seconds.
Retention
Snapshots are designed for the short term. Keeping hundreds of them for years becomes expensive and messy. To keep data for a long time, for example for accounting or contractual obligations, you need copies organized with clear retention rules.
Comparison at a glance
| Aspect | Snapshot | Real backup |
|---|---|---|
| Creation speed | Very high | Variable |
| Where it lives | Same account and region | Separate, ideally another account or provider |
| Consistency for databases | Not guaranteed | Guaranteed with dedicated tools |
| Recovering single files | Laborious | Immediate |
| Protection from deletion | Low | High, if immutable |
| Long retention | Expensive | Designed for it |
How to build complete protection
The solution is not to give up snapshots, but to pair them with something different.
- Frequent snapshots for quick recovery after mistakes or updates, kept for a few days.
- Application-level backups of databases and important files, made with the right tools for each type of data.
- A copy outside the account: backups should be transferred to a separate account, with different credentials, or to another storage provider. Whoever runs production should not be able to delete this copy.
- Immutability: many object storage services offer object locking, often called object lock, which prevents a file from being modified or deleted until a certain date, even by the administrator. It is the most effective defense against ransomware and against whoever has stolen the credentials.
- Encryption of backups, with keys kept separately from the data.
A backup only exists if the restore works
The most neglected point is restoring. A backup that has never been tested is a hypothesis. Periodically it pays to restore a database in an isolated environment, start the application and check that the data is complete and readable. That is when you discover that a folder was missing, that the encryption password was kept only on a laptop, or that the restore takes six hours instead of one.
In my work the first question I ask is not "do you have a backup?", but "when did you last restore, and how long did it take?". The answer says much more about how well the data is really protected.
In short
- Snapshots are fast and cheap, excellent for going back after mistakes or updates.
- They live in the same account as the resources and can be deleted along with them.
- Databases need application-consistent backups, not just disk snapshots.
- Complete protection includes copies in a separate account or provider, immutable and encrypted.
- Only a regularly tested restore proves that the backup really works.
