Cloud storage is durable, which leads people to conflate durability with safety. Durability protects against hardware failure. It does nothing about a mistaken deletion, a bad migration, or ransomware, all of which replicate faithfully.
Decide the two numbers first
-
Recovery point objective
How much data you can afford to lose, which sets backup frequency.
-
Recovery time objective
How long you can afford to be down, which sets the restore mechanism.
These are business decisions, not technical ones. Once agreed, they determine the design; without them, backup discussions run in circles.
A workable arrangement
- Automated backups on a schedule matching the recovery point objective.
- At least one copy in a different account or location, not reachable by the workload.
- Retention with a mix of recent and longer-term points.
- Encryption in transit and at rest, with the key managed separately.
- A documented restore procedure anyone on the team can follow.
- Scheduled restore tests, with the duration recorded.
Protect against deletion, not only failure
| Risk | Control |
|---|---|
| Accidental deletion | Versioning and soft delete. |
| Malicious deletion by an admin | Separate account, restricted delete permissions. |
| Ransomware | Immutable or object-locked copies. |
| Silent corruption | Restore tests that verify content, not just completion. |
| Region-wide outage | A copy in another region. |
| Provider account loss | A copy outside that provider, for critical data. |
Back up configuration as well as data
Restoring a database into an account with no networks, no DNS and no deployment pipeline is a slow afternoon. If infrastructure is defined in code and that code is stored outside the account, recovery becomes a matter of running it. That is often the difference between hours and days.
Summary
Agree the two objectives, keep copies where the workload cannot reach them, make deletion hard, and test restores on a schedule. An untested backup is not a backup.
