How often should you test your backups?

Spot-check monthly that jobs are completing and the data is where it should be, restore something real every quarter and time it, and run a full test at least annually including the systems everything else depends on. Also test after any significant change, because a backup configured for last year's estate quietly stops covering this one.

The reason the cadence matters is that backups fail silently, and almost always in the same way: not with an error, but with a scope that no longer matches reality. A new server is added and never included. A database moves and the job keeps backing up an empty folder. A retention setting is changed to save space and quietly discards the history you were relying on. Every one of those produces green dashboards for months, which is why a job report is a statement about software and a restore is a statement about your business.

Scale the effort to the tier. The monthly check is minutes: are jobs completing, is the data volume roughly what you would expect, has anything new appeared that is not covered. The quarterly test is the one that earns its keep, and it should be a real restore of something that matters, timed, with a person who uses that system confirming the result is usable rather than merely present. The annual test is the closest thing to the real event: a critical system brought back in dependency order, with the clock running against your recovery target.

Two things make this stick. Write down the date, the duration and who verified it, because that log is the evidence an insurer, a tender panel or an Essential Eight assessment will actually ask for, and reconstructing it later is impossible. And put it on someone's calendar with a name attached, since testing that happens when someone remembers is testing that happens after the incident. If you cannot say when your last real restore was, that is this week's job: 1800 456 567.