Appliance Disaster Recovery

Settings, Disaster Recovery protects the SHA itself - not your workloads. Workload disaster recovery (replication patterns, failover, Sendense Controllers) is documented under Recovery & DR; this page is about making sure the appliance that orchestrates all of that can be rebuilt if it is lost.

It owns two estate-wide concerns: recovery bundles - automatic, encrypted daily snapshots of the SHA's configuration and its metadata database, delivered into every eligible backup repository so a destroyed appliance can be rebuilt from any surviving copy - and the replication concurrency limits that cap how many DR syncs run in parallel.

The recovery secret is the encryption passphrase for every recovery bundle. It is created during first-time appliance setup and shown once. Until it is configured, scheduled bundle automation is disabled entirely and manual bundles fail - the page shows a red notice while the secret is missing.

Each bundle contains the appliance's encryption key material, a configuration snapshot including the repository inventory, and a consistent recovery point of the appliance's metadata database - full or incremental. Bundles are encrypted with AES-256 using a key derived from the recovery secret.

Delivery targets are chosen automatically: every enabled local or network-share backup repository, plus every active EBA repository, receives a copy. You do not pick targets - repositories are configured on the repositories page, not here.

Retention is fixed at seven days and is not configurable. Within a chain, a fresh full anchor is forced when the previous chain is older than seven days, exceeds 48 incrementals, or is unusable.

Scheduled bundles run daily at a time you choose (default 02:00 UTC). Enter the run time as HH:MM and the timezone as a standard region/city name - unrecognized timezone names are rejected on save. A Use browser timezone helper fills the field for you, and the page shows the computed next run. Schedule changes take effect within about a minute, no restart needed.

Two kinds of runs happen automatically outside the daily window: configuration-change bundles - changing repositories, encryption keys, or site credentials queues a bundle roughly ten minutes later, with multiple changes batched into one run - and automatic retries of partially delivered runs, by default every 30 minutes, until every repository has its copy.

The page rolls the latest run up into four tiles: total recovery repositories, how many are healthy, total bundles retained, and how many repositories hold a healthy database recovery chain. The last tile also shows whether the mandatory recovery secret is configured.

The Latest run section shows the newest run's trigger (manual, scheduled, retry, or configuration change), status (completed, failed, or partial), per-repository counts, and the last error. The repositories table shows per-repository delivery status, retained bundle count, database-chain health, last delivery attempt, and retry count. A repository picker lets you inspect the bundle history actually present in any repository's copy - up to the seven most recent, each marked Full or Incremental and Restorable or Degraded.

Review this periodically, not just during an incident: a repository whose database chain shows broken, or a run stuck in partial, cannot currently rebuild the appliance on its own.

The same page carries the estate-wide admission limits for DR replication syncs. All of them queue extra work rather than failing it - setting a cap too low does not break anything, it silently slows all DR replication while syncs wait their turn. Save writes all five values at once; a blank field falls back to the built-in default, and the page re-reads and displays the values actually in effect. The first four apply on the next admission cycle without a restart.

The appliance recovery flow consumes a recovery bundle plus the recovery secret to rebuild a lost SHA. Any surviving repository copy is sufficient - that is why bundles are delivered everywhere automatically. Keep the secret escrowed outside Sendense and confirm delivery health regularly so at least one restorable copy always exists.