Capacity and Protection Decisions for a 4K Media Archive
Post-production studio operates a 6-node AHV cluster with 12 x 3.84 TB SSDs per node, yielding about 276 TB raw capacity. The active container uses RF2 and is 62% full. The studio expects to ingest 40 TB of new 4K footage over the next three months, with 15% annual growth afterward. Local snapshot retention is 7 daily, 4 weekly, and 3 monthly. Disaster recovery targets are RPO 30 minutes and RTO 8 hours at a 3-node DR cluster that currently has 138 TB raw and RF2. The media team wants all footage protected, but the CFO questions the cost of expanding both sites. Editing workloads are latency-sensitive and random-read heavy; completed projects are read-only after 30 days. The infrastructure team must decide on resiliency level, erasure coding, replication scope, and snapshot policy without risking the active edit workload.
1. Calculate usable capacity under RF2 and RF3, decide which resiliency level to use for active and archive data, and determine whether erasure coding is appropriate.
Read the worked answer
Raw = 6 × 12 × 3.84 TB ≈ 276 TB. RF2 usable ≈ 138 TB; RF3 usable ≈ 92 TB. Current used = 62% × 138 ≈ 85.6 TB. After 40 TB ingest = 125.6 TB, which is 91% of RF2 usable and only 12.4 TB free. That is not enough headroom for snapshots, rebuild after a node failure, and 15% growth. RF3 cannot hold the data at all.
Decision: keep active editing on RF2 and expand the cluster by at least 2 nodes (raw 368 TB, RF2 usable 184 TB; 125.6 TB is 68%). Do not switch active 4K editing to RF3; it costs 33% usable capacity and does not fix the immediate capacity shortfall. For completed projects after 30 days, create a separate archive container with erasure coding (for example 4+1) because the data is read-only and latency-insensitive. Validate EC-X support and overhead for the AOS version. Keep RF2 for the active container because 4K random-read latency and write performance matter more than capacity efficiency there. If adding nodes is not funded, the only safe alternative is to reduce local retention and move completed projects off-cluster, not to run at 91%.
2. Design DR replication to the 3-node DR cluster to meet RPO 30 minutes and RTO 8 hours without replicating all 40 TB of new footage. Include capacity math and replication method.
Read the worked answer
DR raw = 3 × 12 × 3.84 ≈ 138 TB; RF2 usable ≈ 69 TB. The primary protected set after ingest is ~125.6 TB, so the 3-node DR cannot hold all of it. You must either expand DR to 6 nodes (RF2 usable ≈ 138 TB) or reduce the protected set. Present both to the CFO.
Recommended: replicate only active projects and metadata (for example 60 TB) to the 3-node DR; keep completed archive on primary with a separate offline/cloud copy. Use Protection Domains or Leap protection policies for the active VMs. Schedule async replication every 15 minutes so a 30-minute RPO is achievable if each run completes within 15 minutes. Estimate change rate: if 120 GB changes per 30 minutes, the link needs about 55 Mbps minimum plus overhead; a dedicated 1 Gbps link is sufficient with margin. At DR, pre-create networks and run a Leap runbook for power-on, IP/DNS changes, and validation. RTO 8 hours is realistic if the runbook is tested, not if you are restoring 40 TB from snapshots. Document that archive RPO is not 30 minutes under this design.
3. Define snapshot and restore validation policy, including how you would prove the 4K project can be restored within RTO.
Read the worked answer
Local snapshots: 7 daily, 4 weekly, 3 monthly on the active container; use application-consistent scripts or Nutanix Guest Tools where supported. Snapshots are not backups: they share the same failure domain and consume container capacity, so alert at 70% used and keep 15–20% free. DR retention: replicate the active protection domain and keep 7 daily, 4 weekly, 3 monthly at the DR site; do not replicate archive snapshots unless the DR capacity is expanded.
Validation: quarterly, restore one completed 4K project and one active project to an isolated VLAN at DR. Measure from declaration to login and media mount; verify file checksums and project database consistency. Record actual RTO and fix runbook gaps. Test a single-VM restore and a full protection-domain failover. Also test backup appliance restore independently. If the measured restore exceeds 8 hours, either add DR capacity, pre-stage more data, or narrow the protected set. Keep the restore report as audit evidence.