Backups Are Not a Recovery Plan: Test Your Restores Before You Need Them

Ask most organizations whether they have backups and the answer is yes. Ask when they last restored something from those backups, and how long it took, and the room usually goes quiet. A backup you’ve never tested is a hope, not a plan.

Backup and recovery are different things

A backup is a copy of your data. Recovery is the ability to get your organization working again. Recovery depends on things a backup report won’t show you: how long a restore takes, whether the restored systems actually work together, who knows how to do it, and what order things need to come back in.

Two numbers make this concrete:

• Recovery time objective: how long you can afford to be down before the impact becomes serious.
• Recovery point objective: how much data, measured in time, you can afford to lose.

If your leadership expects systems back in hours but a full restore would take days, that gap is a business risk that needs to be discussed now, not during an incident.

Protect the backups themselves

Modern ransomware groups know backups are your way out, so they go after them first. Make sure your backups are:

• Separate, with at least one copy stored away from your main network and your everyday administrator accounts.
• Immutable, meaning they can’t be changed or deleted for a set period, even by an administrator.
• Protected by strong sign-in, with multi-factor authentication on the backup console.

The long-standing 3-2-1 rule is still a good guide: three copies of your data, on two different types of storage, with one copy offsite.

Don’t forget cloud services

Microsoft 365, Google Workspace and other cloud platforms keep your service running, but their built-in retention features aren’t designed to be a complete backup. Deleted items expire, and data that’s encrypted or deleted by an attacker using a legitimate account can be lost. A dedicated backup for cloud email and files is usually worth the cost.

Test like you mean it

Build a simple testing routine:

1. Monthly: restore a few individual files and a mailbox to confirm the basics work.
2. Quarterly: restore a full server or critical application to an isolated environment and time it.
3. Annually: run a tabletop exercise where leadership walks through a major outage and decides what comes back first.

Write down what you learn each time. The documentation you build from testing becomes your recovery runbook.

The bottom line

Backups are only valuable if you can recover from them quickly and completely. Protect them from attackers, cover your cloud data, and test regularly so the first time you restore your systems isn’t during a crisis.

Not sure your backups would hold up? Ask us about a recovery readiness review.