Why having a backup isn’t the same as having a recovery plan

The gap most people miss

When someone asks “do you have backups?”, the answer is almost always yes. Azure backs up your data. Your hosting provider runs scheduled snapshots. Someone somewhere is copying files to somewhere else.

But here’s the question that rarely gets asked: if your primary system failed right now, completely, catastrophically, today, what exactly would you do?

Not in theory. In practice. Who does it? What gets restored first? How long does it take? What does “restored” actually mean for your specific application, your database, your dependent services?

That’s the plan most organisations don’t have. And without it, your backup is just a file somewhere that has never been opened.

Azure, to use a common example, can back up your managed databases natively. But those backups are typically proprietary snapshot formats, they restore only within the same platform, under the same account. That is not a disaster recovery plan. It is not even close to one. Knowing your data exists elsewhere is not the same as knowing your service will run again in three hours, or that you could recover it at all if your Azure tenancy itself were compromised, suspended, or unavailable.

Holistic recovery means knowing exactly what needs to be restorable, not just what is being copied.

The single point of failure you’re probably not thinking about

Here’s a scenario that’s more common than it should be: the person managing your backups is also your only route to running a restore. That’s a dependency problem.

If that person is unavailable through illness, departure, or simply being overwhelmed by the incident you’re trying to recover from, then you have no recovery path. The backup exists. The knowledge of how to use it doesn’t.

The same logic applies to providers. There are documented cases of large organisations losing entire cloud tenancies through billing disputes, compromised accounts, or provider error. If your backup infrastructure sits within the same account or ecosystem as your primary infrastructure, a single incident can take out both simultaneously. Cross-region replication within the same provider adds some resilience, but it does not protect you from an account-level event. It is not a substitute for genuine independence.

What provider independence actually means

Independence isn’t just a configuration decision. It’s a design principle.

Your DR capability should be able to survive a failure of your primary provider’s platform entirely. That means backups held in a separate account, a separate tenancy, or for the most critical workloads an on-premises copy that is physically independent of any cloud account event.

It also means thinking beyond your application data. In modern infrastructure, the code and configuration that defines your environment is itself a critical asset. Terraform state, infrastructure-as-code repositories, CI/CD pipeline definitions, losing these can be just as damaging as losing your application data. A recovery plan that restores your database but not the infrastructure needed to run it is not a recovery plan.

And it means your recovery capability must be documented, tested, and understood by someone other than the person who built it.

Untested backups are not backups

This is the point most often skipped, and the one that causes the most damage when things go wrong.

A backup job completing without errors is not evidence that a restore will work. It is evidence that a file was written somewhere. Those are different things. The only way to know your recovery capability is real is to use it and to run a restore, end to end, against real data, before you need it.

This includes testing secrets, configuration, and infrastructure recovery, not just data in isolation. A recovered database connected to the wrong environment, missing credentials, or pointing at infrastructure that no longer exists is not a recovered service.

What recovery-readiness looks like in practice

A genuinely recovery-ready organisation can answer all of the following:

• What are the most critical systems, and in what order do they need to come back?
• What is the acceptable recovery time for each? What is the acceptable data loss window?
• Where are backups held, and are they genuinely independent of the primary environment, different account, different provider, or on-premises where it matters most?
• Are backups stored in a format that can be restored without the originating platform?
• Who can execute a restore and is that person available when something goes wrong?
• When was the last time a restore was actually tested, end to end, and documented?

If any of those questions produce a vague answer, a shrug, or a name that’s also the name of the person managing the primary infrastructure, there’s work to do.

How Pipe Ten approaches this

We don’t sell backup as a product. We work with businesses to build recovery plans that reflect how their infrastructure actually runs.

That means starting with a conversation about what matters most to your organisation, which systems, which data, which timelines and working backwards to a backup and recovery design that fits that reality. We cover the full surface: application data, managed databases, cloud infrastructure, and the configuration and code that holds it all together. Whether you’re running workloads in Azure, a virtualised on-premises environment, or a hybrid of both, the approach is consultancy-led rather than off-the-shelf.

Critically, we’re the experts on the restore. We define recovery objectives per workload, not as a single blanket policy. We test. We document. And we make sure recovery is possible by someone other than the person who designed it.

If you’re running infrastructure that matters, particularly in a regulated sector where recovery time and data integrity carry real weight and you haven’t recently asked hard questions about your recovery plan, that’s the conversation worth having.