What to back up
The database. Use whatever your provider offers — automated RDS snapshots, Cloud SQL backups, orpg_dump on a schedule. Set retention to match your recovery objective. Everything is already encrypted at rest, so the backup carries no plaintext personal data.
The wrapping key. It does not change unless you rotate it, so this is a one-time capture — but it must survive the loss of the environment that holds it. Keep it in a secret manager, and keep the Shamir key shares somewhere else entirely.
The licence key. Recorded outside the database, so you can re-apply it during a restore without waiting on the portal.
Redis holds only transient session state and does not need backing up. Sessions are lost on restore; users sign in again.
Restoring
1
Restore the database
Restore the snapshot or dump into a database of the same engine. Databunker Pro does not need to be running.
2
Point a new instance at it, with the original wrapping key
Set
DATABUNKER_WRAPPINGKEY to the same value the vault used before. The instance is stateless — nothing else carries over.3
Confirm decryption works
A successful start proves the wrapping key unwrapped the master key. Read a known record to prove the master key still decrypts the data:
4
Re-apply the licence if needed
Check
SystemGetSystemStats — if licensemaxrecords reads 1,000 you are in Trial mode. See update the licence key.Recovery objectives
Two numbers to decide before you need them:- RPO — how much data you can afford to lose. Set by backup frequency. Daily snapshots mean up to a day of records; continuous archiving or point-in-time recovery narrows it to minutes.
- RTO — how long a restore may take. Dominated by database size, not by Databunker Pro. Restoring 585 GB (roughly 100 M records at ~5.7 KB each — see storage footprint) takes far longer than starting the application container.
Test the restore
An untested backup is an assumption. On a schedule, and ideally with someone who did not build the deployment:1
Restore into a scratch environment
Use a non-production licence key so the drill does not consume production record capacity.
2
Bring it up with the real wrapping key
This is the step that catches the most common failure — a wrapping key nobody can find.
3
Read records back and compare
Spot-check a handful against known values.
4
Record how long it took
That number is your real RTO.
Exporting every record
Databunker Pro deliberately blocks bulk retrieval so a stolen token cannot dump the vault. A legitimate full export therefore goes through a specific, audited path rather than aSELECT *.
BulkListAllUsers pages through every record. It requires the list_users configuration flag, a main-tenant admin token, and a short-lived unlock UUID obtained immediately beforehand — and every call is written to the audit trail.
BulkListTokens, and audit events via BulkListAllAuditEvents.
What is not recoverable
Backups protect against losing the database. They do not protect against losing your keys. If the wrapping key is gone and fewer than three Shamir shares remain, the data cannot be decrypted — not by you, and not by Databunker. There is no escrow and no vendor copy of your keys, which is the same property that means a breach of our systems cannot expose your data. See what is recoverable for the full matrix.Next steps
- Wrapping key rotation — the recovery matrix and the rotation runbook
- Shamir key shares — custody and the three-share threshold
- Production checklist — the go-live gate that includes these items