On the morning of April 14, 1912, the crew of the RMS Titanic was scheduled to run a lifeboat drill. It never happened. Captain Edward Smith cancelled it, the official reason has been argued about for a century, and the crew went on with their Sunday. That night, at 11:40 PM, the ship struck an iceberg, and the people on board discovered what happens when you carry safety equipment you've never practiced with. Lifeboats were launched half-empty. Some were never launched at all. People who could have been saved weren't, not because the boats weren't there, but because nobody had ever rehearsed getting into them.
The Titanic's lifeboats were famously insufficient, 20 of them, for 2,224 souls aboard. That part of the story gets most of the ink. The quieter part is that even the boats that did exist were used badly, and that's the part that maps onto a modern business.
Every company I've walked into has backups. Every one. It's the easiest box to check on an audit. The server has a nightly snapshot. The cloud has object versioning turned on. The laptops sync to OneDrive. Somewhere, in theory, a copy of everything important exists.
Almost none of those companies have ever restored from them.
That's the gap. Not the absence of backups, the absence of proof. The first time we run a real recovery test on a new client, we find things. The backup job has been failing silently for months because someone rotated an API key. The restore completes, but it's pointing at the wrong database and the application can't find it. The snapshot is 24 hours old, not the 15-minute RPO the contract claims. The tape backup restores, but nobody can find the drive that reads it. The cloud account the backups live in is owned by an employee who left in 2023.
None of these are hypothetical. They're the things a drill reveals in the first hour, and that a real incident doesn't give you the luxury to notice.
I learned this the expensive way. Early in my career I set up the backup system at a growing company, and I was proud of it, offsite replication, encrypted volumes, every checkbox the CTO asked about. Then a developer dropped a production table, and we had to prove it worked for real. The restore ran. The data came back. The application fell over, because a schema migration had changed two weeks earlier and we'd never tested a restore against the new code. The data was fine. The system was down for six hours while we figured out what a drill would have told us in ten minutes.
That's when the lesson clicked: a backup isn't a capability. A tested restore is a capability. The gap between the two is where careers end and companies fold.
A fire extinguisher, or a fire drill?
Disaster recovery is often sold like a fire extinguisher. Buy it, hang it on the wall, leave it alone, trust it when you need it. That framing is why so much of it fails under load, a fire extinguisher only has to sit there, and mostly it works. A fire drill is different. It's a practiced routine, with known roles, a timed sequence, and measurable outcomes. You don't prove a fire drill by pointing at it. You prove it by running it.
The modern version for a business is a recovery test: simulate the failure, run the actual restore procedure against the actual data, measure how long it takes, and verify the restored system is usable. Once a quarter is the bar. Once a year is the floor. Never is what most companies do.
There's a second reason to run the drill, and it's the one most IT contracts gloss over. Until you've done a real recovery, you don't actually know what an outage will cost you. The sales deck promises a 15-minute RPO and a one-hour RTO. The drill tells you whether those numbers survive contact with your stack. Most of the time, they don't, and the mismatch between what you're paying for and what you'll actually get is the most expensive thing you can learn during an incident.
How Lanovix handles this
Every managed IT engagement we take on includes a scheduled recovery test, not a spreadsheet confirming backups ran, but an actual restore of actual data to a working environment. The first one we run on a new client almost always surfaces something that would have bitten them in an emergency. The backup was out of sync with the schema. The restore account lacked permissions. The documented procedure referenced a tool that had been decommissioned. We fix those things in a planned, calm window, instead of at 2 AM during an incident.
We also measure what a real recovery costs you, in minutes, in revenue, in customer-facing impact, and align it against the backup schedule you're paying for. There's no point paying for a 15-minute RPO if your tested recovery time is four hours. Most companies are either over-insured on one end or under-insured on the other. Finding that out during a drill is free. Finding it out during an outage is not.
At Lanovix, we build disaster recovery plans for every client, software and hardware alike, so that when a crisis hits, no one is guessing. But a plan that sits on a shelf is the same as no plan at all. We exercise ours on a schedule, with a team, so that multiple people on both sides know their role before they need it. The drill and the real event are run by hands that have already done it before.
The Titanic had lifeboats. It didn't have a drill. Your backups are the boats. The drill is what decides whether anyone gets off the ship.
If you haven't tested your restores in the last 90 days, you don't have a disaster recovery plan. You have optimism. Get in touch and we'll help you run the drill while the water is still calm.