How backups work
Base backups plus continuous write-ahead log archiving, to two repositories in two countries, with credentials your database runtime never holds.
Every service is backed up continuously: full physical copies on a schedule, plus every write-ahead log segment as it is filled. There is no option to turn it off and no plan without it.
You do not start a backup. What you do is read whether the chain is healthy, and the Backups tab is where that is.
Read your backup state
- Open the service.
- Select the Backups tab.
Four readings sit at the top:
| Reading | What it answers |
|---|---|
| RPO exposure | How much data you could lose right now |
| Last backup | When the last base backup completed |
| Last verified restore | When a backup was last proven restorable |
| Retention | How far back the chain goes |
Last backup and Last verified restore are different facts, and the second is the useful one. A backup job that exits zero has proved that a backup job exited zero. See restore verification.
What is taken
Two things, together:
- Base backups — a full physical copy of the database, taken on a schedule.
- Write-ahead log archiving — every WAL segment, shipped continuously as it is filled.
A base backup alone gets you back to the moment it was taken. The archived WAL is what lets you replay forwards from there to any point since, which is what makes point-in-time recovery possible.
Two repositories, two countries
Backups are written to two repositories, and the second is in a different country from the first. Both receive every base backup and every WAL segment.
That is what allows your data to survive the loss of an entire location. It also means your data is not confined to a single country. The country pairs for each location are published on the locations page before you buy.
The credentials are not in your database
This is the design decision on this page that matters most.
The backup process holds the credentials for the backup repositories. Your database runtime does
not. The per-service configuration your archive_command reads carries no repository credential at
all: it points at a local backup server and authenticates with a certificate that authorises one
stanza and no other.
The path is split so that the identity that writes backups cannot delete them, and the identity that expires old backups under the retention policy does not run on a database host.
The consequence: a compromised database cannot destroy its own backup history. An attacker who gets code execution inside your PostgreSQL instance has your current data, which is bad, and no route to the record of your data as it was yesterday, which is the difference between an incident and a company-ending one.
When archiving stalls
archive_command fails closed. If the backup server is unreachable, WAL accumulates in the service's
own pg_wal rather than being discarded. Losing a segment would break the chain and make every point
after it unreachable, so the safe direction is to keep it and run out of space.
A stalled archive is graded Severity 1, because the recovery point commitment is suspended and storage is filling.
What you will see
On the Backups tab: the base backups themselves, newest first, with the last verified restore
beside them. On Overview, Last verified restore reads Not measured yet until the first
verification completes.
RPO exposure is computed from the chain rather than from the last upload timestamp, and shows an explicit unknown when the evaluation is stale. An unknown that says so is more useful than a number that is quietly wrong.
Troubleshooting
Last backup is recent and Last verified restore is not. That is normal between verification
runs. The cadence follows database size. See
restore verification.
RPO exposure reads unknown. The evaluation is stale rather than the chain being broken. It refreshes on its own.
No backups yet. A service that has just been created has not taken its first base backup. The first restore verification follows within 48 hours of it.
Your volume is filling and nothing explains it. Check pg_wal. A stalled archive accumulates WAL
on local storage by design.