The Hard Truth
Think of a backup like a spare tire in your car. You feel safe knowing it's there — but if you've never actually checked whether it's inflated, you might discover it's flat exactly when you need it most. A backup file that has never been restored is a spare tire you've never inspected.
There is a saying in the database world: "You do not have backups. You only have restores."
A backup file sitting in an S3 bucket is Schrödinger's Backup: it exists in a state of both "valid" and "corrupt" until you actually try to restore it. The act of restoring is the only thing that collapses the uncertainty. Until then, you are operating on faith, not evidence.
Many companies have failed because they religiously took backups for years but never tested restoring them. When disaster struck, they discovered the files were empty, encrypted with a lost key, silently truncated due to a disk quota, or took three weeks to restore when the business needed recovery in three hours. The backup process was green. The restore process had never been run.
As a DBRE (Database Reliability Engineer), your job isn't to run backups. It is to run Restore Drills — scheduled, automated, verified exercises that prove your recovery capability before you need it.
Interviewers frequently ask: "How do you know your backups are working?" The wrong answer is "We check that the backup job succeeds." The right answer is: "We run automated restore drills on a schedule, restore to an isolated environment, and run validation checks against the restored data. A backup is only proven valid when a restore succeeds."