A backup you have never restored from is an assumption. The only way to know it works is to pick a file, restore it somewhere else, and open it — and that takes about fifteen minutes once a quarter.
Most small businesses we meet have backup software installed and a green checkmark somewhere. That checkmark means the job ran. It does not mean the data inside is complete, readable, or recent enough to be useful on the worst morning of your year.
How to run a test restore yourself
You do not need a technician to do this the first time. Pick something ordinary — last month's payroll spreadsheet, a client folder, a QuickBooks company file — and walk it through the whole path.
- Open your backup software and find the restore or recovery option, not the backup job list.
- Choose a recovery point from a few days ago, not last night's. If only the newest one works, you have a problem worth knowing about.
- Restore to a different folder, like a new folder on your desktop. Never restore over the live file; you want to compare, not overwrite.
- Open the restored file. Check it actually opens, and check the contents match what you expect for that date.
- Write down the date you did it and how long it took. That number is the useful part.
If you get stuck at any step, that is the finding. A backup you cannot restore from under calm conditions is not one you will manage during a flood or a ransomware call.
What a real recovery looks like
Restoring one file is the easy case, and it is also the most common one — somebody deletes a folder, or a spreadsheet gets saved over. Losing a whole server is different, and the honest question is not whether you have a backup but how long you would be down.
Work out the rough steps for your own setup. Where does the replacement hardware come from, and how long does it take to arrive? If the backup lives on a USB drive plugged into the server, is there a second copy somewhere off-site or in cloud storage, since a fire or a theft takes both the server and the drive sitting beside it? If your line-of-business software needs a licence key or a vendor to reinstall it, who has that key and that phone number?
Write the answers on one page and keep a printed copy. During a real outage, the network is often the thing that is down, which means the document stored on the server is the document you cannot read.
The three things that quietly break
Backups tend to fail slowly rather than suddenly. Three patterns account for most of what we find.
The backup drive fills up, so the software starts trimming older recovery points until you only have two or three days of history. Ransomware that sat quiet for a week will outlast that window.
Someone adds a new server, a new shared folder, or a new virtual machine, and nobody adds it to the backup job. The old data is protected perfectly and the new data is not protected at all.
The drive itself ages. External drives that stay plugged in and spinning for four years do fail, and the failure often shows up first as backup jobs that take twice as long or throw an error every third night.
A schedule you will actually keep
Once a quarter, restore one file and open it. Once a year, ask harder: could we rebuild this server, and roughly how many days would that take? Check the backup drive's free space and its recovery point count monthly — that is the pair of numbers that predict trouble earliest.
We do this work for clients as part of our managed maintenance, including test restores that prove the backup by actually recovering a file. But the fifteen-minute version is worth doing yourself this week, whoever ends up owning it.
