THE MOST COMMON SERIOUS FINDING IN THIS COURSE. A green backup job proves A FILE WAS WRITTEN; only a restore proves YOU CAN COME BACK.
Ask any estate whether it has backups and the answer is yes, with a job that has succeeded every night for a year. Ask when a restore was last performed and the answer is usually silence, or a date somebody is not sure about, or "we restored a table once".
THAT GAP IS THE FINDING, AND IT IS THE MOST COMMON ONE IN THIS COURSE. A successful backup job proves the utility ran and wrote something. It does not prove the file is complete, that it is readable, that the archives to go with it exist, that anybody knows the procedure, or that the whole thing fits in the time the business assumes. Every one of those is only established by doing it.
AND THE WAYS A GREEN JOB IS WORTHLESS ARE ALL REAL AND ALL SILENT. A backup missing a datafile added six months ago that nobody added to the script. A backup to a destination that is itself lost with the host. An archive gap, so the restore can be loaded and not opened. A backup nobody can decrypt because the key was on the machine that died — Lesson 12's fifth failure, and complete data loss with a perfect backup in hand.
SO THE ONLY HONEST STATEMENT ABOUT RECOVERABILITY IS A DATE: "we last restored this system on the ninth, and it took four hours." Anything else — a backup schedule, a retention policy, a monitoring dashboard — describes an intention rather than a proven capability.
THE TEST IS A FULL RESTORE TO A SEPARATE HOST, WHICH IS LESSON 9, BECAUSE THAT IS THE CASE THAT FINDS THE MISSING PIECES. Restoring onto the original host reuses configuration that is already there and quietly proves less than it appears to.
AND SCHEDULE IT RATHER THAN INTENDING IT. It never becomes this week's most urgent task, which is exactly how a year passes — and the day it becomes urgent is the day it is too late to find out.