After an external backup solution reports nightly jobs successful for a protection domain, an administrator must prove the backups are actually usable for recovery. Which backup-health control best demonstrates recoverability?
Select an answer to reveal the explanation.
Short Explanation
Think of a backup like a parachute: you don't trust it because it packed cleanly, you trust it because you pulled it. You need scheduled restore tests to prove the data is actually recoverable. Job logs only tell you the copy finished, not whether you can boot from it.
Full Explanation
Backup health has two distinct layers: backup execution and backup validity. A successful job means the backup application copied data, wrote metadata, and reported completion, but it does not prove the resulting image is mountable, application-consistent, or restorable. Periodic restore tests close that gap by exercising the actual recovery path, validating that snapshots or backup copies can be used to recover a VM or volume group. A warning-free completion log is still useful for trend analysis, yet it remains a success signal, not evidence of recoverability. Extending snapshot retention increases the number of restore points and can help meet RPO or compliance goals, but it does not test whether any retained copy works. Healthy replication links between primary and DR sites support asynchronous or synchronous availability and failover readiness, but they are a separate data-protection plane and do not validate external backup restore capability. Exam caveat: backup verification is a recovery control, not a replication or retention tuning task. Operational check: run a scheduled non-production restore of one VM from the latest backup, boot it in an isolated network, and record the time and result in the runbook.