Cloud Backups: What Your Provider Does Not Do for You

Cloud storage is extremely durable. Providers replicate data across devices
and often across facilities, and hardware failure is genuinely close to a solved
problem. People reasonably conclude from this that their data is safe, and then
discover that durability protects against precisely one category of loss and
their actual loss was a different category.

Durability is not backup

Durability means the provider will not lose your data through hardware
failure. It says nothing about the far more common causes of data loss:

• Someone deletes the wrong thing, and the deletion replicates perfectly to
  every copy.
• An application bug corrupts records over several days before anyone
  notices.
• Ransomware encrypts everything the compromised credentials could reach.
• The account is suspended and you lose access to all of it at once.

In every one of those, the data is durably stored and you still cannot get it
back. Backup is about recovering a previous state, which is a different problem
from storing the current one reliably.

What snapshots actually give you

Provider snapshots are a genuine and useful layer. They are fast, cheap and
easy to schedule, and they handle a large share of real incidents: a bad deploy,
a botched upgrade, an accidental deletion noticed the same day.

Their limits are worth stating plainly:

• They usually live in the same account, so an account-level problem takes
  them too.
• They are often tied to one region, so a regional outage covers both the
  volume and its snapshots.
• Retention is whatever you configured, and the default is frequently shorter
  than the time it takes to notice slow corruption.
• A snapshot of a running database can be inconsistent unless it was
  coordinated with the database.

So snapshots are the first layer, not the whole answer.

What a real backup strategy includes

The old guidance of three copies, two media types and one off-site still
works if you translate it for cloud:

Three copies: production, a snapshot or local backup, and
something stored elsewhere.

Two destinations: at minimum a different region. Preferably
a different provider or a different account, so that losing the account does not
lose the backups.

One genuinely separate: ideally with credentials that your
production systems do not hold. This is the specific control that defeats
ransomware, because compromised production credentials cannot reach a
destination they have no access to.

Several object storage services offer immutability or object lock, which
prevents deletion for a defined retention period even by an administrator. For
backups this is worth enabling.

Databases need their own handling

A volume snapshot of a running database may capture a half-written state.
Use the database’s own backup mechanism, which produces a consistent dump, and
keep point-in-time recovery enabled where the platform offers it.

Managed databases usually handle this well, which is one of the stronger
arguments for using one, as discussed in
managed databases vs running your
own. If you self-host, the backup job is yours to write, schedule, monitor
and verify, and the monitoring part is the one that gets skipped.

The test that matters

A backup you have never restored is a hypothesis.

Restore one. Into a separate environment, from the actual backup, following
the actual documented procedure. Do it now, while nothing is wrong, and time
how long it takes.

What this exercise reveals is consistently the same set of problems: the
backup was running but silently failing; it contains the data but not the
configuration needed to use it; the encryption key is stored only on the server
being restored; nobody except one person knows the procedure; or the restore
takes eleven hours and everyone assumed it was one.

That last point deserves its own thought. Knowing your recovery time is as
important as having the backup, because it is the number that tells you whether
your plan is adequate for what the business can tolerate.

A workable baseline

1. Daily automated snapshots with retention long enough to catch slow
   corruption, not just yesterday’s mistake.
2. Database dumps using the database’s own mechanism, on their own
   schedule.
3. A copy in a different region, and ideally a different account, with
   restricted credentials.
4. Immutability enabled on the off-site copy where available.
5. Monitoring that alerts when a backup job fails, because silent failure is
   the normal failure mode.
6. A restore test on a schedule, with the procedure written down.

Most of that is configuration done once. The restore test is the only part
that requires discipline, and it is the only part that proves the rest
works.