Most data backup and recovery plans do not fail at the backup. They fail at the restore.

The backup job runs nightly for four years. The dashboard is green. Then a server dies, someone clicks restore, and the business discovers that the database file was copied while it was open and the copy is unusable — or that the restore takes eleven hours when the business assumed one, or that the one system nobody thought to include was the one holding customer records.

We have been building and supporting systems for U.S. businesses since 2003, including operations platforms for electric utility and recycling companies where a day of downtime is measured in trucks that do not roll. This is what we have learned about the difference between having backups and being able to recover.

Start with two numbers, not with software

Almost every business shops for backup software before deciding what it needs the software to do. Reverse that. Two numbers define your entire plan.

Recovery Point Objective (RPO) — how much data can you afford to lose? If you back up once nightly at 2 a.m. and the server fails at 4 p.m., you have lost fourteen hours of work. Is that survivable? For a company doing manual data entry, maybe. For one processing transactions all day, no.

Recovery Time Objective (RTO) — how long can you be down? Not how long the restore takes in the vendor’s brochure. How long from the moment of failure to the moment staff are working again, including the time to diagnose the problem, find the hardware, and rebuild the operating system.

Write both numbers down and get the business owner to agree to them, not the IT department. They are business decisions with a cost attached, and they determine everything else. A four-hour RTO and a fifteen-minute RPO is an achievable target. It is also a meaningfully more expensive design than nightly backups to a single external drive, and the person paying for it should be the one choosing.

The 3-2-1 rule, and what it became

The old standard was 3-2-1: three copies of your data, on two different types of media, with one copy offsite.

It is still a good foundation. But ransomware changed the threat, because modern attacks specifically target backups first. Attackers spend weeks inside a network, find the backup server, encrypt or delete the backups, and only then encrypt production. A perfectly executed 3-2-1 strategy is worthless if all three copies are reachable from a compromised domain admin account.

The updated version is 3-2-1-1-0: three copies, two media types, one offsite, one copy immutable or offline, and zero errors on verification.

The immutable copy is the part most businesses are missing. It means a backup that cannot be altered or deleted for a fixed retention window, even by an administrator, even by someone holding valid credentials. Object-lock cloud storage and write-once media both do this. Without one, your recovery plan assumes an attacker will politely leave your backups alone.

File backup is not database backup

This is where we see the most expensive mistakes, and it is worth being specific.

Copying a SQL Server .mdf file while the database is running does not produce a restorable database. The file is being written to as it is copied, so what lands in the backup is a torn, inconsistent snapshot. It will often appear to succeed. It will fail when you try to attach it, usually at the worst possible moment.

Databases need database-aware backups:

• Full backups capture the whole database at a point in time.
• Differential backups capture what changed since the last full, keeping nightly windows short.
• Transaction log backups are what make a tight RPO possible. Run them every fifteen minutes and you can restore to nearly any moment, rather than to last night.

Transaction log backups require the database to be in the full recovery model. Plenty of businesses run production databases in simple recovery, which quietly makes point-in-time restore impossible no matter what the backup software reports. If your operations depend on a database, that setting is worth checking today — and it is a core part of our Microsoft SQL Server database development work.

The same principle applies to Exchange, to line-of-business applications with their own data engines, and to virtual machines running any of the above.

What businesses forget to back up

The server is the easy part. In practice, the gaps are almost always here:

• SaaS data. Microsoft 365 and Google Workspace replicate your data for availability, not for recovery. If a user deletes a mailbox or a ransomware sync wipes a SharePoint library, the retention window is shorter than most businesses assume. Third-party SaaS backup is a separate product for a reason.
• Configuration, not just data. Firewall rules, switch configs, DNS records, certificates, application settings. Restoring the data onto a server nobody knows how to configure adds days to your RTO.
• Endpoints. Laptops holding the only copy of a proposal or a spreadsheet that runs part of the business.
• The recovery documentation itself. If the runbook lives on the file server that just died, you have a problem. Keep an offline copy.

Test the restore, or you do not have a plan

A backup you have never restored is a hypothesis.

Test quarterly at minimum, and test the thing you would actually do in a disaster — restore to different hardware, not back onto the working server. Time it, and compare that time to your stated RTO. If the restore takes eleven hours and your RTO is four, you do not have a backup problem, you have a design problem, and finding that out during a quarterly test costs nothing.

Verification matters as much as the restore. That is the zero in 3-2-1-1-0: every backup checked for integrity, not just reported as complete. Backup software that says “success” is telling you the job finished, not that the data is good.

Write down what you tested, when, how long it took, and what broke. If you carry cyber insurance or work under contracts with security requirements, that record is often what an auditor asks for — and it is the same discipline behind our managed service provider engagements.

Ransomware raised the stakes on recovery time

Federal guidance has grown considerably more direct on this. CISA’s StopRansomware guidance treats tested, isolated backups as a primary defense rather than an afterthought, because the ability to restore quickly is what removes an attacker’s leverage.

Two practical implications. First, keep backup infrastructure on separate credentials from your production domain — if one compromised account can reach both, you have one system, not two. Second, plan for the scenario where you cannot trust any running server. Recovering into clean infrastructure is a different exercise than restoring a failed disk, and it takes longer than most RTO estimates assume.

While you are reviewing this, check what operating systems your backup infrastructure runs on. An unsupported OS protecting your last line of defense is a common and avoidable weakness — see our guide to Windows Server 2012 R2 end of life for the current deadlines.

Where ITsoft fits

We design data backup and recovery for businesses whose operations do not tolerate downtime — including database-heavy environments where generic backup tools quietly fail. That means setting recovery targets with you, building to them, and proving through tested restores that the targets are real.

If you cannot say from memory how long a full recovery would take, that uncertainty is the finding.

Talk to Mike Treat about a backup and recovery review — we will document what is protected, what is not, and how long recovery would actually take. You keep the report whether or not you work with us.

Related reading: Windows Server setup and maintenance · managed service provider services · IT resources for small to medium-sized businesses