Backups and Snapshots: The Difference, and Why It Matters

A snapshot sitting in the same account, in the same region, on the same provider as the thing it protects is not a backup. It is a convenience.

It covers the case where you delete a file. It does not cover account compromise, accidental account deletion, a region-wide incident, or ransomware that has the same credentials your automation does.

Snapshots and backups are different tools

Use both. Snapshots for fast rollback, backups for actual recovery.

Start from objectives, not from a schedule

Two numbers drive everything, and most teams have never written them down:

Recovery Point Objective (RPO) — how much data you can afford to lose, measured in time. An RPO of one hour means backups at least hourly.

Recovery Time Objective (RTO) — how long you can afford to be down. An RTO of four hours rules out anything that takes six hours to restore.

Write both down, per system. They will differ: a transactional database and a static marketing site do not deserve the same treatment, and pretending they do wastes money on one and under-protects the other.

The rule worth following

The classic 3-2-1 formulation still holds, adapted for cloud:

• 3 copies of the data.
• 2 different storage types or media.
• 1 copy in a separate failure domain — a different region, a different account, or a different provider entirely.

That last point is the one that matters most and is most often skipped. A backup in the same account as the primary shares the account's fate. If credentials are compromised, so is the backup.

Practical implementations:

• Backups written to a separate account whose credentials the production environment does not hold.
• Backups written to object storage with versioning and object lock enabled, so they cannot be deleted or overwritten within the retention window even by a valid credential.
• Backups replicated to a different region, and for critical data, a different provider.

Object lock is the single most valuable ransomware control available in cloud storage, and it is usually a checkbox.

Database backups specifically

Filesystem snapshots of a running database can capture an inconsistent state. Use the engine's own mechanisms:

• PostgreSQL: pg_dump for logical backups, plus continuous WAL archiving for point-in-time recovery.
• MySQL: mysqldump or xtrabackup, plus binary logs for point-in-time recovery.
• Managed services: use the provider's automated backups, and also export independently. A managed backup lives inside the account it is protecting.

Point-in-time recovery is the difference between losing a day and losing a minute. For transactional data it is usually worth the storage.

Restore testing is the only proof

An untested backup is a hypothesis. The failure modes are mundane and common: the backup was empty, the retention window had already expired, the restore needed a credential nobody had, the process took nine hours and the RTO was two.

Test on a schedule:

1. Quarterly at minimum, and after any change to the process.
2. Restore to an isolated environment, never over production.
3. Time it, and compare against the RTO.
4. Verify the data, not just that the restore completed — row counts, recent records, application startup.
5. Document the procedure so it can be executed by someone who did not write it, at three in the morning.

Object storage is the natural backup target: cheap, durable, and available on essentially every provider in S3-compatible form, which keeps the tooling portable. The storage guide covers the trade-offs.

Retention that is defensible

• Short-term frequent snapshots for operational rollback — hours to days.
• Daily backups retained for weeks.
• Weekly or monthly backups retained for months, where the data justifies it.
• A documented deletion policy. Personal data retained indefinitely is a data protection problem, not a safety margin. Retention must be justified, not maximal.

Frequently asked questions

Are managed-service backups enough? They are good and they live inside the account they protect. For anything critical, export independently to a separate failure domain as well.

How long should backups be kept? Long enough to recover from a problem discovered late, short enough to satisfy data protection obligations. Write the policy down and automate it.

Does versioned object storage replace backups? It protects against overwrite and deletion within the retention window, which is a large part of the problem. Combine it with object lock and cross-region replication for the rest.

What is the most common backup failure? Discovering at restore time that the backup was never valid. Testing is the only thing that prevents it.

The incident readiness guide covers what to do when a restore becomes necessary.

Object storage for backup targets is available on essentially every provider in the catalogue, which keeps the tooling portable.