What is the difference between a backup and disaster recovery?

A backup is a second copy of your data sitting somewhere safe. Disaster recovery is the process that turns that copy into a working business again: how quickly you can be operational, on what hardware, and who does what while the clock is ticking. You need both.

RPO (Recovery Point Objective) is how much data you can afford to lose. If your backup runs nightly, your RPO is up to 24 hours. RTO (Recovery Time Objective) is how long you can afford to be down. Deciding these numbers before you buy any backup solution tells you what setup actually makes sense for your business.

Does Microsoft 365 back up your data automatically?

No. Microsoft 365 includes retention and recycle bin features, but these are not a backup. A proper third-party backup solution for Microsoft 365 is needed to protect your email and files against accidental deletion, ransomware, and admin errors. Many small businesses assume Microsoft handles this and are wrong.

How often should a small business test its backups?

At minimum, once a year. A backup you have never successfully restored from is not a backup; it is an assumption. A good IT support provider will test a restore annually and confirm the results. Monthly monitoring of backup job success is also recommended so you know the backup is actually running.

A small office server cabinet with a warning LED and a portable external backup drive on a tidy desk

Written by Phil on 30 January 2026.

Backups vs Disaster Recovery: Why Small Businesses Need Both

The phrase I dread hearing most on a Monday morning is: "Don't worry, we've got backups." Not because backups are bad, but because the person saying it has usually confused having backups with being able to recover. They are not the same thing.

Most of the small businesses I take over from have some kind of backup running. Very few have a real disaster recovery plan. Here is the difference, why it matters, and how to tell which one you actually have.

A backup is a copy. A disaster recovery plan is a process

A backup is a second copy of your data sitting somewhere safe. That might be an external drive, a cloud service, or a proper enterprise backup appliance. Its job is to exist when you need it.

Disaster recovery is the process that turns that copy into a working business again. It covers how quickly you can be back up, what you'll be back up on, and who does what while the clock is ticking.

A cloud folder full of zipped files is a backup. It is not a disaster recovery plan.

The two numbers that matter: RPO and RTO

You don't need to love acronyms to run a small business, but these two save arguments:

RPO (Recovery Point Objective): how much data you can afford to lose. If your backup runs nightly, your RPO is up to 24 hours; a crash at 4pm loses everything typed that day.
RTO (Recovery Time Objective): how long you can afford to be down. If your RTO is two hours, a four-hour outage has failed the plan, regardless of whether the data came back eventually.

Decide these numbers before you buy anything. They change what backup and recovery setup actually makes sense.

Why "we've got backups" often isn't enough

The three things I find most often when I start with a new client:

The backup runs but has never been restored. A backup you haven't tested is not a backup; it is an assumption.
The backup lives on the same server it's backing up. A ransomware attack or a dead machine takes both at once.
No one has thought about the hardware. You can restore all the data in the world but if your server is dead and there's a three-week lead time for the replacement, you are not back up.

A genuine disaster recovery plan answers the question: "Our office burns down tonight, what happens tomorrow?" If the answer involves someone shrugging, there isn't a plan.

What a sensible setup looks like for a small business

For most Kent small businesses I work with, the practical answer is not complicated:

Microsoft 365 for email and files, with a third-party backup product on top (Microsoft's native retention is not a backup).
Line-of-business software in the cloud where possible, so the vendor handles the infrastructure.
One local backup and one off-site/cloud backup for anything still on a server.
A written one-page plan listing: who to call, what to log into, which cloud tenant holds what, which laptop can be used in an emergency.
An annual test where you pretend the office is gone and see how far you actually get.

The ransomware test

When I audit a client's setup, the simplest check is this: if ransomware encrypted everything on your network tonight, including your backup drive that's plugged in, could you recover? If the answer requires "yes, because the backup is offline, or in another tenant, or immutable", you're probably fine. If the answer involves "our IT company has something, I think", you have work to do.

The bit most people forget: people and process

Your disaster recovery plan should include the non-IT bits too. Whose phone gets the alert at 3am? Who tells the team to stay home? Who updates the client who was due on site? Who approves the spend on an emergency replacement laptop?

Answer those now, in daylight, on paper. It is much harder to answer them at 7am on a Tuesday with half the network dark.

The short version

If you only take one thing from this: have backups, but know your recovery plan too. If you're not sure which of the two you have, you probably have backups and an assumption, and you want the other thing.

If you'd like me to look at your current setup and tell you honestly how long it would take to recover from a real incident, get in touch. An hour of my time now is far cheaper than a weekend of cleanup.

Blog