Designing Tiered Protection Policies for VMware Under a WAN Constraint

Do not use one policy. A Cohesity protection policy is the unit that carries snapshot, replication, and archival schedules, so a single policy forces the same SLA onto every VM. Build one policy per service tier and attach protection groups by vCenter tag or category.

• Tier 1 policy: snapshot every 4 hours to meet the 4-hour RPO, retain 30 days locally, replicate on a 4-hour schedule, and archive to Azure with a 7-year retention. Only this tier needs the 7-year copy.
• Tier 2 policy: daily snapshot with 30-day local retention. Replication is optional; if the business has not asked for a second-site RPO, do not replicate.
• Tier 3 policy: a lightweight daily or weekly snapshot with a short retention, and no replication or archive. Rebuild-from-template is not a backup strategy for developer data that occasionally matters.

The key judgement is separating RPO from retention and from DR copies. The 4-hour RPO drives snapshot frequency and replication frequency for Tier 1; it does not justify replicating Tier 2 or Tier 3. Using vCenter tags also prevents a new VM from silently landing in the wrong SLA. Validate that the 120 Tier 1 VMs can complete a 4-hour snapshot cycle within the backup window, and monitor policy compliance by VM count rather than by job success alone.

First quantify the change rate for Tier 1. Replication bandwidth is driven by changed blocks after deduplication and compression, not by the full VM size. If the 120 Tier 1 VMs produce more changed data than the 500 Mbps link can carry during business hours, the fix is scheduling and scope, not abandoning the 4-hour RPO.

Recommended changes:

1. Limit replication to the Tier 1 protection group. Tier 2 and Tier 3 should not consume WAN capacity unless a documented DR requirement exists.
2. Run replication on the same 4-hour cadence as the Tier 1 snapshot, but use Cohesity replication scheduling and bandwidth controls so replication does not compete with production traffic at peak times.
3. Archive only Tier 1 to Azure, and start archival after the local 30-day retention rather than after 90 days. This reduces local capacity pressure and aligns with the 7-year requirement.
4. Confirm that the initial replica seed is sent over the link or by an alternate method; a first full replication of 120 VMs can otherwise dominate the WAN for days.
5. Monitor replication lag as an RPO metric. A completed snapshot is not an RPO success if its replica has not arrived at the second site.

Keep the one-policy desire only as an operational goal, not as a design constraint. A small number of well-named policies is easier to audit than one policy that fails Tier 1.

The risk is not that development VMs cannot be rebuilt; it is that the rebuild assumption is often wrong. Developers store test datasets, configuration, and occasionally data copied from production on those VMs. If the VM is lost, the team may discover that the template does not reproduce the work, and someone may ask for production data to be copied again, creating a new security exposure.

A lightweight Tier 3 policy should provide a modest recovery point without consuming DR resources:

• Snapshot once per day or every other day, with 7 to 14 days of local retention.
• No replication and no archival unless a specific project requires it.
• Exclude Tier 3 from the 7-year compliance archive.
• Use vCenter tags to keep development VMs in the correct group, and review exceptions quarterly.

This gives a low-cost safety net while preserving WAN and archive capacity for Tier 1. The policy should be documented as best-effort, not as a guaranteed RTO. If a development team needs a stronger SLA, it should be reclassified and charged against capacity. The exam-style judgement is to avoid both extremes: protecting everything equally is wasteful, but assuming every development VM is disposable is an unverified business assumption.