She was certain the backups were running.

Her IT person had set them up two years ago. She'd seen the confirmation emails. She didn't read them closely — they said "backup complete" and that was enough.

When ransomware encrypted her server on a Thursday afternoon, her first thought was: at least we have the backups.

The restore attempt started at 4pm.

By 6pm, they knew the truth. The backup job had been silently failing for eleven months. The confirmation emails kept arriving because the job was scheduled — it just wasn't completing. Nobody had ever tried to restore from it. Nobody had ever verified that what it was capturing was actually recoverable.

The most recent clean backup was from the previous October.

She lost eleven months of data.

The problem isn't that she didn't have backups.

The problem is that she thought she did.

This is the most common version of a backup failure: not a backup that was never created, but a backup that was never verified. A job that ran, produced a log, sent a notification, and appeared — from every external indicator — to be working fine.

Until it wasn't needed.

What a real backup strategy looks like

There's a framework called the 3-2-1 rule. It's been the industry standard for over a decade and it's still the right starting point:

  • 3 copies of your data
  • 2 different storage media types (e.g. local + cloud)
  • 1 copy offsite

For a small business, this looks like: a local backup (NAS device or external drive attached to the server), plus a cloud backup to a service like Azure Backup or Backblaze. Your local backup is fast to restore from. Your cloud backup is there when the local one burns, floods, gets stolen, or gets encrypted alongside your primary data.

What the 3-2-1 rule doesn't tell you: none of it matters if you've never tested a restore.

The difference between a backup running and a backup working

A backup that runs writes data somewhere. A backup that works can be fully restored from, within your acceptable recovery window, without data corruption.

Those are different things.

Testing a backup means:

  • Picking a random date and attempting to restore from it
  • Verifying the restored data is intact and complete
  • Confirming the restore time falls within what your business can tolerate

For most small businesses, this test should happen at minimum quarterly, and after any significant change to the environment (new server, new software, migration to cloud).

The result of the test should be documented. If you can't produce a restore log when your insurer asks for one, the test didn't happen.

What "backup" does not mean

OneDrive and SharePoint are not backups. They are sync tools. If someone — or ransomware — deletes or overwrites a file, the change propagates immediately. Version history helps, but it has retention limits and it isn't a substitute for a true backup.

Microsoft 365 email retention is not a backup. It's a compliance tool. The retention window is configurable and may not match what you actually need to recover from.

"The server has RAID" is not a backup. RAID protects against disk failure. It does not protect against ransomware, accidental deletion, software corruption, or anything that writes bad data across all disks simultaneously.

What to ask your IT provider

  • What are we actually backing up, and what's excluded?
  • Where does the backup go — local, cloud, or both?
  • How long are backups retained?
  • When was the last restore test, and can I see the documentation?
  • What's our recovery time objective (RTO) — how long to get back online from a full failure?

If your IT provider can't answer those questions clearly, you don't have a backup strategy. You have a backup job.

The bottom line

A backup is only as good as your last successful restore test.

If you've never tested it, you don't know what you have.