Snapshots and backups both produce a copy of your data and protect against different things. Treating one as the other is a common and expensive mistake, and it is only discovered on the day it matters.
What a snapshot is
A snapshot is a point-in-time image of a block volume, stored by the provider, usually incremental, usually restorable in minutes. It is excellent at exactly one job: undoing something you did to a server.
- Protects against: a bad upgrade, a broken configuration change, a deleted directory, a migration you want to roll back.
- Does not protect against: account compromise, account suspension, accidental deletion of the whole project, a provider-side regional failure, or a corruption that was already present when the snapshot was taken.
The reason is simple: the snapshot lives in the same account, on the same platform, under the same credentials as the thing it is copying. It shares a failure domain with production.
What a backup is
A backup is a copy of your data — not your disk — stored somewhere with a different failure mode, retained on a schedule, and restorable by a procedure you have actually run.
Three properties do the work:
- Separation. Different account at minimum; different provider or different medium is better.
- Retention. More than one generation, because corruption is often discovered days after it happened.
- Verification. A restore you have performed, timed, and written down.
Databases need special handling
A snapshot of a running database’s volume captures whatever was on disk at that instant, including partially written state. It will often restore fine, and “often” is not a backup policy.
Use the database’s own tools — a logical dump, or a physical backup with write-ahead log archiving if you need point-in-time recovery. Then treat that output as the thing to copy off-platform. Managed database services do this for you and expose a restore window; that is a large part of what you are paying for. See managed databases vs running your own.
A workable policy for a small deployment
- Daily automated snapshots of the server volumes, retained for a week. Cheap, fast, and covers most operational mistakes.
- Daily database dumps written to object storage in the same region — encrypted, and with a lifecycle rule so they do not accumulate forever.
- Weekly copy off-platform to a different provider or a different account entirely.
- A quarterly restore test into a scratch server, timed, with the result written down.
The restore test is the item that turns the rest into a backup system rather than a collection of files.
What it costs
Snapshots are billed for the storage they consume and accumulate quietly — an automatic daily snapshot with no retention limit is a slow, permanent increase to the monthly bill. Set retention when you set the schedule. Off-platform copies additionally incur egress charges, which is an argument for weekly rather than continuous.
Where to go next
- Block, object and file storage
- What an uptime SLA actually promises
- Migrating a workload between cloud providers
Questions
Frequently asked
Are cloud snapshots a backup?
Not on their own. Snapshots live in the same account and platform as the data they copy, so they do not protect against account loss, compromise or a regional failure. They are excellent for rolling back changes.
Can I snapshot a running database safely?
It usually restores, but it captures whatever was mid-write. Use the database's own dump or physical backup tooling for anything you intend to rely on.
How often should I test a restore?
At least quarterly, and after any significant change to the stack. Time the restore as well as verifying it, because recovery time is the number that matters during an incident.