Bring Your Data Back From the Dead: Build a Recovery Plan That Works

In Tuesday’s Backup Vault, we talked about a scary reality: businesses often assume their data is protected because someone tells them, “We have backups.”

But having backups and being able to recover from a disaster are two very different things.

A backup is a copy.

A recovery plan answers a much more important question:

How do we get the business running again?

If ransomware encrypted your systems tonight, a server failed tomorrow morning, or critical files suddenly disappeared, could your team answer that question with confidence?

That’s what a real recovery strategy is designed to do.

Identify Critical Systems

Not everything needs to come back online at the same time.

Your accounting system may be more important than an archived file server. Your customer database may need to be restored before an internal application. For some businesses, email is critical. For others, production systems, project files or line-of-business applications come first.

Identify the systems and data your business cannot operate without, then establish the order in which they need to be recovered.

This shouldn't be a decision your team makes for the first time during an emergency.

Define How Much Data You Can Afford to Lose

Imagine restoring your systems only to discover that your most recent usable backup is from yesterday.

Could your business recreate an hour of lost work?

Four hours?

An entire day?

The answer helps determine how frequently critical information needs to be backed up. A business processing hundreds of transactions every hour has very different requirements from one where files change only a few times per day.

The question isn't simply, “Are we backing up?”

It's “How much could we lose between backups, and is the business comfortable with that?”

Define How Long You Can Be Down

The other side of recovery is time.

If a critical system takes three days to restore but the business can only tolerate four hours of downtime, you don't have a recovery plan that matches the needs of the business.

Consider what happens while systems are unavailable.

Can employees work? Can customers place orders? Can invoices go out? Can your team access project information? Does production stop?

For each critical system, determine how long the organization can realistically operate without it.

Find that out now—not during an outage.

Protect the Backups From the Attack

Cybercriminals understand backups too.

Modern ransomware attacks aren't necessarily limited to encrypting the files employees use every day. Attackers may attempt to find and compromise backup systems as well, specifically because those backups represent your way out.

That's why recovery copies need protection of their own.

A compromised production environment shouldn't automatically mean compromised backups.

Strong access controls, separation from production systems, multiple recovery copies and appropriately protected or immutable backups can make the difference between recovering your data and negotiating with an attacker.

Know Who Does What When Something Goes Wrong

Technology is only part of recovery.

Someone needs to declare the incident. Someone needs to contact your IT or cybersecurity team. Someone may need to communicate with employees, customers, vendors, insurance carriers or legal counsel.

And someone needs the authority to make decisions quickly.

A recovery plan should establish those responsibilities before the crisis begins.

When the business is down, you don't want executives searching through emails trying to figure out who they're supposed to call.

Test Recovery — Not Just Backup

This may be the most important step.

A dashboard displaying green checkmarks and the word “Successful” can tell you that a backup job completed.

It doesn't necessarily tell you what will happen when you need to rebuild a server, recover an application or restore critical business data under pressure.

Test the restoration process.

Can the data actually be recovered?

How long does it take?

Are the applications usable afterward?

Does the recovery time match what the business expects?

Did the right data come back?

Testing can expose problems while they're still inconveniences instead of emergencies.

Ask Your IT Team This Question

Business leaders don't need to know every technical detail of their backup infrastructure.

But they should be able to get a clear answer to this:

“If our critical systems went down today, what would we restore first, how much data could we lose, and how long would it take to get us operating again?”

If nobody can confidently answer that question, that's worth addressing.

Because the goal isn't simply to back up your data.

The goal is to recover your business.

Survive the Scare

Identify what's critical. Set realistic recovery objectives. Protect your recovery copies. Know who's responsible. And most importantly, test the plan.

A backup you've never successfully restored is a promise you haven't verified.

When disaster strikes, you don't want to discover The Backup Vault is empty.