Cloud Parts

Backup & restore

Copies of your data kept apart from the original, so you can get it back after a deletion, corruption, ransomware or a lost region.

3 technologies on this page ↓
Live model
What you’re watchingThe app writes through one database address. The primary appends each write to its log, and an archiver ships the log in batches to locked object storage in region B; the “behind” count is what a disaster would lose (the RPO). When region A fails, writes fail until a new database has been restored from the backup and the address points at it (the RTO). Then the loop starts over.

How it works

A backup is a copy kept somewhere the original can’t take down with it. A full backup copies everything; an incremental copies only what changed since the last backup, and a differential what changed since the last full one. Nightly backups stay small, but a restore needs the full backup plus every piece after it. A snapshot freezes a disk or volume at one instant by tracking changed blocks. Kept on the same disk, array or file system, it dies with the original and isn’t a backup; Amazon EBS snapshots count because they’re stored separately in S3, though they still sit in the same account and region until you copy them out. Databases add point-in-time recovery: restore a base backup, replay the write-ahead log (WAL) archived since, and stop just before the mistake. Two numbers set the design: the recovery point objective (RPO), how much recent data you can afford to lose, and the recovery time objective (RTO), how long you can afford to be down. The 3-2-1 rule asks for three copies, on two kinds of media, one of them off site. Because ransomware hunts for backups to delete or encrypt, keep at least one copy offline or immutable, locked so that nobody, not even an administrator, can delete it before a set date. And test restores on a schedule: a backup you’ve never restored is a guess.

Think of it as

A copy of your passport kept in a different bag. Keep it in the same bag (a snapshot on the same disk) and one thief takes both, and you only find out the copy is unreadable on the day you need it.

Reach for it when

  • Any data you can’t recreate: databases, uploaded files, cluster and configuration state
  • Undoing mistakes that replication faithfully copies, like a dropped table, a bad migration or a corrupted file
  • Ransomware and stolen credentials: a locked copy the attacker can’t delete
  • Rules that require keeping records for a fixed number of years

Think twice when

  • Staying up through a failure: a restore takes minutes to hours, so use replicas and failover for that, and backups for what replicas can’t undo
  • Data you can cheaply rebuild from its source, such as caches, build outputs and derived tables

A real example

A shop runs PostgreSQL in one region. pgBackRest takes a full backup every Sunday and an incremental every night, and archives each WAL file as it fills, with archive_timeout = 60s, to an S3 bucket in a second region with Object Lock. At 09:42 a migration drops the orders table: the team restores Sunday’s full backup and the incrementals onto a new server, replays WAL up to 09:41, and loses no orders. If the whole region went down instead, the same restore would run in the second region and lose at most about a minute of orders, the WAL not yet archived (the RPO); the time spent copying data back is the RTO.

Technologies

Specific products, and what each does differently.

What each provider calls it

AWS
AWS Backup (backup vaults, cross-Region copy, Vault Lock, restore testing); EBS snapshots; RDS automated backups and point-in-time restore; S3 Object Lock
Google Cloud
Backup and DR Service (backup vaults with enforced retention); Compute Engine disk snapshots; Cloud SQL point-in-time recovery
Azure
Azure Backup (Recovery Services vaults and Backup vaults, immutable vaults), including AKS backup
Open source & others
Velero (Kubernetes); restic, Kopia, BorgBackup (deduplicated file backups); pgBackRest, WAL-G, Barman (PostgreSQL); rsync for plain copies

In code · bash

# postgresql.conf: hand every finished WAL file to pgBackRest
#   archive_mode = on
#   archive_command = 'pgbackrest --stanza=main archive-push %p'

# a full backup on Sunday, incrementals on the other nights
pgbackrest --stanza=main --type=full backup
pgbackrest --stanza=main --type=incr backup

# the orders table was dropped at 09:42: with PostgreSQL stopped,
# restore the latest backup and replay WAL up to 09:41
pgbackrest --stanza=main --delta --type=time \
  "--target=2026-10-06 09:41:00+00" --target-action=promote restore

Often confused with

Object storageBlock storageRelational databasesContainer orchestration
Where it came from1953–2019

For most of computing history a backup meant tape. In 1953 IBM introduced the vacuum-column tape drive for its 701 computer, and for more than 30 years magnetic tape dominated offline storage: cheap per byte, and easy to carry off site. Unix made the routine explicit. In Seventh Edition Unix (1979), dump copied to tape every file changed since the last dump at a lower level: level 0 copied everything, higher levels only the changes, the full-plus-incremental scheme still in use.

Networks and databases changed what a copy could be. In 1996 Andrew Tridgell and Paul Mackerras described rsync, which updates a remote copy over a slow link by sending only the parts that differ. PostgreSQL 8.0 (2005) added WAL archiving and point-in-time recovery, so a database could be backed up continuously and restored to any moment. restic (first released in 2015) and BorgBackup (forked from Attic in 2015) split files into content-defined chunks and store each chunk only once, so every backup reads as a full one but stores only what changed.

The cloud made snapshots an API call: Amazon EBS launched in 2008 with snapshots stored in S3, and AWS Backup (2019) put one policy over many services. Then ransomware changed the threat. Many variants look for reachable backups and delete or encrypt them before demanding payment, so the answer became copies that nobody can delete before a date: S3 Object Lock (2018), AWS Backup Vault Lock, and immutable vaults in Google Cloud and Azure.

Why it’s built this way

A full copy, then only the changes
Copying everything every night takes too long and too much tape. Dump levels copied only files changed since a lower-level dump, at the price that a restore needs every piece of the chain.
Keep a copy somewhere else
A fire, a theft or a failed disk takes everything kept in one place, including backups on the same drive. The 3-2-1 rule, from photographer Peter Krogh’s The DAM Book and adopted by US-CERT, asks for three copies on two media with one off site.
A base backup plus the log, not frequent full copies
Replaying archived WAL over one base backup gives continuous protection without a perfectly consistent snapshot, and replay can stop at any moment, which turns a backup into a time machine.
Make the copy impossible to delete
Once attackers began deleting backups before encrypting data, keeping a copy was no longer enough. Write-once retention locks put a copy beyond the reach of a stolen administrator account.

Timeline

  1. 1953

    IBM introduces the vacuum-column tape drive with the 701

  2. 1979

    Seventh Edition Unix ships dump with incremental levels 0 to 9

  3. 1996

    Tridgell and Mackerras publish the rsync algorithm

  4. 2005

    PostgreSQL 8.0 adds WAL archiving and point-in-time recovery

  5. 2008

    Amazon EBS launches with snapshots to S3

  6. 2015

    restic and BorgBackup bring deduplicated, chunked backups

  7. 2018

    S3 Object Lock offers write-once retention for backups

  8. 2019

    AWS Backup launches

Sources26

Improve this page on GitHub