Cross-region volume replication
Maintain asynchronous recovery copies and promote one writer after a regional failure.
Cross-region replication transfers volume recovery checkpoints to a separately owned destination volume in another region. It does not turn one regional volume into a multi-region writable device.
Create a relationship
Open Volume → Replication, choose an allowed target region and storage policy,
and select the capture interval. The default interval is 300 seconds; accepted
values are integer seconds 60–86400. Actual recoverable age depends on capture,
transfer, and destination application completing.
The target receives a new volume ID and remains read-only for recovery management. Destination quota, encryption access, capacity, and residency policy are checked before initial synchronization. A consistency group can replicate a required set together.
Read lag correctly
Inspect last captured checkpoint, last completed target checkpoint, transferred bytes, and remaining backlog. An updated source timestamp is not evidence that the same data is recoverable at the target.
A disconnected target retains its last completed point while later work queues or fails according to relationship policy. Alert on recoverable age and transfer errors, not only on the relationship's enabled setting.
Promote
Stop or fence the source writer before promoting the target. Open Volume → Replication, select the relationship, and choose Promote. Select a completed checkpoint and review its age and consistency. For automation, use the promotion operation with its fencing reference. Promotion stops ordinary replication into that target and creates a writable recovery attachment path.
A promotion cannot recover writes absent from the selected checkpoint. Applications with their own replication must establish database ownership as well as storage ownership. Update traffic only after application validation.
Reverse and resynchronize
A promoted target can contain writes missing from the former source. Do not resume forward copying over it. Establish the new authoritative direction, retain needed rollback points, and create a reviewed reverse or replacement relationship.
A failed source returning to service stays excluded from write ownership until reconciled. Check old guest execution before reusing its disks.
Remove
Disabling prevents new checkpoints without deleting the retained target. Removing the relationship requires resolving active transfers and an explicit target retention decision. Source deletion cannot silently remove a promoted recovery volume.
See Replication API, fencing, and disaster recovery for promotion and cleanup.