# 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.

URL: https://unrent.dev/features/databases/

## Engines

Database engines and how each is backed up

| 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.

1. **Write heartbeats.** The drill writes marker rows before and after a moment T, then waits until that WAL is archived.
2. **Restore to T.** It restores to T in a scratch container, never touching production.
3. **Check.** Rows before T are there, none after it; `pg_amcheck` passes; every database accepts connections.
4. **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.