The Backup You Have Never Tested Is Not a Backup

Every business we assess has backups. Almost none of them have tested a restore.

That gap is where the damage happens. A backup job that runs nightly and reports success has told you one thing: that a job ran. It has not told you that the data is complete, that it is readable, that it includes the systems you actually need, or that you can get it back inside a timeframe your business can survive.

The first time most companies find out is the day they need it.

What "We Have Backups" Usually Means in Practice

When we open the backup configuration at a small office, the findings are remarkably consistent:

• The job has been failing for months. Notifications went to an employee who left, or to a folder rule nobody checks. The last successful run predates the current fiscal year.
• It backs up the file server and nothing else. Not the accounting database, not the line-of-business application, not the local mail archive, not the workstation where one person keeps the only copy of something important.
• Everything lives in one building. The backup drive sits on a shelf beside the server it is protecting. A fire, a flood, or a theft takes both.
• It is a sync, not a backup. A folder synchronized to cloud storage is not a backup. When a file is corrupted or encrypted, the sync faithfully copies the damage to every other location, usually within minutes.
• Nobody knows how long a restore takes. Not approximately. At all.

None of these are exotic failures. They are the normal condition of a system that was configured once and never revisited.

The 3-2-1 Rule, and Why It Still Holds

The working standard is straightforward: three copies of your data, on two different types of media, with one copy off-site.

• Three copies. The live production data plus two backups. Two copies means one failure away from having none.
• Two media types. Different failure modes. A local disk and cloud storage, or disk and tape. If both copies are on identical hardware bought in the same batch, they can fail in the same way at the same time.
• One off-site. Geographically separate. This is the copy that survives the event affecting your building.

Many practitioners now add a fourth element: one copy that is immutable or offline, meaning it cannot be modified or deleted even by an administrator account. This addition exists entirely because of ransomware, and it matters more than any other single improvement on this list.

What Ransomware Changed

Older backup design assumed the threat was hardware failure, accidental deletion, or physical disaster. Those threats are indifferent to your backups. Ransomware is not.

Modern ransomware operators deliberately hunt backups before triggering encryption. They look for connected backup drives, network shares holding backup files, and backup software consoles reachable with the credentials they have already stolen. They delete or encrypt what they find, then encrypt production. The extortion works because recovery is genuinely impossible.

Attackers also dwell in networks for weeks before acting, which means your recent backups may already contain their tooling. Recovery planning therefore needs enough retention depth to reach a known-clean point, not just last night's copy.

The practical implications for a small business:

• At least one backup copy must be genuinely offline or immutable, not merely on a different server.
• Backup credentials must be separate from everyday administrator credentials, with multi-factor authentication.
• Retention needs enough history to restore from before an intrusion began, which typically means months rather than days.
• A backup drive permanently connected to the machine it protects is not off-site and is not safe.

Two Numbers Every Business Should Know

Backup conversations get clearer once you replace "we back up nightly" with two specific figures.

Recovery Point Objective: How Much Work You Can Afford to Lose

If backups run at 11pm and the server fails at 4pm the next day, you have lost seventeen hours of work. Everything entered that day is gone. Is that acceptable? For some businesses it genuinely is. For a practice entering billable time and client documents all day, it is not, and the backup schedule should reflect that.

Recovery Time Objective: How Long You Can Afford to Be Down

This is the number almost nobody has measured. Restoring several terabytes from cloud storage over a standard business internet connection can take days, not hours, and the constraint is bandwidth rather than anything you can fix on the day.

A business that can tolerate three days offline needs a very different design from one that cannot get through a single day. Both are legitimate positions. What is not legitimate is not knowing which one you are, and discovering it during the outage.

Testing: The Step That Converts Hope Into a Backup

A restore test does not need to be elaborate. It needs to happen on a schedule.

• Quarterly file-level restore. Pick a handful of real files from different systems and restore them to a temporary location. Confirm they open and the contents are correct. This catches silent corruption and incomplete job scope.
• Annual full-system restore. Recover an entire server to spare hardware or a virtual machine. Time it with a clock. That measured duration is your real recovery time objective, and it is frequently three to five times what people assumed.
• Documented recovery procedure. Written steps someone other than you can follow, stored somewhere that remains accessible when the network is down. A recovery plan saved only on the encrypted file server is not a plan.
• Verify the alerts work. Deliberately fail a job and confirm someone currently employed receives the notification.

An hour per quarter is the entire cost. Compared with the alternative, it is the cheapest insurance in your technology budget.

Backups Are Not the Whole Plan

Data recovery is one part of continuity. If your office loses power, internet, or physical access, restoring files does not put you back in business. A complete plan also covers where staff work, how clients reach you, which systems must come back first and in what order, and who makes decisions while the usual person is unreachable.

For most small businesses this document runs two or three pages. Its value is that the thinking happens on an ordinary afternoon rather than during the incident, when nobody thinks clearly.

A Reasonable Standard for a Small Office

Nothing here requires enterprise budgets. A defensible setup for a typical St. Charles County office looks like:

• Automated daily backup of every system holding business data, not just the file server
• A local copy for fast restores, plus an off-site copy for disasters
• One immutable or offline copy that ransomware cannot reach
• Retention measured in months, so you can reach a known-clean restore point
• Backup credentials separated from daily admin accounts, protected by multi-factor authentication
• Monitored alerts going to someone who still works there
• Quarterly file restores and one annual full restore, both documented
• A short written recovery plan stored somewhere reachable during an outage

Finding Out Where You Actually Stand

Most businesses discover their backup problem at the worst possible moment. It is entirely avoidable, and the assessment is not expensive or disruptive.

Archway Point provides on-premises IT support, backup design, and disaster recovery planning for businesses in St. Charles County and the greater St. Louis area. We document what you have, test whether a restore actually works, measure how long it takes, and give you the findings in writing whether or not you hire us for the follow-on work. If nobody at your company has restored from backup in the last twelve months, let us take a look.