Proving it works before you need it

Most organisations have backups. A meaningful share of them do not work, and this is discovered at the only moment it matters.

The ways they fail. The job stopped months ago and nobody noticed, because success is silent and failure is also silent. The backup completed and the file is truncated, because a dump that was interrupted still produces a file and still reports success. The backup is on the same server as the data. The backup is reachable from the network and ransomware encrypted it too. Nobody knows how to restore it. Or the restore works and takes four days, which for a business that cannot operate is the same as not having one.

So the only thing that establishes a working backup is a restore. Not a file, not a green status, not a report. Restoring it somewhere and checking the data is there.

Check the completion marker rather than the file's existence, because a truncated dump has a plausible size and reports success. Every backup tool writes something at the end when it finished properly, and checking for that is the difference between a backup and a file.

Two numbers define what you need. How much data you can afford to lose, which sets how often you back up. And how long you can afford to be down, which sets how you restore. Most organisations have never stated either, and then discover during an incident that their arrangements do not match what the business actually needed.