New · Release 2026.04, Multi-tenant audit exports & SLA dashboards now liveSee changelog →
Business continuity
Backups and disaster recovery you can actually prove
Scheduled encrypted PostgreSQL backups with retention and pruning, plus a weekly automated restore drill that restores into a throwaway database and logs recovery time (RTO) and backup age (RPO).
Product illustration · sample data
Infrastructure / Live
142/142 healthy
CPU avg
34%
Memory avg
62%
api-prod-01.acme.io98ms
db-primary.acme.io12ms
worker-eu-03.acme.ioSSL expires 14d
Product proof
Already live in the product
Backed by app modules
Running in production today: real database backup jobs and a scheduled restore drill that proves recoverability.
Protected app route: /backups
How it works
Built around real workflows
Highlights below describe capabilities already present in the protected app behind this page.
Scheduled encrypted database backups
Retention and automatic pruning
Weekly automated restore drill
Recovery time (RTO) and backup age (RPO) logged
Workflow
What teams can do here
Step 1
Set a backup policy
Step 2
Backups run on schedule
Step 3
Weekly drill verifies recoverability
Step 4
Review RTO/RPO evidence
How it works
How it works
01
Set a backup policy
A platform-wide policy controls whether backups run and how many are kept — a retention count (14 by default) plus an age cap in days (30 by default) after which older successful backups are pruned.
02
Run backups on schedule
A scheduled job takes a real pg_dump of the database, records its size and a SHA-256 checksum, and stores it. If no policy exists at all it still runs with safe defaults rather than silently doing nothing.
03
Prove recoverability weekly
A weekly restore drill creates a throwaway database, restores the latest backup into it, and verifies the tables and row counts loaded — then drops it. It never touches the live database.
04
Review RTO and RPO evidence
Each drill logs recovery time (RTO, how long the restore took) and backup age (RPO, how old the restored backup was), so disaster-recovery readiness is measured, not assumed.
Example
A worked example
Say a diagnostics-lab chain is going through an ISO-style audit and the assessor asks the classic question: "when did you last prove a restore works?" The retention policy keeps the last 14 dumps and prunes anything past 30 days. Every week the restore drill spins up a throwaway database, loads the newest dump, verifies the restored table count sits within range of the live schema, and drops the temp database again. The lab's answer is a drill history: RTO of a few minutes, RPO under a day, week after week — evidence on a screen instead of an assurance in a meeting.
FAQ
Frequently asked questions
What exactly gets backed up?
The platform PostgreSQL database — the data behind your workspace — via real pg_dump jobs. Backups are a platform-wide operation, and each job records its file size and a SHA-256 checksum.
How do you know a backup can actually be restored?
A scheduled restore drill restores the latest backup into a fresh throwaway database, counts the tables and rows that loaded, and only passes when the restored table count is at least about 90% of the live schema — catching a partial restore that a naive check would wave through. The temporary database is always dropped afterwards.
What do RTO and RPO mean here?
RTO is recovery time — how long the drill took to restore. RPO is the age of the backup that was restored. Both are logged on every drill so you can show how quickly you could recover and how recent the data would be.
How is retention controlled?
The policy keeps a fixed number of recent backups (14 by default) and also drops successful backups older than a set number of days (30 by default). Pruning runs as its own task so old dumps do not pile up.
Does the restore drill risk my live data?
No. The drill only ever creates and writes to a uniquely named temporary database and drops it at the end. The live database is never the restore target, so verification cannot disturb production.
What happens when a drill fails?
The drill run is recorded with its outcome, so a restore that would not complete shows up in the drill history the week it happens — while there is time to fix the backup chain — rather than being discovered during an actual disaster.
What can I hand to an auditor from this module?
The backup history with sizes and SHA-256 checksums, the retention policy in force, and the weekly drill log with measured RTO and RPO per run — a recoverability record built from executed restores, not a written procedure.
Would your backup actually restore? Prove it weekly
Checksummed pg_dump backups on a retention policy, plus an automated weekly restore drill that measures real RTO and RPO — recoverability as a logged fact, not an untested assumption.