Ask most owners if their systems are backed up and you'll get a confident yes. Ask how long it would take to get the business running again after a bad day — a ransomware event, a corrupted database, a cloud region outage, a departing admin who took the only credentials with them — and the confidence disappears.
That gap is the whole problem. A backup is a receipt. Recovery is the service. Buying the first and assuming the second is how companies discover, in the worst possible week, that their safety net has holes they never looked for.
The two numbers that matter more than your backup vendor
Strip away the jargon and disaster recovery comes down to two questions a business owner can answer without a technical background.
How much work can we afford to lose? If your ERP backs up nightly and fails at 4 p.m., you've lost a day of orders, receipts, and inventory moves. Someone has to re-enter all of it from paper, email, and memory. That tolerance is your recovery point.
How long can we be down? Not "how long until the server is up" — how long until people can take orders, ship product, and invoice. A warehouse that can't print pick tickets is down even if the database is technically online. That tolerance is your recovery time.
Those two numbers are business decisions, not IT decisions. They drive architecture, cost, and how much redundancy is worth paying for. Most mid-market companies have never written them down, which means their infrastructure was designed against assumptions nobody stated out loud.
An untested backup is a hypothesis
Backup jobs report success for all kinds of reasons that have nothing to do with whether the data is usable. The job completed, but it skipped a locked file. The database dumped, but without the attachments stored on a separate volume. The snapshot ran nightly for a year on a server that was decommissioned eight months ago. The archive is encrypted and the key lives in a password manager that only one person can open.
None of that shows up in a green dashboard. It shows up during the restore, when the clock is running and everyone is watching.
The fix is unglamorous: actually restore something, on purpose, when nothing is wrong. Pick a system, spin up a clean environment, bring it back from the most recent backup, and have a real user log in and confirm the data looks right. Time the whole thing. That number — not the vendor's SLA — is your true recovery time.
What actually breaks in a real recovery
The data is usually the easy part. What delays recovery is everything wrapped around it:
- Credentials and access that live with one person or one personal account
- DNS, certificates, and domain settings nobody documented
- Integrations that need to be re-pointed, re-authorized, or replayed in the right order
- License keys and vendor approvals required to stand a system back up
- Dependency order — what has to come online before anything else works
Each of these is small on an ordinary Tuesday. Stacked together during an outage, they turn a two-hour restore into a two-day scramble.
Not every system deserves the same answer
Protecting everything at the highest level is expensive and usually unnecessary. Sort your systems into tiers and be honest about which is which.
The systems that stop revenue when they stop — ERP, order entry, payment processing, the website if it takes orders — get the shortest recovery targets and the most investment. The systems that cause friction but not stoppage can tolerate longer. The archive nobody has opened in two years needs to be retrievable, not instantly available.
This tiering conversation is also where fragility becomes visible. When a single aging server sits underneath three tier-one systems, you don't have a backup question anymore. You have an architecture question.
Write the runbook for the person who will be on call
Recovery knowledge that lives in one person's head is another single point of failure. The runbook doesn't need to be elegant. It needs to be specific enough that a competent person who wasn't part of building the system can follow it: where backups live, how to access them, what order to restore in, who to call at each vendor, how to verify success, and how to tell the team the business is back.
Then test it with someone other than the author. If they get stuck, the document is wrong — not the person.
Make it a rhythm, not a project
Systems drift. New integrations appear, servers get replaced, people leave. A recovery plan validated once is accurate for about a quarter. Put a restore test on the calendar the same way you'd schedule a financial close, and treat the result as a metric leadership sees.
If you don't know your real recovery time today, that's the place to start. Infraxio helps operators map their critical systems, set honest recovery targets, and build infrastructure that can actually come back. Reach out and we'll walk through what a real restore would look like in your environment.