The one backup mistake that costs businesses everything
The one backup mistake that costs businesses everything is never checking that a backup can actually be restored. Plenty of offices have backups running every night and a green tick on a dashboard, and they feel covered. Then something breaks, they go to get their files back, and they find the copies are incomplete, corrupted, or stored in a form nobody remembers how to open. A backup you have never tested is a hope, not a plan.
A backup that runs is not the same as a backup that works
Backup software reports on what it was told to copy and whether the copying finished. It does not know whether the files will open, whether the database inside them is intact, or whether you still have the password for the encrypted drive. Those problems stay hidden until the day you need the data, which is the worst possible time to find them.
The gap is common because restoring is tedious and nothing forces anyone to do it. Setting up the backup is a one-time job. Restoring is something you only do in a crisis, so it tends to get skipped. The people who end up in trouble are rarely careless about backing up. They just never confirmed the result.
How to test a restore without breaking anything
You do not need a full disaster exercise to find out whether your backups work. Start small and do it on purpose:
- Pick one folder that matters, such as current client files or the accounting folder.
- Restore it to a different location, not on top of the live copy. A spare folder on another machine works well.
- Open a few files from the restored copy. Check that a spreadsheet calculates, a document shows the latest changes, and a database loads.
- Write down how long the restore took and whether anything was missing.
- Delete the test copy once you are satisfied, so nobody mistakes it for live data later.
If the restore works, you have real evidence. If it fails, you have found the problem on a quiet Tuesday rather than during an outage, and that is a far better outcome.
Keep one copy the main system cannot reach
A test restore tells you the backup is good. It does not help if the backup gets damaged along with everything else. Ransomware, a compromised login, or a mistaken mass delete can reach any drive that stays permanently connected to your network, including a backup drive or a cloud sync folder that updates automatically.
The usual rule is to keep several copies, on at least two different types of storage, with one copy kept separately from the main site or network. In practice that might be a local backup plus a copy in a cloud backup service that does not sync deletions straight away. The point is that a single bad event should not be able to wipe out every copy at once. If you cannot say where your second copy lives and who can delete it, find out today.
How often to test, and what to do when a test fails
The rule is simple: test your first restore now, then test again after any significant change, such as a new server, a new accounting system, or a change in backup software, and at least every few months even if nothing has changed. If you have never restored from your backups at all, treat that as the first job for this week.
When a test fails, do not panic and do not just switch the backup on again. Find out which files or systems were affected, fix that specific gap, and run the test again until it passes. Keep a short note of the date, what you tested, and the result. That note is useful the next time someone asks whether the backups are working, and it is the closest thing to proof you will have.
Your next step is small. Choose one important folder this week, restore it to a spare location, open a few files, and write down what happened. If that goes smoothly, do the same for your most critical system. If you would rather have someone else set up the test and check the offsite copy properly, that is a reasonable call too. Either way, the goal is the same: know, not hope, that you can get your business back when you need to.