Your backups are a hypothesis until you test a restore

Ask a business owner if they have backups and the answer is yes. Ask when someone last restored anything from them and the room goes quiet. That gap is where businesses end: not because they skipped backups, but because they trusted them untested.

Backups fail silently. That is the whole problem

Nobody gets an alert saying “your backups have quietly become useless”. Instead:

• The job reports success every night, but the scope was set three years ago and the new file server, the new SharePoint site, and the finance database are not in it.
• The agent stopped after a migration or an update, and the last good backup is from March.
• The backups run, but to a NAS in the same cupboard as the server, which floods, burns, or gets encrypted along with everything else.
• The restore works, but takes four days, and the business assumed four hours.

Every one of these shows green in the dashboard. Only a restore attempt shows the truth.

Ransomware changed the assignment

Modern ransomware crews do not encrypt your files and hope. They spend time in the network first, find the backups, and delete or encrypt them before triggering anything visible, because a business with working backups does not pay.

That is why at least one copy must be immutable or offline: object storage with immutability enabled, an air-gapped copy, or a service where a compromised admin account still cannot purge history. A backup your own domain admin can delete is a backup the attacker can delete, because on the day it matters, they are your domain admin.

Microsoft 365 is not backing itself up

The assumption that “it’s in the cloud, Microsoft has it” retires more data than hardware failure ever did. Microsoft runs the service; retention of your data is your job (their own terms say so). Deleted mailboxes age out, retention policies have gaps, and a synced ransomware encryption or a malicious deletion replicates into OneDrive and SharePoint just fine. Microsoft 365 needs its own backup, separate from the tenant it protects.

Know your two numbers: RTO and RPO

Two questions define what your backups need to be, and most businesses have never answered either:

• RPO (recovery point objective): how much work can you afford to lose? If the answer is “an hour”, nightly backups are already a failed design.
• RTO (recovery time objective): how long can you be down? If the answer is “a day”, a restore that needs a week of rebuilding servers first is a continuity plan on paper only.

Agree the numbers, then check the backup design against them. This is the five-minute conversation that decides whether a bad day is an inconvenience or an extinction event.

What a restore drill actually looks like

1. File-level restore: a named file from a specific date, recovered and opened. Minutes, and it catches scope and agent failures.
2. Mailbox or M365 item restore: proves the cloud side is genuinely covered.
3. Full system restore (at least annually): a server or VM brought back somewhere isolated, timed against your RTO. This is the one that finds the four-day surprise.
4. Record it: date, what was restored, how long it took, what failed. If your IT provider runs your backups, this evidence should be arriving in your reports without you asking.

The honest summary

Backup software is a commodity; verified restores are the product. The businesses that survive ransomware, floods and fat-fingered deletions are not the ones with the most expensive backup tool. They are the ones who knew their RPO and RTO, kept a copy the attacker could not reach, covered Microsoft 365 separately, and had restore drill results recent enough to trust. If your last test restore was more than a quarter ago, that is the gap to close this month.