Use sync back after a failover to periodicaly transfer incremental, delta-based updates for failed over workloads on a recovery SDDC.
Sync back helps you capture all changes that can occur on a VM after failover. It provides incremental transfer of data changes for failed over workloads, which can reduce the time required for failback. When you regularly sync back, less data needs to be transferred during failback, depending how often you sync back after making changes to the VMs.
Sync back is supported for both standard and high-frequency snapshots.
Sync Back Workflow
- Run a failover recovery plan with VMs set to run live on the cloud file system. VMs running on the recovery SDDC after failover.
- Sync back to send all changes back to original protected site. VMs still running and being modified.
- Sync back again, just before failback.
- Fail back VMs to original protected site.
Sync back restores VMs to a protected site in their current state on the recovery SDDC. Any changes to VMs on the protected site that happened after failover will be lost.
Sync Back Frequency
How often you should sync back before failback depends on many factors, such as how many changes occur to the VMs after failover and before failback, and how long you expect a failback to complete.
If you sync back too frequently, for example, after any change to the VMs, it can use too much bandwidth/resources. If you sync back too infrequently, predicting failback times becomes more difficult.
- If you know how long your VMs will stay failed over before failback, perform a sync back at about a quarter, halfway, and then three quarters of the way through the full failover duration.
If the time it takes to failback is acceptable, then this frequency is satisfactory.
If the failback time took too long, then you can resync more frequently.
- Sync back close to the planned failback date to reduce failback time. If you are running sync back and at a quarter, halfway, then three quarters of the way, you can sync back again at seven eights of the way through the full failover duration.
- If you know there will be a full restore for some of the VMs (for example, VMs corresponding to the failover snapshow are missing, perhaps due to already being restored to a new protected site), sync back sooner soon after failover to do a full restore of the VM on the original protected site.
Sync Back Restrictions
- Sync back is only supported on VMs that have been failed over to run live on the cloud file system.
- You cannot use sync back on VMs that were failed over and migrated to storage on the recovery SDDC. If you storage vMotion a VM to a vSAN datastore after performing sync back, failback will behave as if no sync backs were ever done.
- VMs that have been migration from a vSAN datastore back to the cloud file system cannot use the sync back feature.
- Sync back will skip any VMs that have vSphere snapshots.
- Avoid powering-on VMs on the protected site after sync back, as sync back does not perform any guest OS customizations on the VMs.
- If the protected site you are using sync back does't have have the original VMs, the first sync back will do a full restore of the VM on the protected site, which can save a lot of time during failback.
Procedure
- Find the plan that is ready for failback from the list of plans.
- Click the Sync Back button.
- In the Sync back dialog box, enter to words sync back, and then click Sync Back.
After the sync back completes, you can view information about the event from the Events page in VMware Live Cyber Recovery.
- You can also create a PDF report of the sync back operation, which provides more details about the process for this specific plan.
