The failure people do not plan for
Most backup plans protect against deleting a file or corrupting a database. Those are real risks and snapshots handle them well.
The risk that gets skipped is losing access to the whole account: a suspension, a billing failure, a compromised credential used destructively. In every one of those cases, backups stored inside the account go with it.
Keep one copy outside the provider
The single most valuable change to most backup setups is holding one copy with a different provider entirely. It does not need to be fast to restore or frequently updated; it needs to exist somewhere the loss of your main account cannot reach.
Object storage on a second provider is cheap and the S3-compatible API makes it straightforward to write to two destinations.
Snapshots, backups and archives are different things
| Type | Protects against | Does not protect against |
|---|---|---|
| Snapshot | Accidental change, bad deploy | Account loss, region loss |
| Backup in another region | Region failure | Account loss, credential compromise |
| Backup with another provider | Account loss, provider failure | Nothing much, if tested |
A complete setup usually has all three, because each is cheap relative to what it covers.
Test the restore, not the backup
A backup job reporting success proves a file was written. It does not prove the file is complete, readable, or sufficient to rebuild the system.
Restore to a scratch environment on a schedule and confirm the result actually works. This is the step that separates a backup strategy from a backup intention, and it is the one most often skipped.
Decide the two numbers
How much data can you afford to lose, and how long can you afford to be down? Those two figures determine backup frequency and what recovery method you need. Answer them explicitly rather than defaulting to whatever the provider suggests.
They also tell you when a nightly snapshot is genuinely sufficient, which for many systems it is.
Back up more than the data
- Infrastructure definitions, so the environment can be rebuilt rather than remembered
- Configuration and secrets, stored securely and separately
- DNS records, which are easy to overlook and painful to reconstruct
- TLS certificates and the process for reissuing them
- Documentation of the restore procedure, kept somewhere outside the account
Related cloud accounts
This guide applies across providers. The cloud account catalogue lists every platform with its configurations and prices, and the comparison table puts them side by side.
Further reading
- AWS vs Linode: Which Cloud Account Should You Buy?
- Setting Billing Alerts Before You Deploy Anything
- Deploying for Asia-Pacific Users
- DigitalOcean vs OVHcloud: Which Cloud Account Should You Buy?
Frequently asked questions
For accidental deletion, usually. They live inside the account, so they do not protect against losing the account itself.
Quarterly is a reasonable baseline for most systems, more often if the data changes rapidly or the recovery target is tight.
With a different provider. Another region on the same provider protects against a regional failure but not against account loss.
