Beyond 3-2-1: Proving Your Business Backups Actually Work
Most businesses we speak to in Edinburgh know the 3-2-1 rule, and our primer on 3-2-1 backups covers it. The harder problem is proving that the backup you're paying for holds what you think it does, and that you could get it back fast enough to keep trading. That's an operating discipline, not a product you buy once.
Start with an inventory, not a product
Almost every gap we find starts the same way: someone bought a backup product, pointed it at the server, and the job was considered done. The question isn't "is the server backed up" — it's "what would we need to be trading again on Monday, and where does each of those live today?" List them: invoices, customer records, email, contracts, the spreadsheet the quoting process secretly depends on. Then mark the ones you've restored from in the past year. That column is usually much shorter.
The things that get missed
The same four gaps come up again and again, whatever the size of the business.
- Cloud services. Microsoft 365, Google Workspace, cloud accounting and payroll each hold something you would need on Monday, and each keeps deleted items for its own limited window. The question isn't whether the provider is reliable; it's how far back you could actually go, confirmed in writing rather than assumed.
- Laptops and desktops. If your team saves anything locally — and they do — the endpoint is a data location. A stolen laptop in Livingston shouldn't cost a fortnight of work.
- Configuration. Firewall rules, application settings, user permissions, printer and phone setups. Files restore quickly; the week spent rebuilding how everything was configured is what stops you trading.
- The NAS that is the only copy. A network drive in the cupboard is storage, not a backup, however many disks it has. Mirroring protects you from a disk dying, not from deletion, fire, theft or encryption.
Sync, versions and retention are three different things
Be pedantic here: it decides what you survive. Sync mirrors the current state, so a deletion or corruption propagates. Version history steps back through recent edits of a file. Retention is how far back your copies reach, and it's the only one that saves you from a problem found late: a database corrupted in June and noticed in September, or ransomware that sat dormant before triggering. Two weeks of retention is a decent safety net and a poor insurance policy.
Two numbers that were probably never chosen
Your recovery plan may already name an RPO and an RTO. The question is whether either was chosen by the business or inherited from whatever the software does by default.
- How much work can you afford to lose? If backups run overnight, a failure late in the afternoon costs the whole day, for everyone. Some businesses can absorb that. For others it's the difference between a bad week and a closed one.
- How long can you afford to be down? Holding the data isn't the same as being operational. Pulling a large dataset back over broadband takes real hours, before anyone reinstalls software or reconfigures a server.
Agree both with whoever runs the business, not only whoever runs the IT, then record them in your disaster recovery plan.
Run a real restore drill
Restoring one file proves the software runs. It doesn't prove you can recover. Once or twice a year, do it properly: pick a realistic scenario, restore to spare hardware rather than over live data, have someone time it, and write down every password, licence key and missing step you hit. The drill's real output isn't the restored data — it's the list of things that surprised you. If you run your own kit, the on-site versus cloud trade-offs shape it.
Somebody owns it, and it's written down
Backups fail silently, and the failure is usually organisational, not technical. A named person should be accountable for reading the alerts, chasing the ones that never arrive, and re-checking coverage when a system is added. Treat a run of quiet weeks as a prompt to test the alerting, not as proof all is well. When someone leaves, check what left with them — the account the backup job authenticated as, or the drive that went home in a bag.
Keep the rest on one page: what is protected, where each copy lives, how far back it reaches, who gets the alerts, and the date of the last successful restore. Give the backup console its own credentials and multi-factor authentication, not a day-to-day admin login. It takes an hour, and it shows you at once which line you can't fill in.
Let's check your backups together
We're based in Wishaw and work with businesses across Edinburgh, Musselburgh and Bathgate. If you'd like someone to review what's covered, run a restore drill with you and document the gaps, our business IT support and managed IT teams can help, with a clear quote before any work.