During a planned failback after an async replication outage, what must be true at the original site before the recovery plan can safely reverse replication?
Select an answer to reveal the explanation.
Short Explanation
Think of failback like moving back to your old office: you can't just flip the sign until the building is safe and the phone lines are back up. You need the original site healthy and replication re-established so the latest data can flow the other way. If you try to run the plan first, you're just guessing with production VMs.
Full Explanation
Metro and async failback is a controlled reversal of the active site. After workloads have been recovered at the disaster-recovery target, the original site must first be brought back to a supported state: compute, storage, networking, and Prism services must be reachable, and the replication relationship must be re-established so data written at the target can be copied back before the failback plan moves the VMs. The option requiring target snapshots and powered-off VMs confuses backup or migration hygiene with failback prerequisites; snapshots may help recovery, but they do not make the source usable. Reinstalling Prism Central and completing LCM describes a full rebuild or upgrade path, not a normal failback condition, and would only be needed after a severe platform failure. Migrating every protection domain VM to Metro availability changes the availability design and is unrelated to reversing an existing async or Metro replication direction. Exam caveat: failback is not simply powering on at the original site; the direction of replication and source-site health are the gate. Operational check: verify the source cluster and network are healthy, then confirm the protection domain shows reverse replication or target-to-source replication before running the failback plan. A plan cannot protect data if the source storage pool cannot accept the reverse copy.