Skip to content
industricAgents

Disaster recovery

Recovering from a major outage with warm standby.

High availability handles local failures. Disaster recovery restores service after a larger outage, such as losing a region.

Warm standby

In this reference design, a smaller Exo service stays running in a recovery region, with a continuously replicated, read-only database. Only one region accepts writes. Separate backups protect against corruption that replication could copy.

Exo control plane · Warm standby reference
Exo warm-standby disaster recoveryProduction traffic uses the primary region. A reduced-capacity Exo control plane is already running in the recovery region. PostgreSQL replicates asynchronously from the primary writer to a read-only standby. Independent backups, WAL, encryption keys and recordings support recovery. During failover, the old writer is isolated, the standby becomes the writer, capacity is increased, and service is checked before traffic switches to the recovery region. Dashed replica outlines represent capacity to add, not running instances.Two regionsExo service endpointRoutes production trafficPrimary regionMulti-AZ · activeRecovery regionWarm standbyProduction trafficRoute traffic here after failoverLoad balancerDistributes requestsLoad balancerReady for failoverExo control planeProduction capacityExo control planeRunning · reduced capacityPostgreSQL primarySingle writerPostgreSQL standbyReplicating · read-onlyAsyncreplicationIndependent backups · WAL · encryption keys · recordingsStored separately for recovery
Scroll to view the full diagram.
Exo control plane · Warm standby reference
Exo warm-standby disaster recoveryProduction traffic uses the primary region. A reduced-capacity Exo control plane is already running in the recovery region. PostgreSQL replicates asynchronously from the primary writer to a read-only standby. Independent backups, WAL, encryption keys and recordings support recovery. During failover, the old writer is isolated, the standby becomes the writer, capacity is increased, and service is checked before traffic switches to the recovery region. Dashed replica outlines represent capacity to add, not running instances.Two regionsExo service endpointRoutes production trafficPrimary regionMulti-AZ · activeRecovery regionWarm standbyProduction trafficRoute traffic here after failoverLoad balancerDistributes requestsLoad balancerReady for failoverExo control planeProduction capacityExo control planeRunning · reduced capacityPostgreSQL primarySingle writerPostgreSQL standbyReplicating · read-onlyAsyncreplicationIndependent backups · WAL · encryption keys · recordingsStored separately for recovery

Before adopting this design, test Exo startup and health checks against the read-only standby. See the warm-standby pattern.

Recovery steps

For managed Exo, control-plane recovery belongs to the Exo operations team, not your cluster team:

  1. Isolate: stop the original region from accepting writes.
  2. Check: confirm available data, encryption keys, and any expected data loss.
  3. Activate: make the standby database writable and increase service capacity.
  4. Verify: test sign-in, session access, and Operator connectivity.
  5. Switch: direct traffic to the recovery region and confirm reconnections.

What your team does

Check that your Operator reconnects and try an Agent session. If your own cluster was affected, restore its workloads and saved files separately. Control-plane recovery does not restore Agent volumes or guarantee that interrupted work resumes.

Recovery targets

Agree how much downtime (RTO) and data loss (RPO) your business can accept. Confirm the service commitments with Exo and test your own recovery plan.