Guide · Backups
How to check your business backups actually work
A plain-English test anyone can run in an afternoon, and the 3-2-1 rule without the jargon.
Almost every business we talk to says they have backups. Far fewer can tell us when they last restored anything from them. Those are very different things.
A backup you've never restored from isn't a backup. It's a hope. This guide shows you how to turn the hope into something you know, in an afternoon, without needing to be technical.
Backups fail quietly
Backups rarely fail in a dramatic way. They fail quietly, months before anyone notices. The usual culprits:
- The job stopped running. A password changed, a disk filled up or a licence expired, and the backup software has been sending a failure email to someone who left last year.
- It's backing up the wrong thing. The files are there, but the database behind your main system isn't, or it's copying a database file while it's in use, which gives you a copy that won't open.
- It only goes back a day. If you only keep last night's copy and nobody spots a problem for a week, the backup has faithfully copied the problem.
- The backup sits next to the original. A USB drive plugged into the server, or a second folder on the same network. Ransomware encrypts both, a fire takes both, a burglar takes both.
- Nobody knows how to restore. The person who set it up has gone, and the restore needs a password or a key that only they had.
Testing catches every one of these. Nothing else does.
The 3-2-1 rule, without the jargon
You'll see this everywhere. It's good advice, and it's simple:
- 3 copies of anything that matters: the original, plus two backups.
- 2 different kinds of storage, so one fault doesn't take out both. For example, a backup server in the office and cloud storage.
- 1 copy off site, somewhere a fire, flood or burglary at the office can't reach.
These days we'd add one more: at least one copy that can't be changed or deleted for a set period, even by someone with your admin password. Most cloud storage can do this (look for "immutable", "object lock" or "retention lock"). It's what saves you when ransomware gets hold of an admin account and goes looking for the backups, which it now routinely does.
What needs backing up
Before you test, make a list. Most businesses have more than they think:
- Shared files, wherever they live (a server, SharePoint, Google Drive, Dropbox).
- Email. Microsoft 365 and Google Workspace keep deleted items for a while, but that isn't the same as a backup. Microsoft's own services agreement recommends that you regularly back up your content.
- Databases behind your own systems: the CRM, the job system, the website.
- Your website and online shop, including the uploads folder, not just the code.
- Accounts software, if it's on a local machine rather than in the cloud.
- Servers themselves, if rebuilding them from scratch would take more than a day.
- The odd laptop where someone keeps everything on the desktop. There's always one.
How to test a restore
Do this once a quarter. Put it in the diary now, or it won't happen.
- Pick three things to restore. One ordinary file, one mailbox (or a folder of email), and one whole system: a database, a website or a server. The file test proves the basics work. The system test is the one that matters.
- Pick a date to restore from. Not last night. Choose something from two or three weeks ago, so you also prove that older copies are kept.
- Restore somewhere safe. Never over the top of the live version. Restore the file to a new folder, the mailbox to a test account, and the database or server to a spare machine or a temporary cloud server.
- Open what you restored. Open the file. Read an email. Log in to the restored system and look at a record you know exists. If it's a database, check the most recent entries are from the date you expected.
- Time it. Write down how long the whole system took to restore and get working. That number is how long your business would be down. If it's three days and you can't afford three days, now you know.
- Write it up. Half a page: what you restored, from when, how long it took, and anything that went wrong. Keep these. If a big customer or your insurer asks how you'd recover from ransomware, a dated record of a working restore is about the best answer there is.
- Delete the test copy once you're done, so you don't leave a spare copy of customer data lying around.
Five more things to check
- Are the backup failure alerts going to someone who still works here, and do they read them?
- How far back can you go? A month of daily copies is a sensible minimum for most small businesses.
- Is the off-site copy really off site, and really separate? If the same admin login can delete both the original and the backup, it isn't separate enough.
- Are the backup's passwords and encryption keys written down somewhere safe that isn't the thing being backed up? A password manager is ideal.
- Could someone other than the person who set it up do the restore, using only what's written down?
Write a one-page recovery plan
When something goes badly wrong, nobody reads a 40-page document. One page is enough: who to call, what order things get restored in (usually email and the main business system first), where the backups are, where the passwords are, and who's allowed to make decisions. Print it. If your server has been encrypted, the copy saved on the server won't help much.
Start with ten minutes today
If you've never tested a restore, do the file test today. It takes ten minutes and tells you whether anything is working at all. Then book a proper afternoon for the full system test within the month.
If nobody has tested a restore in years, the backups usually aren't the only thing that's slipped. It tends to mean nobody owns technology across the business, and the same is true of updates, access and suppliers. Have a look at the signs you've outgrown your IT and see how many ring a bell.
For the servers we look after, nightly database backups go off site with an alert if one fails, and a test restore every quarter, with a written result, is part of the job. That's us, so apply the usual pinch of salt. Plenty of good IT companies test restores too. The important thing is that someone owns it.
Backup questions
Restore at least one whole system every quarter, and a file or two every month. Also test after any big change, such as a new server, a move to the cloud or new backup software.
Keep three copies of your data, on two different kinds of storage, with one copy off site. Many people now add a copy that cannot be changed or deleted for a set period, to protect against ransomware.
Not in the way most people assume. Microsoft keeps deleted items for a limited time and protects against its own hardware failing, but it is not designed to bring back everything from a month ago after an accidental deletion or an attack. A separate backup is sensible.
Restore from it and open what you restored. A report saying the backup succeeded only tells you something was copied, not that it can be used.
Only if the ransomware can't reach them. Keep at least one copy off site, in a separate account with separate logins, ideally one that can't be changed or deleted for a set period. Then test that you can restore from it.
Not sure your backups would work?
Tell us what you have and we'll tell you how we'd test it.
What systems you run, where the backups go, and when anyone last restored from them. If the honest answer is "never", that's fine. It usually is.
What we will cover:
- What needs backing up that probably isn't
- Whether your off-site copy is really separate
- How long a full restore would take
Rather talk now? Book a call or ring 01474 639 089.
We reply within one working day.
