Do Your Backups Actually Work? Six Ways They Fail

Ask a business owner whether they have backups and the answer is almost always yes. Ask when someone last restored something from them, and the room goes quiet.

That gap is where the trouble lives. A job that runs every night and a business that can be operating again by Thursday are two different claims, and the first one does not automatically produce the second. Nearly every backup failure we find was not caused by a missing backup. It was caused by a backup nobody had ever asked to prove itself.

Key takeaways:

• “The backup ran” and “we can get the business back” are separate claims, and only a restore test proves the second one.
• A backup drive that stays plugged in gets encrypted along with everything else. At least one copy has to sit somewhere an attacker cannot reach from your network.
• Microsoft keeps your email available, but it does not keep a point-in-time backup you can roll back to. Its own documentation says so plainly.
• Decide two numbers before you buy anything: how many hours of work you can afford to lose, and how long you can afford to be down.

Six ways a backup fails quietly

None of these announce themselves. That is the whole problem.

Nobody reads the report. The nightly email lands in a folder, or in the inbox of someone who left. The job has been failing since a Windows update in March, and the first to notice is whoever needs a file back in November.

A sync folder is not a backup. OneDrive, Dropbox, and Google Drive are excellent at making the same files appear everywhere, which is exactly the problem. Delete a folder, or let ransomware encrypt it, and the service does its job perfectly: it syncs the damage to every copy within seconds. Versioning helps and is worth turning on, but it is a safety net with a time limit, not an archive.

The drive that never leaves. A USB drive plugged into the server is a backup right up until the moment it matters. Ransomware encrypts every drive letter it can see, and yours is one of them. The FTC’s small business guidance is blunt about the fix: regularly save important files to a drive or server that is not connected to your network.

It covers the file server and nothing else. The file share gets backed up because that is what backups meant in 2010. Meanwhile the accounting database is open and locked when the job runs, so it is skipped, and the mailboxes were never in scope at all.

The restore works, but takes nine days. This one passes every test except the real one. If the only copy lives in a cloud account and a whole server has to come back down a business internet connection, the arithmetic can run into weeks. Nobody discovers that until the week they cannot afford it.

The backup shares credentials with everything else. An attacker who reaches administrator access does not start by encrypting files. They start by deleting backups, because that is what turns an incident into a payment. If the login that runs your network can also delete your backup history, you have one control, not two.

Your cloud apps are not backing themselves up

This one surprises people, so it is worth quoting the vendor rather than paraphrasing. On its own documentation for Exchange Online, Microsoft states that “Exchange Online does not provide a way to perform a traditional backup of mailboxes”, and that there is no way to restore a mailbox to the state it was in when a backup was taken. Point-in-time restoration of mailbox items is described as out of scope for the service.

That is not a knock on Microsoft. Their job is keeping the service running and your data available, and they are good at it. Deleted items stay recoverable for a while and retention policies can hold more, but none of that is the same as saying “put this mailbox back the way it looked on the 4th”. If that matters, it is something you add.

Two numbers that make this decidable

Backup conversations go in circles because nobody has agreed what the target is. Two questions settle it, and neither requires technical knowledge to answer.

How much work can you afford to lose? Measured in hours since the last good copy. If your team does a day of data entry and the answer is “not a day”, you need copies more often than nightly. In the trade this is the recovery point objective (RPO).

How long can you afford to be down? From the moment something breaks to the moment people are working again. That one is the recovery time objective (RTO). Owners usually guess low here until they price it out, which is what our downtime cost calculator is for: put in your own numbers and the total tends to reframe the budget conversation quickly.

Answer those two and most of the technical decisions make themselves. Skip them and you buy whatever was quoted.

The 3-2-1 rule, and the part everyone drops

The convention worth knowing is 3-2-1: three copies of your data, on two different kinds of storage, with one of them offsite.

Most businesses get to two. The copy that gets dropped is the one that matters most, because the point of the third is that it survives whatever happened to the other two: the fire, the flood, the encryption that spread across every mapped drive on a Tuesday night. Offsite has to mean genuinely out of reach, not a second drive in the same cupboard.

Two details separate a real third copy from a comforting one. It should be offline, or held in storage that cannot be altered once written. And it should use different credentials from the rest of your network, so that getting into your systems is not the same as getting into your backup history.

How to test a restore without turning it into a project

The test is smaller than people expect, and skipping it is why the failures above stay invisible.

Once a quarter, pick something real and put it back. Not a test file created for the purpose: an actual document from a month ago, a mailbox item, a record from the line-of-business system. Then check three things. Did it come back? Did it open, with the right contents? And how long did it take, on a clock rather than estimated?

Write down the date, what you restored, and the elapsed time. That log is the only honest evidence your backups work, and it is the first thing a compliance assessment or an insurance renewal asks you to produce. Once a year, go bigger: restore a full server to a spare machine and time that too. Better to learn an uncomfortable number in a quiet week.

Where this usually lands

Plenty of this is doable in-house, and if this post sends you to check tonight’s job, that is a good outcome on its own. Harder to sustain is the part that never finishes. Backups drift as systems change, new applications arrive without anyone adding them to the job, and the quarterly test is first to fall off a busy calendar. That continuity is most of what our backup and disaster recovery service actually is: monitored jobs, offsite copies out of reach, and restores tested on a schedule rather than when something is on fire. It sits alongside the rest of managed IT because a backup is only as current as the systems inventory behind it.

If you want an outside read on whether yours would hold, we do it as part of a free assessment: what is covered, what is not, how long a real recovery would take, and what we would change first. Or email hello@cohesivesecurity.com and ask.