Two-Site VMware Protection with a Single PPDM Instance
An enterprise has two data centers 20 ms apart. Site A runs vCenter A with 900 VMs and a DD9400; Site B runs vCenter B with 500 VMs and a second DD9400. A single PowerProtect Data Manager instance is proposed at Site A. The VMware estate is 90 TB full, with 6% daily change and a 10-hour backup window. The initial full backup cannot be seeded from tape; all traffic must use the existing 1 GbE WAN, which is already 60% utilized in business hours. Security requires backup data to remain at the site where it is produced. The project team wants one pane of glass and asks whether a single PPDM can protect both vCenters, where vProxy and DD traffic should flow, and how to meet the window without saturating the WAN. They also need a rollback position if the first policy run overruns.
1. Determine the PPDM, vProxy, and DD placement and justify the data path.
Read the worked answer
Keep PPDM at Site A only if it can reach both vCenters and both DD systems, but do not let VM backup data cross the WAN. Register vCenter B as an asset source, deploy a vProxy in Site B, and target DD B for Site B policies. The control path (PPDM to vCenter B, PPDM to vProxy B, PPDM to DD B) can tolerate 20 ms; the data path (vProxy B to DD B) stays local and satisfies data residency. A second PPDM would reduce management-plane WAN risk but adds operational overhead; it is justified only if discovery or policy operations over 20 ms fail SLAs or Site B must be managed during a Site A outage. Document that one PPDM is a management-plane single point of failure. For one pane of glass, use role-based access and reporting, not stretched backup data. Before creating policies, test PPDM-to-vCenter B latency, vProxy B registration, and vProxy B-to-DD B throughput.
2. Calculate whether the 10-hour window is achievable and design the first-run policy.
Read the worked answer
Split the estate by site: Site A is about 58 TB full and Site B about 32 TB. A first full of 58 TB in 10 hours needs roughly 1.6 GB/s, which is impossible over 1 GbE, so the initial full must be seeded locally, not sent over the WAN. For daily incremental, 6% of 58 TB is about 3.5 TB; over 10 hours that is about 97 MB/s before dedupe and compression. That is feasible on 1 GbE but leaves little headroom at 60% utilization, so cap concurrency and keep vProxy-to-DD traffic local. Schedule Site B independently. If a local seed is impossible, extend the window or use removable media rather than weakening the policy. Measure post-dedupe throughput, set job alarms at 80% of the window, and confirm no backup traffic appears on the WAN link during the canary run.
3. Define the validation and rollback evidence needed before the first production policy runs.
Read the worked answer
Capture the PPDM configuration export, policy settings, vProxy and DD inventory, and a test restore of one VM per site. Define rollback as disabling the new policy and reverting to the prior policy; do not delete DD data until the restore is proven. Success criteria: all in-scope VMs protected within the window, no VM backup data on the WAN, and one VM per site restored within RTO. Run Site A first, then Site B, with a stop point between them. If Site A overruns, stop, preserve logs and job reports, and reschedule rather than letting Site B overlap. Keep the old policy export and a named approver for rollback.