A backup you have never restored is not a backup

Three of the last five businesses we audited had backups running and no idea whether they worked. Two of them did not.

Backup software is good at telling you it ran. It is much less good at telling you whether the thing it produced can be turned back into a working business. Those are different questions, and only one of them matters on the morning something has gone wrong.

What we actually check

On a health check we ask for a restore, not a report. Three requests, in this order:

• A single file from four months ago. Tests retention depth and whether anyone can actually drive the console.
• A mailbox belonging to someone who has left. Tests whether your Microsoft 365 or Google Workspace data is backed up at all, or whether you have been relying on the platform's retention policy without knowing it.
• The accounting database, restored somewhere it can be opened. Tests the thing you would actually need. A database file that restores but will not mount is not a restore.

If any of those take more than an afternoon to produce, there is a gap between what you are paying for and what you have.

The failure is almost never the backup job. It is the one folder nobody added after the office moved to a new share.

The five gaps we find most often

1. Scope drift. The backup was configured correctly three years ago. Since then there is a new file server, a new share, a new line-of-business application and a folder on someone's desktop that the whole sales process depends on. None of them were added.
2. The SaaS assumption. "It's in the cloud, so it's backed up." Microsoft and Google are responsible for keeping the service running. They are not responsible for recovering the mailbox someone emptied in March, or the SharePoint library that a ransomware-infected laptop encrypted and synced.
3. Every copy on the same network. A NAS in the server room is a good second copy and a bad only-copy. Anything that can be reached with a stolen domain administrator password will be encrypted along with everything else.
4. No immutability. Modern ransomware crews look for the backup console first and delete or encrypt the repository before they touch production. If your backups can be deleted by a credential, they can be deleted by an attacker holding it.
5. Nobody knows the sequence. Even with good backups, if the restore order — domain controller, then file server, then application server, then clients — lives in one person's head, your recovery time is however long it takes to reach that person.

Start with two numbers, not with software

Before comparing products, get the business to answer two questions. They are not technical questions.

A four-hour RTO and a fifteen-minute RPO is achievable and costs real money. A two-day RTO and a one-day RPO is fine for plenty of businesses and costs very little. The mistake is not choosing the cheap option — it is never having the conversation, then discovering the answer during an incident.

3-2-1-1-0, and why the extra digits exist

The old rule was 3-2-1: three copies, two media, one offsite. The version the industry now recommends adds two more conditions, both of them a direct response to ransomware:

• 3 copies of your data
• 2 different types of storage
• 1 copy offsite
• 1 copy immutable or air-gapped — it cannot be altered or deleted, even with valid credentials
• 0 errors, verified by actually testing the recovery

The last digit is the one people skip, and it is the only one that produces evidence. Veeam's 2025 ransomware research surveyed 1,300 organisations and found that of those attacked, only 10% recovered more than 90% of their data, while 57% recovered less than half. Notably, 69% of victims had believed they were prepared beforehand. Confidence is not a control.

A quarterly habit that costs an hour

Put a restore test in the calendar every quarter and write down how long it took. That single number tells you more about your resilience than any dashboard.

1. Pick one item from each category: a file, a mailbox, a database.
2. Restore to an isolated location, never over the live copy.
3. Open the restored data and confirm it is intact and current, not just present.
4. Record the elapsed time, who did it, and anything that slowed it down.
5. Fix the thing that slowed it down before the next quarter.

Once a year, go further and run a tabletop: assume the file server is encrypted at 09:00 on a Monday and talk through who does what, in what order, with which phone numbers. It usually surfaces two or three assumptions that were never true.

When we run retainers we do this on your behalf and the result goes in the monthly report, pass or fail.

The Mauritius-specific parts

Two things we plan for locally that a generic guide will not mention. First, cyclone season and grid interruptions: an offsite copy that sits in another building on the same island, with the same power and connectivity risk, is only half an offsite copy. For most clients we keep at least one copy in a cloud region outside Mauritius.

Second, the regulatory clock. If a ransomware incident exposes personal data, the Data Protection Act 2017 requires notification to the Data Protection Commissioner without undue delay and, where feasible, within 72 hours of becoming aware. A tested restore is what lets you spend those 72 hours reporting accurately instead of guessing at what was lost. The same applies to a compromised mailbox — the scenario we described in the Port Louis invoice fraud case.

Frequently asked questions