BEFORE YOU BEGIN
Check before you begin
Replication does not replace independent backups with retention. OpenStack/Safir Cinder and VMware-to-VMware VDDK/CBT data paths have different prerequisites. A VMware-to-OpenStack design document does not establish production-validated conversion support. Do not assume the same flow for other platforms.
Verification limit: these guides are based on local replication templates and operations documentation. Firefox lab control could not reliably read current page content in this inspection, so no new replication/DR screen was captured; another platform’s screenshot was not substituted. Full/Incremental, interruption/resume, checkpoint boot, failover and failback were not executed live. Menus and source code do not establish end-to-end acceptance of the installed release.
- Source/target sites, platforms and matching releases
- Networking/TLS, data-path roles and destination capacity
- Checkpoint identity, data consistency and measured RPO
- Isolated testing, source fencing and a failback plan
011. Assess the incident and recovery objective
With service, incident and infrastructure owners, identify affected VMs/applications, dependency order and the last sound data time. Ransomware or corruption may have propagated to the replica; do not assume the newest checkpoint is clean. Choose independent-backup recovery when necessary. Record decisions and the timeline.
Expected resultBusiness priority and an acceptable data point are established.
022. Inspect a verified checkpoint
In Replication → Details, compare status, generation, source instance/volume and checkpoint identity. The inspected UI enables Failover only for checkpoint-available; this does not guarantee application consistency. Verify that all required disks belong to the same accepted generation and destination data is accessible. Measure actual data loss at the incident time from checkpoint age.
Expected resultThe recovery point and expected data loss are evidenced.
033. Prepare an isolated test target and dependencies
Check DR compute, storage, network, project/datastore, security rules and licensing capacity. Separate the test network from production; prevent duplicate IP, hostname, domain/cluster identity and automatic external connections. Plan DNS, identity, database and application startup order. Isolated testing and taking production traffic are different approval and acceptance stages.
Expected resultThe isolated destination can be tested without conflicting with the source.
044. Fence the source before production promotion
With the infrastructure owner, verify that the source VM and any previous DR copy are powered off and cannot write. No ping response is not proof of fencing. Document power/access controls that prevent writes from both sites. The inspected Failover form requests FENCE CONFIRMED; typing the text does not perform physical fencing. Do not proceed to the final Failover action without verification.
Expected resultA single writer and source isolation are verified.
055. Perform controlled failover and application acceptance
In the approved incident plan, recheck policy, checkpoint and destination mapping. Start Failover queues an operation; separately monitor completion, destination VM/disk identity and addresses. Check boot and data hashes first, then services/databases and user scenarios. Change production routing such as DNS/load balancers only after service acceptance; record durations.
Expected resultInfrastructure and application acceptance support production cutover.
066. Define stop and rollback boundaries on failure
If boot, data or service acceptance fails, do not bring both copies into production simultaneously. Preserve the last verified checkpoint and logs. Once new writes begin at DR, starting the old source may cause data loss/conflicts; identify the authoritative side and agree a reconciliation plan with the application owner before rollback. Do not assume automatic rollback.
Expected resultRollback decisions respect the authority of current writes.
077. Plan failback as a separate change
Verify primary-site health, capacity and bidirectional data-path access. Agree the release-specific method for resynchronizing new DR data to the primary/reverse replication with the technical team; one-click failback was not verified in this inspection. Plan a new window for final delta, controlled shutdown, renewed fencing, boot and application acceptance. Record actual RPO/RTO, backup/checkpoint identities and improvements in the incident report.
Expected resultReturn to the primary is accepted with current data and a single writer.
COMMON QUESTIONS
Is a DR test needed after successful replication?
Yes. Data transfer does not establish acceptance of boot, application consistency, fencing, network cutover or return to the primary. Validate these separately with isolated tests and a documented operations plan.