A scheduled job that prints SUCCESS tells you a process ran. It does not tell you the data is readable, complete, or that you still own the tooling to put it back. A copy earns the name backup only once you have restored from it and checked the result. Until then you have bytes and a hope.
The gap is not theoretical. In 2017 GitLab lost production data during an incident and discovered that five separate backup and replication methods had all failed silently: dumps produced empty files, cloud sync was misconfigured, and the snapshots they counted on were never taken. They recovered only because an engineer happened to have a six-hour-old copy sitting on a staging server. Every one of those five methods had been reporting healthy.
Treat the restore, not the job, as the deliverable. A backup you have never restored is an untested assumption parked next to your money. The job log is the least trustworthy signal in the whole chain, because it goes green whether or not the bytes are any good.
If you have never restored a given backup set, plan as though you do not have it. Book the first test restore this week, not after the next outage.