What is Disaster Recovery and how do I set it up?

Why it matters

Your account backups are on the destination, but BackupWall's database (jobs, destinations, backup points) and its master key exist on this server only. If the server dies first, BackupWall loses its list of jobs, destinations and points, and encrypted backups can never be read again. A DR bundle holds both. It does not hold any account data. If you use Encrypt backup data, DR is not optional.

DR ships off, and BackupWall never picks the passphrase for you.

Set it up

1. Open Settings → Disaster Recovery.
2. Under "DR passphrase", enter a New passphrase (at least 12 characters) twice and choose Set passphrase. Save it somewhere safe first.
3. Under the schedule card:
   • Switch on Enable scheduled DR exports.
   • Choose a Destination. Use one that is not this server's own disk: a bundle on a lost server is lost.
   • Set the start time (server time) and Keep last N copies (default 14).
   • Choose Save DR schedule.
4. Under "Recent exports", choose Export now. Wait for the row to show OK, with a size and a checksum.
5. Make sure the row has no not restorable warning. That warning means the bundle was made without backupwall.env (the master key), which makes it useless. It usually means the backup service could not read /etc/backupwall/backupwall.env.

DR counts as set up only when all three are done: a passphrase, a destination and scheduled exports switched on. curl -s http://127.0.0.1:8087/api/v1/health/ready then shows "dr_configured": true.

The passphrase

• It is never stored on the server. Only a key derived from it is kept (encrypted at rest with the master key) so the unattended nightly export can run.
• If you lose it, every bundle sealed with it is permanently unopenable. There is no recovery, no reset and no support override. That is the design.
• Keep it in a password manager that does not live on this server.
• Changing it does not re-key old bundles: each bundle carries the salt it was sealed under. Keep the old passphrase until those bundles age out of retention.

Where bundles are stored

On the destination as dr/<server-id>/backupwall-dr-<date>-<time>.bwdr. On an S3 destination with a path prefix, that is inside the prefix (<prefix>/dr/<server-id>/). 14 bundles are kept by default.

Test a bundle

This writes nothing and is safe on a live server:

bw-dr-restore --bundle /path/to/backupwall-dr-<date>-<time>.bwdr --dry-run

It asks for the passphrase and says "dry run OK" if the bundle opens. BackupWall cannot fetch the bundle for you: download it from the destination with your own tool first (S3 console, aws, rclone, sftp). Repeat the test every so often.

Warnings until it is set up

• The Dashboard shows a "Disaster Recovery is not set up" warning (you can snooze it for a day) and a "DR not set up" badge appears at the top of every page until it is done.
• If any job has Encrypt backup data on, a notification goes out once, then weekly: by email (if email alerts are on) and to every Slack, Discord or webhook channel with All events or Disaster Recovery not set up (weekly).
• The installer prints a reminder.

What the bundle does not hold

The TLS certificate and key: a rebuilt server gets a new certificate and fingerprint, so other BackupWall servers linked to it must pin the new one in Settings → Peering. It also does not hold account data, or anything outside BackupWall's own state.