When was your backup last restored, not just run?
A backup report that says success proves the job ran, not that your data comes back. Disaster recovery testing is the only proof, and it has to be timed. Sophos found just 46 percent of victims with intact backups fully recovered inside a week. Ask for a dated restore log.
- A backup job and a restore are separate events that fail independently. The job can finish green while writing an image that will not boot.
- The only useful test result is a measured duration set against your recovery time objective. A restore that succeeds after 40 hours still closes the shop.
- Evidence is a dated restore log naming the systems recovered, the copy used, the time each step took, and the failures found. A green dashboard is not evidence.
- CISA puts the floor at no less than once per year, and New York's financial regulator made annual restore testing a legal requirement.
- Sophos measured median recovery costs of 3 million dollars where backups were compromised, against 375,000 dollars where they held.
When was your backup last restored, not just run?
To find out whether your backups work, ask for the date of the last restore test, the list of what it recovered, and how many hours it took. A nightly report that says success only proves the job ran. Proving the data comes back is a separate event, and the two fail independently.
Ransomware turned this into the question that decides whether a bad week is survivable. Verizon found that 48 percent of all breaches now involve ransomware. Sophos surveyed victims and found that 94 percent said attackers tried to compromise their backups, and that 57 percent of those attempts succeeded. Your backup copy is not a bystander during an attack. It is the target.
This guide covers disaster recovery testing from the buyer's side. It gives you the evidence to ask for, the one number almost no restore test records, and six questions you can send your provider on Tuesday. Read it beside Backup and Disaster Recovery: A Complete Guide for the concepts, Business Continuity vs Disaster Recovery for the planning split, and Does Microsoft 365 back up your data? if your files live in Microsoft 365.
A backup job and a restore are two different events
A backup job and a restore are different events because the job only writes data out, while the restore reads it back and rebuilds something you can use. The job backs up data. The restore brings a working business back. A job finishes green and still leaves you with nothing that runs.
Four failure modes produce a successful job and a failed recovery. They are listed below.
- Writes an image that no longer boots, so the file copy is perfect and the server is unusable.
- Captures a database mid-transaction, so the file restores and the application refuses to open it.
- Skips the one file share holding your contracts, because somebody changed a permission six months ago.
- Saves to a volume the attacker can reach, so the copy encrypts alongside the original.
CISA treats corruption as the normal case rather than the rare one. Its performance goals tell organizations to check restoration assets for indicators of compromise, file corruption, and other integrity issues before use. That instruction only makes sense once you accept the copy may be bad.
Confidence is not capability, and the gap is measured. Veeam surveyed more than 900 IT, security and risk leaders and found 90 percent were confident they could recover from a cyber incident, while only 28 percent of ransomware victims fully recovered all their affected data. On average victims got 72 percent of their data back, and 44 percent recovered less than three quarters of it. Nobody in that confident 90 percent believed their backups were broken. Their dashboards said success too.
The number that matters is how long the restore took
The number that matters is duration, because a restore that technically succeeds after 40 hours fails a business that assumed it would be trading the next morning. Outcome and time are two separate results, and most restore tests measure only the first.
A report that says restored successfully tells you the data exists somewhere. It does not tell you whether you open the doors on Monday. The only useful result is a measured duration set against the recovery time objective the business actually needs. Recovery time objective is how long you can be down. Recovery point objective is how much data you can afford to lose. Both are yardsticks for the test, and neither is the test.
Duration is where real recoveries break. Sophos found 53 percent of ransomware victims fully recovered within a week, up from 35 percent the year before, which means that even in the better year nearly half needed longer than seven days. Where attackers reached the backups, only 26 percent fully recovered inside a week, against 46 percent whose backups stayed intact. Intact backups roughly doubled the odds, and still left more than half of those businesses past the week.
Veeam found the same mismatch at the planning level. 90 percent said they were confident of recovering inside their recovery time objectives, while only 69 percent said those objectives were fully aligned with their business continuity goals. A target nobody mapped to the business is not a target. It is a number in a document.
Ask for the duration in three parts, because a single average hides the part that hurts.
- Time to first file back, which tells you how fast one deleted folder returns.
- Time to a working system, which includes the bare-metal restore of the operating system and the application, not only the data.
- Time to the business trading, which adds the failover of email, phones and line-of-business apps in the right order.
A provider who can tell you the date and the duration of your last restore is operating the control. A provider who names the backup product is only selling it.
What counts as evidence, and what does not
Evidence is a dated restore log naming what was recovered, which copy it came from, how long each step took, and who watched it happen. A green dashboard is not evidence, because it reports on the job rather than on the recovery. Evidence also has to be verifiable by somebody outside the provider who produced it.
Eight fields make a restore log worth keeping. The list below is what to ask for.
- Date of the test and the name of the engineer who ran it.
- Systems restored, named one by one, with the data volume in gigabytes.
- Source copy used, including whether it was the local, offsite or immutable copy.
- Start and finish times per system, which produce a measured duration.
- Target recovery time objective for each system, printed beside the measured time.
- Verification step that proves the data was usable, such as opening a record or running a report.
- Failures found during the test, each with the ticket number that fixed it.
- Signature of a witness from your side of the business, not only theirs.
Backup verification sits one level below that and is not a substitute. Verification checks that the backup file is readable and matches its checksum. A verified file still fails to boot, and a verified database still refuses to mount. Ask your provider to verify the restored data in front of you instead.
A restore log pairs with a runbook, which documents who does what, in which order, with which credentials. The runbook is what makes a good test repeatable by somebody other than the one engineer who knows the environment. Ask which systems it covers and when a person last rehearsed it.
Order of recovery matters more than raw speed for most firms, and a business impact analysis is what sets it. FEMA's guidance says the analysis should prioritize the order of events for restoring business functions and identify the operational and financial impacts resulting from the disruption of business. Skip it, and a provider restores whatever is quickest first.
The standards already set the floor at once a year
Annual restore testing is the published floor, not a premium extra. CISA's Cybersecurity Performance Goals tell organizations to test backups and recovery on a recurring basis, no less than once per year, to securely store backups offsite and offline, and to regularly test backup information to verify media reliability and information integrity.
New York's financial regulator went further and wrote it into law. Covered firms must periodically, and at a minimum annually, test their ability to restore critical data and information systems from backups, and must maintain backups adequately protected from unauthorized alterations or destruction. A managed service provider can hardly call the restore test optional once a regulator has made it a rule.
CISA and MS-ISAC make the ransomware case directly. The StopRansomware Guide says to maintain offline, encrypted backups of critical data and to regularly test the availability and integrity of backups in a disaster recovery scenario. Offline matters because many ransomware variants attempt to find and subsequently delete or encrypt accessible backups.
Three design choices make the copy survivable, and your provider should tell you which ones you have.
- 3-2-1 rule, meaning three copies of the data, on two types of media, with one copy held offsite.
- Immutable backup, meaning a copy nothing can alter or delete for a set retention window, even with administrator credentials.
- Air gap, meaning a copy with no live network path from the production environment. Isolate at least one copy this way.
Each of those protects the copy. None of them proves the recovery. You still have to run the test and time it.
Your insurer asks before your provider volunteers
Your cyber insurance underwriter asks for restore evidence because tested backups change the size of the claim. Marsh, the largest insurance broker in the world, lists secured, encrypted and tested backups among twelve key controls and states that the adoption of certain controls has now become a minimum requirement of insurers, with potential insurability on the line.
The cost asymmetry explains the interest. Sophos compared victims whose backups were compromised with those whose backups held. Median recovery cost was 3 million dollars where backups were compromised, against 375,000 dollars where they were intact, roughly eight times more. 85 percent of the compromised-backup group had data encrypted, against 52 percent of the others. And 67 percent of them paid the ransom, against 36 percent whose backups survived.
Read that last pair of numbers again. A business with a proven restore has a choice. A business without one is negotiating with a criminal while the phones ring.
Five restore tests, ranked by what each one proves
Five restore tests exist, and each proves more than the last. Run the cheap ones monthly, and treat the final two as the annual exercise that answers the question your business actually asked.
- File-level restore. Recovers a named file or folder. Proves the copy is readable. Takes minutes, and proves nothing about a server.
- Full system restore to isolated hardware. Rebuilds an entire server, which is the bare-metal restore. Proves the image boots and the application starts. This is the first test that yields a duration worth recording.
- Application verification restore. Restores the database, then opens a real record and runs a real report, which verifies the data is usable rather than merely present.
- Failover test. Switches live users onto the standby environment for an hour. Proves people can work, and exposes the dependencies nobody documented, such as DNS, licensing and phone routing.
- Full runbook rehearsal. Walks the whole documented sequence with the real staff, timed, against the agreed recovery time objective. Proves the business recovers, not just the server.
Most providers skip the rehearsal, because it needs scheduled downtime and a named owner. Price that reluctance against the alternative. Sophos puts the average cost of ransomware recovery at 1.7 million dollars, against a median ransom payment of 769,000 dollars. A planned Saturday of downtime is cheaper than either number.
That survey covered 2,158 organizations of 100 to 5,000 employees across 17 countries, and found 56 percent of attacks ended with data encrypted. That is the population a mid-sized firm sits in, so the base rate is not comfortable.
Six questions to send your provider on Tuesday
Six questions separate a provider who tests restores from one who only watches backup jobs. Send them in one email, keep the reply, and schedule the next test in writing.
- What is the date of our last restore test, and what did it restore? Good names a date inside the last twelve months and the systems involved. Weak describes the backup software.
- How long did that restore take, measured end to end? Good gives hours and minutes per system. Weak says it completed successfully.
- Which recovery time objective are we measured against, and who agreed it? Good names a number per system and the person who signed it. Weak says as fast as possible.
- Which copy did you restore from, and is any copy immutable or air-gapped? Good names the copy and its retention window. Weak says it is all in the cloud.
- What failed during the test, and which ticket fixed it? Good admits two or three failures, because real tests surface them. A flawless result usually means nothing hard was tested.
- Can we witness the next full restore test? Good puts a date in the calendar. Weak explains why that is not practical.
Question five is the tell. A restore test that found no problems at all almost always means somebody ran a file-level restore and wrote test in the log.
Best IT MSP is an independent directory. We rank providers on verified rating and firmographic data across 24,491 roster rows in 730 city datasets, we label paid placement, and we do not sell IT services, so we have no restore test to sell you. Compare the answers from three merit-ranked firms in your city and the differences show up fast.
What a tested restore does not buy you
A tested restore does not make you safe, and no honest provider claims it does. It converts an unknown into a measurable number, which is the only part of this you can manage, budget for and improve.
Sophos found that 97 percent of organizations whose data was encrypted did eventually recover it, at an average recovery cost of 1.53 million dollars that year. Eventually is the word carrying the weight. The gap between a bad fortnight and a closed business is almost never whether the data still existed. It is how many hours passed before people could work again, and that is the figure your restore log either holds or does not.
Start with the date. If nobody can name the day your data last came back, you do not have a backup position. You have a backup product. For the underlying concepts read our Backup and Disaster Recovery: A Complete Guide, and for the service itself see backup and disaster recovery.
FAQ
How often should backups be restore tested?
At least once a year, with smaller tests monthly. CISA's performance goals say to test backups and recovery on a recurring basis, no less than once per year. New York's financial regulator requires covered firms to test their ability to restore critical data and information systems from backups at a minimum annually.
What is the difference between backup testing and disaster recovery testing?
Backup testing checks that a copy can be read and restored. Disaster recovery testing times the whole sequence, including the bare-metal restore, the failover and the runbook, against your recovery time objective. One proves the data exists. The other proves the business can trade again.
What evidence should my IT provider give me that backups work?
A dated restore log naming the systems restored, the copy restored from, the measured duration per system, the target recovery time objective, the verification step and the failures found. A backup success report is not evidence. Sophos found 94 percent of ransomware victims had attackers attempt to compromise their backups.
How long should a full restore take?
Short enough to beat the recovery time objective your business agreed, which is a number you set rather than inherit. Measure it instead of estimating it. Sophos found 53 percent of ransomware victims fully recovered within a week, up from 35 percent the year before, so a week is common and rarely acceptable.
Does cyber insurance require tested backups?
Most underwriters ask for them. Marsh lists secured, encrypted and tested backups among twelve key controls and says adoption of certain controls has become a minimum requirement of insurers. Tested backups also cut the bill, since Sophos measured a median recovery cost of 3 million dollars where backups were compromised.
Best IT MSP is the independent directory of vetted managed IT and cybersecurity providers across North America. Organic ranking is earned on rating and verified data, and paid placement is always labelled. Take these six questions to three merit-ranked firms in your city and compare the answers side by side.