Why your backups are probably not tested, and how to fix it in an afternoon
When we take on a new office, the audit in the first fortnight almost always turns up the same thing. There is a backup. It was set up years ago by someone who has since left. The little green tick has been green for so long that nobody looks at it any more. And nobody has ever tried to get a file back out of it.
That last part is the problem. A backup that has never been restored is a hope, not a plan.
What usually goes wrong
The failures we see are rarely dramatic. The job ran, but it has been backing up an empty folder since the shared drive moved. The job ran, but the licence lapsed and it has been silently skipping the mail server. The job ran, but the disk it writes to sits in the same cupboard as the server it protects, so a flood or a thief takes both.
None of those show up as a red light. They show up on the day you need the backup, which is the worst possible day to find out.
The one test that settles it
Pick a file. Any file, ideally one that changed last week. Ask whoever looks after your IT to restore it to a new location, and time how long it takes from the request to the file being in your hands.
If the answer is under an hour and the file is the version from last week, your backup works. If the answer involves a pause, a phone call or the words “it should be fine”, it does not.
What a tested backup looks like
For every office we support, the backup runs to an encrypted copy off site, and once a month an engineer restores something from it and writes down what came back and how long it took. That line goes in the client’s monthly report. It is one sentence, and it is the most important sentence on the page.
Doing it yourself
If you are not on a plan that includes this, do the file test above this week. Then put a reminder in the calendar to do it again in a month. It takes fifteen minutes and it turns a hope into a plan.
