Backed up. And proven.
Continuous archiving to two independent repositories in two EU countries, recovery to any second in your retention window, and automatic restore tests that show you your backups actually work.
Example view with sample data.
Most backups are a hope.
A backup job that succeeds tells you a job ran. It doesn’t tell you what matters.
Will it restore?
Most teams find out whether a backup restores on the worst day to find out: during the incident.
How much would you lose?
“We back up nightly” means up to a day of writes gone. The real question is how recent the last point you can actually restore to is.
Is the copy really separate?
A backup stored next to the database, or copied from a single source, can be lost with it.
How it works
From every change to a verified restore.
Your service hands every change to a separate backup server, which writes it to a repository in Germany and, independently, to a second repository in France. On a schedule set by your database size, Balta restores a real backup into an isolated environment, replays every change, starts PostgreSQL and checks it.
Point-in-time recovery
Restore to 14:02. Into a new service.
Someone ran the wrong migration. A customer deleted the wrong records. Pick the exact second before it happened, and Balta restores your data into a new service with its own connection address — while your production database keeps serving everyone else.
Need to rewind the live service instead? That’s a separate, deliberate path. It shows you exactly which changes will be discarded, takes a safety backup first, and asks you to confirm by name.
- Any second inside your retention window
- A new service, so production keeps running
- Rewinding production is deliberate and reversible
Example view with sample data.
Verification
Restores we actually run.
On a schedule based on your database size, Balta takes one of your real backups, restores it into an isolated environment, replays every change, starts PostgreSQL and checks it — then records how long it took.
You see when your data was last proven recoverable, not just when it was last backed up. A test also runs within 48 hours of your first backup, and after every plan, storage or major version change.
| Database size | Full restore test |
|---|---|
| Up to 50 GiB | Every 7 days |
| 50 to 250 GiB | Every 14 days |
| 250 GiB to 1 TiB | Every 30 days |
| Over 1 TiB | Every 60 days, plus a monthly point-in-time test |
A test also runs within 48 hours of your first backup, and after every plan, storage or major version change.
Recovery point
A recovery point you can actually restore to.
Your recovery point is the latest moment we could really restore you to — not the time of the last upload. That takes a verified backup and an unbroken chain of changes after it. Balta checks that chain continuously, separately for each repository, and shows you both.
Under normal operation it stays at five minutes or better, and that commitment is written into our SLA. If PostgreSQL simply restarts on a healthy host, your recovery point is zero — recent changes are still on local storage and are replayed.
Example view with sample data.
Security
Backups kept apart from your database.
- Backups are written by a separate process, not by your database
- Your database never holds a storage credential
- Each service’s backups are encrypted with their own key
- Each service reaches its own backups and no other service’s
- A full backup weekly, a differential daily, every change in between
- Keep 7, 30, 90 or 365 days of history — 30 by default
- Backups expire automatically at the end of your window
Questions about backups.
Do I have to set anything up?
Where are my backups stored?
Can I restore without affecting production?
What happens to data I delete?
Early access is open. Tell us about your workload and we’ll reserve your place.