The backup you have vs the backup you think you have

1 September 2026

Ask most businesses if they have backups and the answer comes back fast, without hesitation. Ask when they last actually restored one, properly, under pressure, with a stopwatch running, and the answer gets a lot quieter.

That gap is the one that matters. Having something called a backup running every night is not the same as having something you can genuinely recover from. For a long time that distinction felt mostly theoretical, one of those risks everyone nods along to but nobody quite gets round to testing. It isn't theoretical any more.

Why the old assumption doesn't hold up

Two things have shifted the picture over the past year, and both are worth understanding properly rather than filing under general IT background noise.

The first is that attackers have got much better at going straight for the backup itself. Recent research into ransomware incidents found that the overwhelming majority of attacks now specifically target backup repositories, not as an afterthought but as the opening move. The logic is straightforward from an attacker's point of view: if the backup survives intact, the ransom demand has no real leverage. Disable or quietly corrupt the recovery path first, encrypt everything else second.

The second is that even without an attacker anywhere near the picture, the infrastructure underneath "the cloud" is more fragile than most people assume. In July, a data centre in the Netherlands run by a major cloud provider lost power and cooling for close to fifteen hours, taking a meaningful chunk of that provider's European services down with it. It's a useful, if unwelcome, reminder that "it's in the cloud" describes a location, not a guarantee.

Put those two things together and the assumption that a nightly backup job quietly ticking along in the background is enough starts to look pretty thin.

The three ways backups usually fail without anyone noticing

None of this requires anything exotic to go wrong. The failures we see most often are quiet, ordinary, and entirely preventable:

• The backup runs, but nobody's ever restored from it. A green tick every night for two years tells you the job completed. It tells you nothing about whether the resulting file actually opens, or whether it's missing a database that got added to the system eighteen months ago and never made it onto the backup schedule.
• The backup is reachable from the same network as everything it's meant to protect. If an attacker who's compromised your live systems can also see and delete the backup, you don't have a backup, you have a slightly delayed copy of the same problem.
• Nobody knows how long recovery actually takes. There's a real difference between "we can get the data back" and "we can get the business running again within an hour, or a day, or a week." Most businesses have never timed it, so they're guessing, and guessing under pressure during an actual incident is a bad place to start.

Why this lands differently if you're in finance

If you're a hedge fund, family office or insurer, none of this is a background IT concern you can leave entirely to your provider. A few things compound specifically for you:

• Your investors, and increasingly your insurers, are asking sharper questions about operational resilience than they were even two years ago. "What's your recovery time for critical systems" is turning into a standard due diligence question, not a niche one, and "we have backups" isn't really an answer to it.
• Downtime has a cost that scales with what you manage. An hour of lost access to trading systems, client records or portfolio data isn't just an inconvenience, it's a number someone can put in front of a client or a regulator.
• If part of your operation depends on a third party managing your IT, the responsibility for knowing whether recovery actually works doesn't fully transfer to them. You can outsource the work. You can't outsource the accountability for having checked.

What a proper backup and disaster recovery plan actually needs

• Immutable, offline or logically separated backups. Copies that an attacker sitting inside your live network genuinely cannot reach, alter or delete, even with valid credentials.
• A defined recovery time objective and recovery point objective, in plain terms: how long can the business actually tolerate being down, and how much data can it afford to lose, measured in hours rather than vague reassurance.
• Regular, scheduled test restores, not a one-off exercise when the system was first set up, but something that happens on a calendar, with someone accountable for it, and a record that it happened.
• A tested failover plan for the infrastructure itself, not just the data. If your provider's cloud region goes down for fifteen hours, what actually happens to the people who need to keep working during that window.
• A named person who owns the plan. Not a shared responsibility, an actual name, so that when something goes wrong at 6am there's no ambiguity about who picks up the phone first.

What's worth asking your own provider

• When was our backup last actually restored, in full, and can you show me the result
• What's our current recovery time objective, in hours, for our most critical systems
• Are our backups reachable from our live network, and if so, why
• What happens to us specifically if your infrastructure has an outage like the one in the Netherlands this July

If your provider can answer all four without hesitation, that's a good sign. If any of them prompt a pause, that's worth following up before it becomes the question you're asking during an actual incident rather than before one.

We test restores as a matter of course as part of how we manage client environments, not as a special add-on. Happy to talk through what that looks like for your specific setup if it's useful.