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. Define the workload and direction
Record source/target sites, platform, VM identity, all required disks and application dependencies. RPO is the data-loss objective and RTO the service-restoration objective; do not commit values without measurement. Validate OpenStack/Safir and VMware-to-VMware releases and data paths separately.
Expected resultSource, destination, disk set and measurable objectives are recorded.
022. Check connectivity and TLS between sites
Separate management and data addresses. The 24 September port matrix defines bidirectional TCP/443 plus /replication-controller/ and /replica/ paths between HTTPS-gateway sites. Older/direct component layouts use controller 19451, apply 19450 and relay 19452; do not expose all of them to the internet. Validate rules for the installed topology with the technical team and retain CA verification.
Expected resultCorrect data endpoints and validated TLS access are ready.
033. Validate destination capacity and endpoint roles
For OpenStack, check project, volume type, volume/snapshot/gigabyte quotas and controller/replica_apply roles. The runbook recommends free Cinder capacity of 2 × source volume size + 10% for the initial seed; separately calculate actual needs for multiple disks and retention. For VMware, validate the correct powered-off target VM, datastore, VDDK and all disk mappings. Never substitute a fake file or a different disk for a missing block device.
Expected resultCapacity and data-write roles are bound to the correct destination.
044. Review the replication policy and Run fields
Compare source/target direction and policy identity under Home → Replication. The inspected Run form carries source volume UUID, source/target controllers and sites; target_id/replica_id are advanced mappings. Do not copy sample identifiers from the documentation. A VMware policy requires one source VM and acceptance of all its disks together.
Expected resultThe summary identifies the correct source and destination.
055. Plan the first Full seed and checkpoint acceptance
In an approved small test, inspect Full / Generation 1 transfer, destination records and hash verification together. A queued notification is not completion. Record checkpoint identity, generation, time and data scope. The VMware document publishes a checkpoint only after every disk verifies; the OpenStack runbook describes a verified destination-snapshot chain. Preserve the last good generation on failure.
Expected resultA usable checkpoint matches data evidence.
066. Measure incremental generations and interruption behavior
For at least three Incremental generations, measure changed data, transfer time, age of the last verified checkpoint and backlog. Scheduler interval alone is not RPO. In an approved pilot, separately test interruption/resume and restarts of both EraBackup servers. Do not blindly clear queue/state files on failure; compare task, service and lifecycle logs.
Expected resultThe incremental chain and measured lag are documented.
077. Perform isolated recovery testing and ongoing monitoring
Use the separate disaster-recovery guide to test a verified checkpoint on an isolated network. Accept boot, all disks, file hashes and application access; prevent simultaneous service with the source under the same identity/IP. Assign ownership for monitoring capacity, last-good-checkpoint age, transfer failures and service health. Successful replication is not a reason to remove independent backup retention.
Expected resultReplication is completed with data acceptance and a DR test.
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.