Your backup isn’t real until you’ve restored it — what downtime and lost data actually cost, and why recovery is a systems decision

Every business owner believes they are covered. The hosting has backups, the laptop syncs to the cloud, the accountant keeps a copy — and so the question of "what happens if it all disappears tomorrow" gets filed under solved and never looked at again. It stays solved right up until the day a server dies, a database gets corrupted, an employee deletes the wrong thing, or ransomware locks every file you own. That is the day you discover the difference between having a backup and having a recovery — and for a frightening number of businesses, that day is the last one they trade.

The gap is not laziness. It is a category error. "Do we have backups?" feels like a yes/no IT question, so it gets answered once and forgotten. But a backup is not a thing you have; it is a thing you do — and the only proof it works is a restore you have actually performed. A copy you have never tried to bring back is a hypothesis. Most of the businesses that fail after a data-loss event did have backups. The backups were old, or partial, or silently broken, or sitting on the same system that just got encrypted, or simply never tested. The copy existed. The recovery did not.

This piece is about reframing continuity from an afterthought — a checkbox someone ticked when the system was built — into a deliberate design decision with two numbers attached. How much data can you afford to lose if everything goes down right now? How long can you be offline before the loss becomes existential? Answer those two honestly and the whole problem changes shape: it stops being "do we have backups" and becomes "is the business built to survive its own worst day." That is not something you buy. It is something you build in.

Start with what downtime costs, because the number is larger and more immediate than most owners think. Splunk and Cisco’s study of the world’s largest companies put the aggregate cost of unplanned downtime at around six hundred billion dollars a year — a fifty percent jump in two years — working out to roughly fifteen thousand dollars a minute on average, and about ninety-five million dollars in lost revenue per organisation annually ^[1]. Those are enterprise figures and your business is not the Global 2000 — but the proportion does not shrink when you do. A small operation that takes orders, books appointments, or runs a till has the same problem at its own scale: when the system is down, the business is not earning, staff are paid to wait, customers go elsewhere, and the clock does not stop because you are small.

Downtime is the recoverable disaster. Data loss is the one that ends companies. The numbers here are stark and they have held steady for years: roughly one in four businesses never reopen after a major disaster, and of small businesses that suffer significant data loss, about sixty percent close within six months and seventy-two percent are gone inside two years ^[2]. A security breach is theft — someone takes a copy of what you have. Data loss is amnesia — the business forgets who owes it money, what it ordered, what it promised, who its customers are. You can survive being robbed. It is much harder to survive waking up with no memory of how to run yourself.

So the obvious defence is backups — and here is where the comfortable assumption falls apart. Having a backup and having a recovery are different things, and the gap between them is enormous. Surveys of disaster-recovery readiness find that around eighty percent of organisations are not genuinely prepared, that roughly a quarter never test their recovery plan at all, and — the figure that should stop you cold — that something like fifty-eight percent of backups fail when someone actually tries to restore from them ^[3]. The reasons are mundane: the backup silently stopped running months ago, it captured a corrupted database, it is missing the one system that mattered, or no one had ever practised the restore so it took three days under pressure instead of three hours. An untested backup is not a safety net; it is a story you tell yourself.

Ransomware has made this the central question rather than a peripheral one, because it attacks the recovery directly. The instinct is to assume that if you are hit you can just pay and get your data back — but that bet is failing more often every year. In Barracuda’s 2025 research, forty-one percent of organisations that paid the ransom still did not recover all their data ^[4], and CyberEdge found only fifty-four percent of paying victims recovered their data at all, down from seventy-three percent two years earlier ^[5]. Paying is not a recovery plan; it is a coin flip you are funding. The only thing that reliably brings a business back is a clean, isolated, tested backup the attacker could not reach — which means modern backups have to be kept offline or immutable, because ransomware now deliberately hunts down and encrypts the backups first.

The fix is to stop treating continuity as a product and start treating it as a designed property of your systems, anchored to those two numbers from the first figure. Decide your RPO and RTO deliberately — how much data you can lose, how long you can be down — for each part of the business, because they differ: losing an hour of orders is survivable, losing the customer ledger is not ^[6]. Then build to meet them: multiple copies on different media with at least one off-site and one immutable, automated so no human has to remember, and — the part everyone skips — restores tested on a schedule so you know the number is real before you need it. This is far easier when your business runs on systems you own and can reason about than when your data is scattered across a dozen rented apps you cannot see inside. Resilience is not bought in a panic after the failure. It is built in quietly, long before.