Every Monday your backup system sends a green email. Job completed. Zero errors. Everybody feels good and nobody opens it. That email is not a promise you can get your business back. It is a receipt confirming data was copied somewhere.
On the worst day of your year, exactly one number matters: how long until people are working again. Hours or days. Most owners have never been told that number, because nobody measured it. Here is how to find yours before you need it.
Why Backup Reports Create False Confidence
A backup report is a receipt from a storage unit. It proves the boxes went in. It says nothing about whether the key still works, whether the road there is open, or how many hours it takes to carry everything back out and put it where it belongs.
Copying and recovering are different activities, and the standards bodies treat them that way. In its 2010 publication NIST SP 800-34 Revision 1, the National Institute of Standards and Technology puts it plainly: testing validates recovery capabilities, whereas training prepares recovery personnel for plan activation and exercising the plan identifies planning gaps. Copying data is not a recovery capability. In its #StopRansomware Guide, the Cybersecurity and Infrastructure Security Agency asks organizations to regularly test the availability and integrity of backups in a disaster recovery scenario, not simply to confirm the job ran.
Here is what a green checkmark does not tell you.
- Whether the data opens. A file can copy perfectly and still be corrupt inside. Databases are especially good at this.
- Whether anything is missing. New server added in March, never added to the backup job. The report is still green, because the job it ran succeeded.
- How long it takes to come back. The report measures the trip out. Nobody times the trip home.
- Whether anyone knows the steps. If the only person who understands the console is on a cruise, your recovery time includes the cruise.
What Actually Determines Restore Speed
Five things decide whether you are back in four hours or four days. None of them are on the backup report.
- Where the copy lives. A local appliance in your server closet restores at the speed of a network cable. A cloud-only copy restores at the speed of your internet connection, which is a different order of magnitude.
- How much data there is. Do the arithmetic once and it stops being abstract. A 100 megabit per second connection moves roughly 45 gigabytes per hour at theoretical full speed, so two terabytes is about 45 hours of perfect uninterrupted download. Nobody gets perfect.
- Your actual bandwidth, not the number on the bill. Many business connections are asymmetric, meaning download is fast and upload is slow. Check which direction your restore travels.
- The order systems come back in. Restore the line of business application before the server it authenticates against and you get to do it twice.
- Whether anyone has done it before. This is the biggest variable and the least discussed. A person who has restored this system once moves three times faster than a person reading documentation during a crisis.
There is a sixth factor people forget: how much has to be rebuilt rather than restored. Application installs, license keys, printer drivers, and vendor integrations often are not in the backup at all. That work happens after the data lands, and it is frequently the longest part of the day.
Time One Real Restore This Week
You do not need a full disaster drill. You need one honest measurement of one system that matters. Block ninety minutes and do this.
- Pick something meaningful. The file share with active client work, or the accounting database. Not a test folder somebody made for this purpose.
- Restore it somewhere isolated. A spare machine or a separate virtual machine. Never restore over the live copy, because a botched drill should not become a real outage.
- Start the timer when you decide, not when the transfer begins. Finding the console, locating credentials, and figuring out which restore point to use all count. In a real event they count double.
- Open the data and confirm it is right. Restored is not the same as working. Launch the application. Run a report. Have someone who uses it daily look at it.
- Write down the number and what slowed you. The bottleneck is the useful part. It is almost never the technology.
CISA’s small business guidance sets a similar bar, advising organizations to test the backup procedure to make sure the team can rapidly restore data both fully and partially, and to ensure they can roll back data at least seven days if needed. Both halves matter. Partial restores are what you actually do most of the time, and reaching back a full week is what saves you when the problem started before you noticed it.
Compare It to What the Business Can Tolerate
Now you have a real number. The next question is whether it is acceptable, and that is a business question, not a technical one.
NIST SP 800-34 Revision 1 gives you the two terms worth knowing. Recovery Time Objective, the 2010 publication says, defines the maximum amount of time that a system resource can remain unavailable before there is an unacceptable impact. Recovery Point Objective represents the point in time, prior to a disruption or system outage, to which data can be recovered given the most recent backup copy. In plain English: how long can we be down, and how much work are we willing to redo.
Ask each department lead one question. If this system vanished at nine on Tuesday morning, when does it start costing us real money? Answers will range from two hours to two weeks, and that range is the point. Your shipping system and your marketing archive do not deserve the same investment.
The gap between your measured restore time and your tolerable downtime is your actual risk. Everything else is decoration. If the measurement says three days and the business says four hours, you do not have a backup problem. You have a recovery design problem, and those are fixable once you can see them.
The Cheap Changes That Shorten It
Closing the gap usually costs less than people expect, because the expensive fixes are rarely the effective ones.
- Keep a local copy alongside the cloud copy. The cloud copy protects you against fire and ransomware. The local copy is what makes Tuesday fast. You want both, and relying on one cloud alone has its own failure modes.
- Write the runbook. One document: system order, where credentials live, vendor phone numbers, license keys. Free to make, enormous on the day.
- Decide the recovery order in advance. Arguing about priorities while everyone is standing around is how four hours becomes ten.
- Shrink what has to move. Archive data nobody has opened in five years. Less to restore is less time restoring.
- Store credentials somewhere reachable when the network is down. A password manager on a phone, not a spreadsheet on the file server that just got encrypted.
- Let someone else drive the next test. If recovery only works when one specific person is available, you have not solved the problem. You have hired it.
The Bottom Line
Backup completion is an input. Restore time is the outcome, and it is the only number that matters after a bad week. Measure it once and you will never look at a green checkmark the same way. Most businesses find their real restore time is longer than they assumed and easier to improve than they feared.
If nobody at your company can answer how long recovery takes, that is worth an afternoon. We will time a real restore with you, give you the honest number, and show you which cheap changes move it most. We do this for small and mid-sized businesses across Denton County every month, and it is a fair question to ask any provider you are evaluating as an IT partner. Contact us today.
Sources:
Comments are closed