A company's nightly backup jobs have reported success for months, but when an incident forces a restore, the data cannot be recovered because the backup media are corrupt. Which practice would most likely have revealed the problem beforehand?
Select an answer to reveal the explanation.
Short Explanation
A backup you've never restored is just a hope. 'Job completed' tells you data was written, not that you can get it back. The only way to know is to actually restore it and check that it works, before the day you really need it.
Full Explanation
Restoration testing periodically recovers data from backups into a test environment and verifies that files open, databases mount and applications run. It is the only practice that proves backups are actually recoverable, catching corrupt media, missing data, broken catalogs and incomplete job scopes before an incident exposes them. Reviewing job logs confirms that each job ran and reported completion, which this company already had; a success status reflects the write operation, not the integrity or usability of what was written. Increasing frequency to hourly produces more copies on the same media and through the same process, so the corruption would simply be repeated more often without anyone noticing. Extending retention keeps more historical copies available, yet if the underlying media or process is producing unreadable backups, every retained copy may share the same defect. Exam caveat: restoration testing should cover different data types and full-system recovery, not only single-file restores, and should be timed so results can be compared against recovery objectives. Operational check: schedule recurring test restores from randomly selected backup sets, validate the recovered data against checksums or application-level checks, record the time each restore took, and treat any failed test as an incident to fix immediately.