A company has taken nightly database backups for three years, and every job has reported success. During an audit, the DBA admits that no backup has ever been restored. Which practice should the DBA put in place?
Select an answer to reveal the explanation.
Short Explanation
A backup you've never restored is a parachute you've never opened; you're hoping, not knowing. Schedule real test restores, check the data, and time them against your RTO. A green 'success' light only tells you a file got written.
Full Explanation
A backup is verified only when it has been restored successfully. Scheduled test restores to a non-production server prove that the files are readable, that the restore procedure and any required keys, scripts and permissions work, and that the restored database passes integrity checks and contains the expected data. Timing the restore also confirms whether recovery fits the recovery time objective, information no job log can provide. Relying on the software's success status confirms only that a job finished and wrote output; misconfigured jobs can back up the wrong database, skip files, or produce output that fails on restore, and three years of green status can hide all of these. Extending retention keeps more copies but does not tell the team whether any of them can be restored, so it multiplies untested assets. Writing a second identical copy protects against loss of one file, but if the backup is flawed, both copies are flawed in the same way. Exam caveat: test restores and hash validation complement each other; a hash proves the copy matches the source, while a restore proves the source is usable. Operational check: restore last night's backup to a test server, run an integrity check, compare row counts for key tables with production, and record the elapsed time.