VMs Missing From a Scheduled Protection Domain
Prism Central manages three clusters: Prod-A, Prod-B, and DR-C. The finance team is protected by an RF2 protection domain named PD-Finance with a schedule that takes a local snapshot and replicates to DR-C every four hours. The domain is scoped by the category App:Finance. Two new VMs, fin-app-07 and fin-app-08, were created directly in Prism Element on Prod-B by a DBA who does not use Prism Central. The quarterly DR test restored the latest snapshot to DR-C and both VMs were absent; the restore reported success. The DBA insists the VMs were running on Prod-B for three weeks.
1. Diagnose why the two VMs were never captured, and say how you would prove it.
Read the worked answer
The protection domain is not a folder of VMs; it is a category-based selection evaluated when the schedule fires. VMs created in Prism Element do not automatically receive categories, so fin-app-07 and fin-app-08 carry no App:Finance category and are invisible to PD-Finance. The snapshot completed successfully because it did capture everything the domain selected - it just never selected those VMs. This is the most common false 'backup worked' result in a Prism Central estate.
Proof: in Prism Central, open the VM list for Prod-B and filter or column-display by category to show both VMs have no App category. Then list the protection domain's VM membership before and after the DBAs' creation date and show the count unchanged. If the VMs must be managed at the element level, that is a process gap to close, not a product defect.
2. What is the fix, and what control would stop this recurring without blocking the DBAs?
Read the worked answer
Immediate fix: apply the correct categories to both VMs from Prism Central, confirm they appear in PD-Finance's membership, take an on-demand snapshot, and re-run the DR test for just those two VMs before declaring the quarter closed.
Structural fix: stop treating categories as optional metadata. Options, in order of strength:
- Enforce category assignment at creation through the Prism Central self-service workflow so DBAs deploy from a blueprint that stamps App:Finance automatically.
- Audit drift on a schedule: run a report of VMs on protected clusters with no category, and route it to the team that owns them. Any VM without a category is unprotected by definition, and the report makes that visible weekly rather than quarterly.
Also update the DR test itself so a restore that does not include a known-VM list is treated as inconclusive; a 'success' status with no inventory check is what let three weeks pass unnoticed.
3. The finance team now wants a 15-minute RPO. What do you evaluate before agreeing?
Read the worked answer
Start from what the schedule can actually deliver versus what continuous replication can. A four-hour snapshot schedule cannot be tuned to fifteen minutes without evaluating the cost: more frequent snapshots consume cluster and DR-C capacity, and each replication window must finish before the next starts.
If the requirement is truly 15 minutes, evaluate the continuous replication option available in your AOS release rather than shortening the snapshot interval. That requires:
- Confirmed round-trip latency and bandwidth between Prod-B and DR-C, measured, not assumed from the circuit order.
- Confirmed support in the deployed AOS version and that both sites meet its sizing rules.
- A decision on what happens on a link brownout - does the VM stall or does the protection degrade, and who is paged.
- A DR test that measures actual RPO achieved, not the configured value.
Any of these can disqualify the option. Do not commit to 15 minutes on the strength of a configuration screen alone.