Office Backup Redundancy
The backup model should be obvious to the owner: which node is primary, which node has the latest copy, what is queued, and what will happen when an offline node returns.
- Peer backup makes one office node a recovery path for another instead of leaving everything on one box.
- Queue-first delivery keeps API keys, settings, and database updates from disappearing when a server is temporarily offline.
- The portal should fail gracefully when every approved office route is unavailable, then retry when a lead returns.
Backup behavior
- Peer replication Server nodes should keep current company data available across approved office peers.
- Encrypted outbox Failed delivery should be queued and retried automatically instead of being treated as a permanent failure.
- Recovery visibility Owners need to see primary node, backup node, last sync, and pending queue status.
When systems are offline
- Server down Updates wait in the queue and replay when the peer is reachable again.
- Internet down Local office work should continue where possible and sync when service returns.
- Portal unavailable Public intake should show maintenance instead of losing customer information silently.
Keep the overview clean.
This is now its own resilience page instead of being buried in the general feature overview.