Backup & Disaster Recovery for Continuity

Reviewed by Blake, Technical Services Operations Manager at LBT, who oversees backup testing and recovery drills for LBT's managed clients. Last updated July 2026.

This guide is LBT's pillar page for backup and continuity planning. For the access-control side of resilience, see access control policy: who can see what, and why it matters. For the wider case for managed support, see choosing managed IT support: the UK buyer's guide.

Most small businesses can tell you they "have backups." Far fewer can tell you how long it would actually take to get back to work if their server, their cloud account, or their office was unusable tomorrow morning. That gap — between having backups and having a plan — is exactly what a business continuity plan is meant to close.

This guide covers what a real business continuity plan contains, how backup, disaster recovery, and business continuity actually relate to each other (they're not the same thing, and conflating them is where most plans quietly fail), the 3-2-1 backup rule properly explained, and how to build a plan worth having rather than one that just looks good in a folder.

What a Business Continuity Plan Actually Is

A business continuity plan is a document that answers one question in detail: if something disrupts your ability to operate — a cyber incident, a fire, a flood, a failed server, a building you suddenly can't access — what exactly happens next, who does it, and how long does it take?

It is not the same as having backups. Backups are a component of a continuity plan, not a substitute for one. You can have perfect backups and still have no continuity plan, because backups tell you nothing about how long recovery takes, who's responsible for triggering it, how you'll communicate with staff and customers, or what "back to normal" actually looks like for your specific business.

Why This Gap Matters More Than Most Businesses Think

According to the government's Cyber Security Breaches Survey, only 25% of UK businesses overall have a formal incident response plan — and that average is propped up considerably by larger organisations. 75% of large businesses have one, and 53% of medium-sized businesses do. Smaller businesses, which make up the overwhelming majority of UK employers, sit well below that average (GOV.UK: Cyber Security Breaches Survey 2025/2026).

That gap is where businesses actually fail, not during the incident itself. Data loss, ransomware, and hardware failure are recoverable events for almost any business with decent backups. What isn't recoverable — or at least, not without serious, avoidable damage — is the chaos of figuring out your recovery process for the first time while it's actually happening, with customers waiting and staff unsure what to do.

Backup vs. Disaster Recovery vs. Business Continuity

These three terms get used interchangeably, and that's exactly where plans go wrong. They're related, but they answer different questions:

Backup answers "do we have a copy of our data somewhere else?" It's the raw material everything else depends on, and nothing more.

Disaster recovery answers "how do we get our systems and data back up and running?" It's the technical process — restoring servers, rebuilding infrastructure, recovering files — measured in recovery time objective (how long it should take) and recovery point objective (how much data, measured in time, you can afford to lose).

Business continuity answers the bigger question: "how does the business keep operating while all of that is happening?" It covers the people and process side that disaster recovery doesn't touch — who tells customers what's going on, where staff work from if the office is unusable, what the minimum viable version of "open for business" looks like, and who's actually in charge of making decisions during the disruption.

A business can have solid backups and a competent disaster recovery process, and still fall apart operationally because nobody had thought through the continuity layer on top.

The 3-2-1 Backup Rule, Properly Explained

The 3-2-1 rule is the industry-standard baseline for backup, and it's worth doing properly rather than approximately: keep at least 3 copies of your data, on 2 different types of storage media, with at least 1 copy stored offsite.

In practice for a small business, that typically looks like: your live working data, a local backup (for fast recovery of small, everyday issues like an accidentally deleted file), and a cloud-based offsite backup (to survive anything that affects your physical location — fire, flood, theft, or a building you simply can't get into). The offsite copy is the one businesses most often skip, usually because "we're on the cloud already" gets mistaken for "we're backed up" — file sync services like OneDrive or Google Drive are not, by themselves, a backup, because a file deleted or corrupted at the source syncs its deletion or corruption everywhere else too.

What a Real Business Continuity Plan Actually Contains

A plan that would hold up on a genuinely bad day includes, at minimum:

Clear roles and responsibilities. Named people, not job titles that happen to be vacant that week — who declares an incident, who leads the response, who handles customer and staff communication.

Recovery time and recovery point objectives, set deliberately rather than assumed, for each critical system: how long can this realistically be down, and how much data can we afford to lose if we have to restore from the last backup point?

A communication plan covering staff, customers, and suppliers — drafted in advance, not written under pressure while the incident is live.

Interim working arrangements — where and how the team works if the normal setup isn't available, even temporarily.

A tested recovery process, not just a documented one.

Testing: The Step Almost Everyone Skips

A backup that has never been restored is a hypothesis, not a safety net. The single biggest gap between businesses that survive a bad incident cleanly and those that don't is whether anyone has actually tried recovering from the backup before they needed to for real. Untested backups fail silently — corrupted files, incomplete backup jobs, credentials that expired months ago — and the only way to find that out before it matters is to run an actual test restore on a schedule, not just trust that the green tick in the backup software means what you assume it means.

Building Yours: A Practical Starting Point

Start by identifying which systems, if unavailable for a day, would actually stop the business functioning — not everything, just the genuinely critical few. For each one, set an honest recovery time objective and confirm your current backup actually meets it. Then write down, in plain language, who does what in the first hour, first day, and first week of a disruption. Test the recovery process at least once against real data, not a sample file. Review the whole thing at least annually, and immediately after any significant change to your systems or team.

None of this is conceptually difficult. What makes it hard in practice is maintaining it — keeping the plan current as your systems change, actually running the test restores on schedule, and having someone with the technical knowledge to notice when a backup has quietly stopped working properly months before anyone needed it. That ongoing discipline, more than the initial document, is where most self-managed continuity plans quietly decay.

Frequently Asked Questions

What's the difference between a business continuity plan and a disaster recovery plan?

Disaster recovery is the technical process of restoring systems and data. Business continuity is the broader plan for how the business keeps operating — people, communication, and interim arrangements — while that technical recovery is happening.

Is cloud storage the same as a backup?

Not on its own. Cloud sync tools keep a live, mirrored copy of your files — if that copy is deleted or corrupted, the sync typically carries that change to every other copy too. A genuine backup is a separate, point-in-time copy that isn't affected by changes to the live data.

How often should we test our backups?

At minimum, run a real test restore annually, and after any significant change to your systems. Businesses with fast-changing or highly critical data should test quarterly.

Do small businesses really need a full continuity plan, or is that overkill?

The plan should be proportionate to the business, not to some enterprise template — a five-person business needs a shorter, simpler plan than a 200-person one, not no plan at all. The core questions (what's critical, how fast do we need it back, who does what) apply at any size.