Canonical: https://molo17.com/disaster-recovery/ Markdown mirror: https://molo17.com/disaster-recovery/index.md Title: Disaster Recovery · Gluesync · MOLO17 Description: A standby Core Hub on a second site that follows the active one and takes over its pipelines: planned switchover at zero data loss, manual or witness failover. Gluesync Module · Disaster recovery # Disaster Recovery Run a standby Core Hub on a second site. It follows the active site continuously and takes over the same pipelines from the same positions, by planned switchover at zero data loss or by failover when a site is lost. [See how it works](#how-it-works) [Talk to our team](/contacts/?topic=gluesync-platform#contact-form-section) Disaster Recovery 1. 01 Active site runs the pipelines 2. 02 Standby site follows every database 3. 03 Switch over or fail over in seconds Why Disaster Recovery ## Losing a site should not mean rebuilding Gluesync 01 / One site ### Core Hub holds the state Pipelines, connections, users, checkpoints and schedules live with Core Hub. When its site goes down, every pipeline it runs stops with it. 02 / Backups ### A restore is not a takeover A nightly backup brings back yesterday's configuration and yesterday's positions. The changes in between have to be found, replayed or re-snapshotted by hand. 03 / The platform outcome ### A second site, ready to serve The standby Core Hub holds a copy that follows the active one about a second behind, and resumes the same pipelines from the positions the targets confirmed. How it works ## Two Core Hubs, one active at a time 1. 01 Active ### One site runs the pipelines The active Core Hub serves the Control Plane, the API and MCP, and runs every pipeline as usual. 2. 02 Standby ### The other site follows The standby Core Hub receives every database change from the active one over a single encrypted channel. It opens no source connections and runs nothing until it takes over. 3. 03 Takeover ### The role moves, the pipelines follow A planned switchover or a failover makes the standby active, and it resumes the pipelines from the last positions their targets confirmed. The previous site rejoins as standby when it returns. Capabilities ## Replicate, switch over, fail over Disaster Recovery pairs two Core Hubs at two sites. Replication runs directly between them: no shared storage, no object storage and no extra cluster to operate. Replication ### Every Core Hub database, continuously #### Pipelines, notifications, metrics, AI brain, data comparison and Chronos The active site streams each of its six databases to the standby at the transaction level, so whatever Core Hub writes reaches the other site about a second later. The Disaster Recovery tab shows what the active site has shipped against what the standby has applied, database by database. - Core Hub to Core Hub over one key-pinned, encrypted channel - Chronos schedules replicated with the rest - Per-database status: shipped and applied transaction, in sync or behind Disaster Recovery Planned switchover ### Move the active role with zero data loss #### For maintenance, upgrades and site drills Start the switchover from the active site. It stops the writes, replicates the last changes, and hands the role over with a SHA-256 digest of every database. The standby takes over only when each of its copies matches, then the old site restarts as standby. - Four visible steps, from stopping the writes to restarting as standby - Every database verified by digest before the handover is accepted - Last switchover verification kept on the Disaster Recovery tab Disaster Recovery Failover ### Manual by default, automatic with a witness #### Never two active sites With manual failover, an operator promotes the standby once the active site is confirmed down. With witness mode, a third Core Hub holds a lease: the standby takes over by itself when the active site loses it, and the active site stops serving before that can happen, so both sites never write to the same targets. - Witness: a Core Hub in witness mode, holding no pipelines - Epoch fencing: a returning site steps down and follows - Every promotion starts a new epoch on its own replication history Disaster Recovery Takeover ### Pipelines resume where the targets stopped #### No gaps, no manual replay The standby resumes each pipeline from the position its target confirmed. Changes delivered again across the takeover are absorbed by the upsert write path, so the target converges on the source. - PostgreSQL replication slots confirm only what the target stored - MySQL and MariaDB binlog positions rewound to the oldest confirmed position - Users, tokens and connections work on the new site as they did on the old one Operations ### Upgrade a pair one site at a time #### Standby first, then switch over Gluesync Control upgrades the standby while the active site keeps running, then a planned switchover moves the pipelines to the new build. The site that handed over keeps a rollback point with its exact state, so the pair can return to the previous build. - The Disaster Recovery tab shows the build of each site - A standby never takes over databases newer than its build - Node-local settings per site, never replicated to the peer Explore the platform ## Continue exploring Gluesync Disaster Recovery protects the Core Hub that runs your pipelines. Pair it with Validator to check targets after a takeover, and with Chronos to keep schedules running on the new site. [### Schedules and events Chronos schedules travel to the standby site with everything else and keep running after a takeover. Explore Schedules and events →](/schedules-and-events/) [### Validator After a takeover, compare any entity with its target and reconcile the differences. Explore Validator →](/validator/) [### Core Hub MCP server Check the state of both sites and every pipeline from any MCP client after a switchover. Explore Core Hub MCP server →](/corehub-mcp/) [ ### Gluesync Real-time CDC replication. Disaster recovery keeps it running when a whole site is lost. Explore Gluesync →](/gluesync/) Resources ## Guides, roadmap and support Documentation ### Documentation Technical guides, API reference, deployment tutorials. [Read documentation ↗](https://docs.molo17.com) Roadmap ### Public Roadmap What we're building next. Submit feature requests. [View roadmap ↗](https://roadmap.molo17.com) Support ### Support Access technical support and operational assistance. [Get support →](/support/) Status ### Service Status Real-time platform availability and incident history. [Check status ↗](https://status.molo17.com) ## Plan a second site for Gluesync Talk with the MOLO17 team about adding Disaster Recovery to your Gluesync subscription, or start a free trial. [Request a free trial](/get-gluesync/) [Talk to our team](/contacts/?topic=gluesync-platform#contact-form-section)