An admin must size an external backup target for a protection domain whose VMs are protected with Nutanix snapshots every 6 hours, retained for 30 days. Assuming the first snapshot's used blocks are already accounted for, which inputs most directly determine the additional target capacity needed?
Select an answer to reveal the explanation.
Short Explanation
Think of backup capacity like a closet: it's the stuff you keep that fills it, not how big the house is. You need retained snapshots times the change rate, not every provisioned block. The trap is sizing for allocated disk and forgetting churn.
Full Explanation
Snapshot-based backup capacity is driven by retained snapshots and the data changed between snapshot intervals. The initial snapshot captures used blocks, while each later snapshot captures incremental changed blocks, so required target space is approximately average changed-block volume per interval multiplied by retained snapshot count, plus overhead. Retention depth and workload churn determine whether the target stays online. Total provisioned disk size and production node count are wrong because provisioned capacity can be thin, sparse, or never fully written, and node count describes cluster topology rather than snapshot data retained on the target. The number of protected VMs and average VM disk utilization are wrong because VM count alone does not size incremental snapshots, and point-in-time utilization does not capture how much data changes during the retention period. Replication bandwidth and async replication latency are wrong because they affect how quickly data moves between sites, not the amount of snapshot data stored on the backup target. Exam caveat: when sizing a backup target, distinguish capacity drivers such as retention and change rate from performance or topology metrics. Operational check: calculate average daily changed blocks from monitoring, multiply by retained snapshots, and add headroom for growth and metadata.