A Nutanix administrator is designing backup integration for a protection domain. The business requires that a restore can reach any point within the last 30 days, while replication handles site failover. What should drive backup retention depth?
Select an answer to reveal the explanation.
Short Explanation
Think of retention depth like a bookshelf: if you need to flip back 30 days, you need enough backups on the shelf to cover that span. You can't make a single snapshot or a replication link do a history's job. Set the retention depth to the longest recovery point, then let frequency decide how fine the points are.
Full Explanation
Backup retention depth is the amount of historical restore material kept available, so it should be sized to the longest recovery point the business can require. If a restore may need to reach any moment in the last 30 days, the backup integration must retain enough generations, or a depth-based retention policy, to span that interval. Replication protects availability and can provide a recent copy at another site, but it does not replace retained backup generations unless the design explicitly converts replicated data into restorable history. Snapshot frequency controls how granular individual restore points are; it does not determine how far back the policy can go. Keeping only the newest backup leaves the policy unable to satisfy an older recovery point, even if the latest copy is current. NearSync improves replication latency and RPO, but it is not a retention mechanism for historical restore points across weeks or months. Exam caveat: on the NCP-MCI level, read the requirement carefully and separate recovery point retention from failover latency or snapshot cadence. Operational check: compare the stated recovery window with the configured backup retention depth and confirm a test restore can reach the oldest acceptable point.