Skip to main content
A Databunker Pro backup is only complete if it covers three artefacts. Miss any one of them and the restore fails.
A database backup on its own is worthless. Every record in it is encrypted with the master key, which is itself encrypted by the wrapping key — so a restore without the wrapping key produces a vault full of unreadable ciphertext. Back up both, and store them separately.

What to back up

The database. Use whatever your provider offers — automated RDS snapshots, Cloud SQL backups, or pg_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 a SELECT *. 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.
The output is decrypted personal data in plaintext — the one artefact in this guide that is not protected by the vault. Write it to encrypted storage, restrict who can read it, and delete it when the migration or portability request it was created for is complete.
Format-preserving tokens export separately via 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