Databases
Databases with backups you have seen restored.
Unrent runs Postgres 17 and 18 with continuous WAL archiving to a bucket at another provider, so you can restore to any second in your backup window. Restore drills restore a backup, check the data and show you the evidence; MySQL 8.4 and Valkey 9.1 get verified nightly backups.
- Point-in-time recovery
- WAL archived to the off-site bucket
- Last drill
- passed · restored in 1 min 48 s
- Data at risk at the drill
- 41 s
- Checks
- row counts, pg_amcheck, connections
- Stored at
- acme-backups · another provider
Engines
| Engine | Versions | Backups | Restore |
|---|---|---|---|
| Postgres | 17, 18 | WAL-G continuous archiving, plus a verified base backup every day | Any point in time, into a scratch copy; promote with a passkey |
| MySQL | 8.4 | Nightly mysqldump, verified in the bucket, 14 kept | The newest dump before a time, into a read-only scratch copy |
| Valkey (Redis-compatible) | 9.1 | Nightly RDB snapshot, verified in the bucket, 14 kept | The newest snapshot before a time, into a scratch copy |
Coming MariaDB, SQLite with Litestream, point-in-time recovery for MySQL, and deleting a database with a final backup.
Backups that count only when they are in the bucket.
A backup is successful when Unrent has listed it and read it back in your storage, not when a command exits 0. Storage is any S3-compatible bucket: Amazon S3, Cloudflare R2, Backblaze B2 or your own.
Adding or changing where backups go is a policy change: it needs an admin and a passkey approval that your server verifies. A compromised Unrent cannot point your backups at its own bucket.
- A probe writes, reads and deletes a test object before a bucket is used
- Alerts when a backup is late or failing
- Storage credentials are sealed in your browser to the server
Restore drills
A drill proves a backup restores, and measures how much data you would lose.
- 01
Write heartbeats
The drill writes marker rows before and after a moment T, then waits until that WAL is archived.
- 02
Restore to T
It restores to T in a scratch container, never touching production.
- 03
Check
Rows before T are there, none after it;
pg_amcheckpasses; every database accepts connections. - 04
Report
You see the result, the restore time and the data at risk next to the database. A failed drill raises a critical alert.
Coming Weekly drills on a schedule. Today a drill starts from the console or the API.
Credentials Unrent never sees
Database passwords are generated on your server and sealed back to it. Linking a database to a service writes DATABASE_URL (or REDIS_URL) into the service’s secrets without the password ever existing in clear outside the server.
Rotating a password sets a new one on the server and applies it to every linked service at once.
Questions
How far back can I restore Postgres?
To any second covered by the WAL archive since the oldest base backup you keep in your bucket. Archiving runs at least once a minute.
Where are backups stored?
On the server by default, and in any S3-compatible bucket you add. The console warns you while a database only backs up to its own disk.
What happens to production when I restore?
Nothing, until you promote. A restore goes into a separate, read-only scratch copy that expires after 1 to 48 hours. Promoting it needs a passkey, and the old production database is kept for up to 30 days.
Your servers, your keys. Start with one free server.
The first server is free, then $2 per server per month, with nothing gated.