The StackX Replication / Disaster Recovery scope is intended for production systems that require an operational standby server or infrastructure, managed replication, and a genuinely prepared failover procedure.
The model is based on a PRD / DRS architecture operated through StackX: a production server, a recovery server, consistent SQL and file flows, and dedicated operations tooling.
Depending on the selected scope, StackX can also manage a service VIP (standard on ScalarCloud), propagation of replicated environments, and controlled failback.
The result: a disaster recovery plan that is easier to execute, better documented, and easier to verify than a simple collection of one-off scripts or YAML files.
For requirements focused exclusively on backup and restore, see Backup.
StackX Replication / Disaster Recovery Baseline
| Component | Role |
|---|---|
| PRD / DRS Architecture | A production server and a recovery server operated together |
| SQL Replication | Bidirectional MariaDB/MySQL replication, according to the selected topology |
| File Synchronization | prdsync / drssync to keep docroots, configurations, and content consistent |
| Operations Bastion | Orchestration of critical operations, checks, and remediation across nodes |
| Service VIP | Controlled reassignment based on the architecture when a virtual IP is included in the scope |
Naming convention:
The -prd, -drs, -stg, -dev, and -bkp roles are detailed on the StackX Conventions page.
SQL Engine OverviewMariaDB, MySQL, and PostgreSQL
| Engine | Recovery Mode |
|---|---|
| MariaDB / MySQL | Native database replication based on the selected topology, tool-assisted repair, and resynchronization with an explicit source of truth |
| PostgreSQL | Streaming replication primary / standby, DRS promotion, and target-node rebuild during failback |
| Application Files | prdsync / drssync synchronization according to the selected operational direction |
| VIP / Service IP | Controlled reassignment based on the architecture when it is included |
What StackX AutomatesChecks, synchronization, and bastion operations
| Operation | StackX |
|---|---|
| Initialization | Replication bootstrap and inter-node access checks |
| Environment Creation | Propagation of replicated environments from PRD -> DRS |
| Checks | Verification of services, replication, backups, and monitoring through sxpostcheck |
| Prechecks | Validation of roles, access, SQL status, synchronization, and prerequisites before any mutation |
| Locking | A single mutating operation per PRD / DRS pair to prevent concurrent execution |
| Repair | Managed resynchronization with an explicit source of truth |
| Failover | Activation of disaster recovery / DRS, suspension of synchronization flows, and service failover according to the architecture |
| Failback | Reseeding PRD from DRS, final SQL catch-up, file resynchronization, and return to normal operations |
| Enabling Synchronization | Start only after complete validation of replication and the inter-node path |
When to Choose Replication / Disaster Recovery
| Context | Benefit |
|---|---|
| Critical Production | Reduce recovery time and avoid improvisation during a major incident |
| Strong SQL Dependencies | Maintain database / file consistency on a second node |
| RPO / RTO Constraints | Prepare the recovery level before an incident |
| Multi-zone / multi-DC | Isolate recovery infrastructure at another site or in another zone |
Scoping PointsRPO, RTO, failover, and validation
| Point | Note |
|---|---|
| StackX Scope | Some functions depend on the scope actually deployed |
| VIP | A VIP is not present in every architecture |
| Failback | Returning to normal operations may require a controlled reseeding of PRD |
| Destructive Operation | The target node and source of truth must be selected explicitly before any reseeding |
| Disaster Recovery | The appropriate level depends on the RPO, RTO, application flows, and accepted budget |
Need a properly scoped Replication / Disaster Recovery setup?
We define the architecture, flows, automation level, and failover procedures based on your actual production environment.
Infrastructure
ScalarX designs and operates redundant, maintainable, and scalable architectures tailored to production constraints, the selected provider, and the expected level of independence.
Monitoring
ScalarX combines local monitoring, external HTTPS checks, and an independent trusted third party to assess incidents more accurately, even across architectures distributed among multiple countries, providers, or data centers.
Managed Operations
ScalarX combines human expertise, conditional algorithms, and agentic AI systems to improve operational reliability, detect weak signals, accelerate response, and improve the quality of operations.