A private cloud team backs up hypervisor host configurations every night, but nobody has ever restored a guest VM from backup, and an auditor questions whether recovery would actually work. What should the team do?
Select an answer to reveal the explanation.
Short Explanation
A backup you've never restored is just a hopeful file. You need to back up the guests, not only the hosts, and then actually practise bringing a VM back and checking it works. The trap is improving the backups you have instead of proving they can recover anything.
Full Explanation
Host and guest backups protect different things. Host configuration backups capture hypervisor settings, networking and cluster configuration so a host can be rebuilt; they do not contain the operating systems, applications and data inside guest VMs. Guest backups, taken at the VM level or from within the guest OS with application-consistent methods, are what allow a workload to be recovered. A backup capability is only proven by restore testing: scheduled tests restore sample VMs to an isolated environment, confirm they boot and that applications and data are intact, and measure recovery time against objectives. Increasing the frequency of host configuration backups adds recovery points for the wrong layer and still provides no evidence that anything can be restored. High availability restarts VMs on surviving hosts after a host failure, but it does not protect against data corruption, deletion, ransomware or loss of the VM's storage, all of which require backups. Encrypting and replicating host configuration backups improves their confidentiality and resilience, yet guest data remains unprotected and recovery remains untested. Exam caveat: the outline phrases this as configuration of host and guest OS backup and restore functions, so restore, not just backup, is part of the requirement. Operational check: review the backup scope to confirm every production VM is included, and check the latest restore test report for success and measured recovery time.