Guide
DR Failover
How Sendense approaches test, planned, and live failover for controller-backed DR workflows.
Overview
DR failover is the recovery operation that promotes a prepared replication target so the workload can run in the recovery environment.
The targets are kept ready by replication patterns: replication data flows from the protected site to the recovery-site SNA, which passes it to the Sendense Controller for each VM. See Replication Transport And Routing for how that data moves between sites.
Failover Modes
Failover Lifecycle
A test failover completes into a rollback-eligible state and stays there until the operator rolls it back, which restores the pre-test disk state and resumes replication. A planned or emergency live failover completes into an awaiting-commit state, and the target stays there until the operator commits or rolls back.
Failover lifecycle paths
Steady state
Replication Ready
The target syncs on schedule and the Sendense Controller receives replication data.
Rollback-eligible
Test Failover Active
The recovered workload runs for validation, typically on a test network.
Back to steady state
Rolled Back
Pre-failover disk state is restored and replication resumes.
Steady state
Replication Ready
The target syncs on schedule and the Sendense Controller receives replication data.
Operator decision
Awaiting Commit
The promoted workload runs in the recovery site. The operator must commit or roll back.
Final
Committed
The promoted VM is accepted as production. Normal rollback is no longer available.
Commit And Rollback
After a planned or live failover, the operator decides the outcome. Commit finalizes the failover: the promoted VM remains the production workload and normal rollback is no longer available. Rollback returns to the pre-failover state, restores the controller-backed target to replication mode, and, for planned failover, powers the source VM back on where supported.
Commit is final
Commit is a deliberate operator decision taken after the recovered service has been validated and accepted. It removes the rollback state for that failover.
Rollback, Failback, And Reprotection
Rollback and failback are different operations. Rollback returns to the previous source-side production state and is only available before commit. Failback is a later planned movement of production back to an original or new primary site after a committed DR event.
Readiness And Validation
Failover operations can be blocked by readiness checks. When a precheck blocks failover, fix the readiness condition rather than repeating the operation.
- Controller health: online, degraded, offline, or unknown.
- Replica disk readiness and last sync state.
- Checkpoint recovery requirements after an interrupted sync.
- Destination network availability.
- Active operation locks from another running sync or failover.
Network Handling
Network placement on the hypervisor or cloud side is separate from network settings inside the guest. Windows guest handling can restore source IP settings, preserve current target networking, or apply manually supplied static IPv4 settings where supported. Linux can restore static IPv4 settings where policy and captured source configuration allow it, and DHCP-based workloads may simply obtain target-side addressing.
Guest network restoration depends on captured settings, the target environment, guest behavior, and policy. See Failover VM Remediation for detail.
Test network choices matter
A test workload started on a production network can conflict with the source workload. Use the test network override to place test workloads onto a safer network where available.
Related Docs