Your Backups Are Fine Until You Need Them

Almost every business we talk to has backups. Ask whether they work, and the answer is usually a confident yes. Ask when someone last restored something from them, and the room gets quieter.

That gap is the whole subject. A backup is not a copy of your data. A backup is a promise that your data can come back, and a promise nobody has ever tested is not worth much on the day you need to collect on it.

Why a green checkmark is not proof

Backup software is good at telling you it ran. Dashboards fill with green, reports arrive nightly, and everything looks handled. The trouble is that "the job completed" and "your business can be restored" are different claims, and only the first one is being measured.

Here is how backups actually fail, drawn from what we find when we take over an environment:

The job has been failing for months and nobody read the email. Failure notices go to an address nobody watches, or they land in a folder rule someone made years ago. The silence gets mistaken for good news.

The backup ran out of room. Storage fills, retention quietly shortens, and the copy you assumed goes back six months goes back nine days.

Something new was never added. You added a server, moved to a new line of business application, or someone set up a shared folder on a different machine. The backup kept faithfully protecting everything it was told about two years ago and nothing since.

The agent stopped reporting after a rebuild. A machine got replaced or reimaged, the backup software never went back on, and the dashboard shows the remaining machines succeeding.

Open files were skipped. Databases and practice management systems that are in use during the backup window can be skipped or captured mid write. The job reports success, and the file that comes back is not usable.

Retention is shorter than the attacker's patience. This one catches sophisticated businesses. Intruders often sit inside a network for weeks before triggering ransomware. If your backups only go back two weeks, every copy you have may already contain the problem.

The backup lives where the ransomware can reach it. A drive plugged into the server, or a network share on the same domain, gets encrypted along with everything else. That is not a backup, it is a second victim.

None of these are exotic. They are ordinary drift, and every one of them is invisible until someone tries to restore.

What a real restore test looks like

The good news: proving your backups work is not complicated. It is just work that has to actually happen.

A meaningful test has four parts.

Restore something real. Not a text file someone made for the test. Pick a file that matters, from a system that matters, and pull it from the backup rather than from the live system.

Open it in the application it belongs to. This is the step people skip, and it is the step that catches the failures above. A database file that copies successfully but will not open is a very different outcome than a successful restore, and you only learn the difference by opening it.

Time it. Note how long the restore took, and think about what that means at scale. If a single folder took twenty minutes, a full server is not a lunch break.

Restore a whole system, not just files, at least once a year. File recovery and business recovery are different problems. Bringing an entire server back, ideally onto different hardware or into the cloud, is the only way to know whether you could actually reopen after a hardware failure or an encryption event.

Write down the date and the result each time. That record is worth more than any dashboard, and it happens to be exactly what a cyber insurance questionnaire or a compliance review will ask you for.

The number almost nobody knows

Here is a question worth sitting with: if your main server died this morning, how many hours until your team is working again?

Most owners cannot answer, and the reason is that "we have backups" feels like an answer until you trace it through. Where does the restored system run if the hardware is gone? Who has the credentials? How much data has to move, and over what internet connection? Is anyone available to do it on a Saturday?

Businesses with good backups still lose a week when nobody worked that sequence out in advance. Backups are one ingredient. The plan for using them under pressure is the rest of the recipe, and the two get confused constantly. We wrote about the difference in more detail on our questions site: we have backups, is that our disaster recovery plan?

What to ask, and what a good answer sounds like

If someone else manages your IT, two questions tell you nearly everything:

"When did a backup job for us last fail, and how did you find out?" A good answer is specific and slightly boring: a date, what failed, and how it was noticed and fixed. An answer of "they don't really fail" means nobody is watching.

"When did you last restore our data, and how long did it take?" A dated answer with a number is what good looks like. A confident but vague answer means the test has not happened.

Neither question is a trap. They are the questions we would want a client to ask us, because they are the ones that separate a monitored backup from a hopeful one.

How we approach it

For the businesses we manage, backups run on a frequent schedule rather than once nightly, so the amount of work at risk stays small. Copies live off site, out of reach of anything happening on your local network, and jobs are monitored so failures reach a person instead of an inbox nobody checks. Test restores are part of the service rather than a favor, and we would rather find a broken backup on a quiet Wednesday than on the worst morning of your year.

We cannot promise that nothing will ever go wrong, and we would not trust anyone who did. What we can do is make sure that when it does, the recovery is a procedure instead of an improvisation.

Final thoughts

Backups are one of those areas where confidence and reality drift apart slowly and silently. Nothing announces the drift. The dashboard stays green, the years go by, and the discovery happens at the worst possible time.

You can close that gap this month, and it starts with one small act: restore something and open it.

If you are not sure when your backups were last tested, or whether they would bring your business back rather than just your files, we are glad to take a look and tell you honestly what we find. Asheville Computer Company manages backup and recovery for businesses across Asheville, Arden, Fletcher, Hendersonville, and Western North Carolina, and the testing is the part we care most about.