Available
PostgreSQL
pg_dump · one snapshot · parallel streams
Whole databases, or leave out schemas and tables. Backups run on your private host and restore checks rebuild the copy in a sandbox.
Restore-verified PostgreSQL backups · preview
Backups you’ve actually restored. Not just stored.
BackupSanity runs your PostgreSQL backups from a small host on your own network, keeps the copies where you choose, and only calls a source healthy after a copy has been restored and checked.
The demo runs in your browser with sample data. No sign-up needed.
$ backupsanity run production-db
→pg_dumpdone4 streams · one snapshot · zstd:3
→encryptdoneAES-256-GCM · key stays on the host
→copydonebucket + ssh://nas · sha256 each
→restoredonesandbox · no network · no mounts
→verifyoktables and row counts match
→cleanupdonesandbox removed · confirmed
✓ recoverable · restored into a new copy, then removed
- Source access
- Read only. No restarts, no failover.
- Destination
- Your bucket, or hosted storage.
- Restore target
- Always a new copy. Never the source.
- Healthy means
- The restore check passed.
How it works
The job doesn’t end at “backup complete.”
Every plan follows the same three steps. The last one is the one that counts, and the one most backup tools skip.
- 01
Read the source.
A read-only role and one consistent snapshot. No restarts, no failover. The host backs off before its locks would block your maintenance.
source → snapshot - 02
Keep it somewhere else.
Encrypted, checksummed and written to the storage you pick: a bucket, your own SSH server, or a directory on the host. Retention sets how many copies stay.
snapshot → storage - 03
Prove it restores.
Rebuild a copy in a sandbox with no network, compare tables and rows, then remove it. Only a passing check marks the source healthy.
storage → verified copy
Works today
Runs on your network. Reports to one place.
Everything below works now for PostgreSQL on a private host you run. Hosted workers, billing and alerts are still being built, and this page says so wherever it matters.
A small host on your network
A Proxmox VM or any Linux machine runs the runner. It connects out over HTTPS, so nothing needs to reach in. Database passwords stay in its local config.
Fast, careful dumps
Several pg_dump streams read one consistent snapshot. Compression adapts to what the host can sustain, and a lock watchdog stops a backup before it blocks maintenance.
Storage you choose
S3-compatible buckets, your own SSH or SFTP server, or a directory on the host. One plan can write to several at once.
Reaches what you have
Over your LAN, an existing VPN, or SSH jump hosts. A path check measures every hop and tells you what would make it faster.
Encrypted before it leaves
Each source has its own archive key. Archives are checksummed on upload and read back before a copy counts.
Plans, logs and checks
Schedule each plan, watch progress and time left, read the full log, and turn on an automatic restore check after every backup or once a day.
Evidence, not vibes
What a restore check proves. And what it doesn’t.
A private host restores one exact archive into a digest-pinned PostgreSQL container with no network, no source credentials and no host mounts. It reports evidence only after the sandbox is gone.
Join the waitlistChecked
- Archive decodes completely
- SHA-256 matches what was uploaded
- Restores into an isolated copy
- User-table row counts
- Sandbox removed before success
Not implied
- Offsite durability
- Your application’s own assertions
- A full database, from a limited backup
- A healthy source, from a connection check
Sources
Different sources. The same recovery standard.
PostgreSQL is first because a restore check can prove it. Other sources arrive once their copies can be checked the same way.
Planned
MySQL & MongoDB
Logical dumps
The same plan, storage and restore-check model. Not available yet; the setup can save them so you can see the plan.
Planned
Servers & folders
SSH · Docker · selected paths
Application data needs an application-aware snapshot to be consistent, so these wait until that can be checked too.
Single-file databases are refused. Files copied while an application is writing are not automatically consistent.
Try it
Practice recovery. Before you need it.
Run a sample restore check right here. Then open the full workspace to back up, fail a check on purpose, and recover to a new copy.
Open the full workspaceproduction-db
Postgres 17 · US East
Sample snapshotToday, 01:00 UTC
Sample size8.42 GB
Destination Your bucket
Restore verification
Isolated scratch- Allocating isolated scratchWaiting
- Restoring sample snapshotWaiting
- Checking tables and recordsWaiting
- Removing scratch resourcesWaiting
A saved snapshot. Still waiting for proof.
Interactive example · Sample data only · No live backup
Pricing
Small bill. Full explanation.
Your own host and storage aren't billed. Hosted storage and managed hosts are priced per provider and region, measured daily and billed monthly within a spending cap.
Your host, your storage
Our runner on your machine$0during the beta
The runner backs up from inside your network and writes to a bucket, SSH server or disk you own. We don't bill any of it.
- Scheduled backups, encrypted with each source's key
- Restore checks in a sandbox on your host
- Your provider bills its own storage
Hosted storage
No bucket to createfrom $0.019/ GB-month
A folder of your own at the provider you pick, priced per provider. Keep fewer copies, pay less.
- Cloudflare R2: $0.035 / GB-month
- Backblaze B2: $0.019 / GB-month
- Wasabi: $0.02 / GB-month
- Amazon S3: $0.055 / GB-month, reading back $0.15/GB
Managed host
For databases on the internetfrom $0.05/ started hour
We start a server in your region when a backup or restore check is due and delete it when it's done. A daily backup is usually one started hour.
- $0.05 to $0.13 per started hour, by region
- Inside AWS beside RDS: data sent out $0.10/GB, free to hosted S3 in the region
- Elsewhere, transfer included ($0.03/GB if a fallback server runs it)
Proposed launch prices, in USD before taxes. Hosted storage and managed hosts need a card; charges stop at your monthly spending cap ($50 unless you change it).
A few things worth knowing.
Is BackupSanity protecting live data yet?
Yes, for PostgreSQL on a private host you run. Invited accounts back up real databases on their own Linux or Proxmox machines, on a schedule, to their own storage, with optional restore checks. Hosted workers, billing and failure alerts are still in development. The public demo uses labeled sample data.
What do I need to run?
One small Linux machine that can reach your database: a Proxmox VM the kit creates, or an existing host. It needs outbound HTTPS and a route to the database. Database credentials go into its local config and never reach BackupSanity.
Can I use storage I already own?
Yes. S3-compatible buckets, your own SSH or SFTP server (BackupSanity generates the access key and pins the server’s host key), or a directory on the host itself. Your provider bills storage, requests and transfer separately.
What does “read the source” mean?
The design avoids restarting services or overwriting source data. Logical dumps still use resources and may take database locks. Mutable files and live application volumes need consistency safeguards; a read-only copy alone is not proof of a usable backup.
Where will my data be stored and checked?
The proposed regions are US East, Frankfurt, and Singapore. Choose workers near the bucket to reduce transfer. Account metadata has its own database region. A location hint is not a residency guarantee; strict residency needs an explicit jurisdiction and matching worker placement.
Know what you can recover.
Run the demo