Disaster Recovery & DR

They get sold together and mean different things. A backup is a copy of your data. Disaster recovery is your ability to be operating again — with people working, orders going out, invoices being raised — within a time you decided in advance.

You can have perfectly good backups and no disaster recovery. If your server dies on a Monday morning and the data is safe but there is no hardware to restore it onto, no configuration to rebuild the system from, and no one who has ever practised the restore, then the copy is genuine and the business is still stopped.

We treat them as two questions. What are we protecting, and how quickly must it be running again? The second question drives most of the cost, and it is the one most quotes never ask.

The rule is old and still correct: three copies of your data, on two different types of media, with one held offsite. It survives because it fails gracefully. Any single event — a dead disk, a flood, a stolen laptop — takes out at most one leg.

What ransomware changed is that an attacker who reaches your network does not only encrypt the live data. They look for the backups first, because a business with working backups does not pay. If your backup target is a share the server can write to, it is inside the blast radius.

This is why we use immutable backups: once written, a copy cannot be altered or deleted for its retention period, by anyone, including an administrator account that has been compromised. It is the difference between a backup that survives a bad day and one that was quietly destroyed a week before you needed it.

There is a widespread and expensive assumption that data in Microsoft 365 or Google Workspace is backed up because it is in the cloud. It is replicated, which is not the same thing. Replication faithfully copies a deletion.

Both providers operate a retention window and are explicit that protecting your data is a shared responsibility. If someone deletes a mailbox, a departing employee empties a shared drive, or an account is compromised and used to destroy files, recovery depends on noticing inside that window. Discover it a few months later — which is common, because nobody misses an archived folder quickly — and there is nothing to restore.

We back up SaaS data alongside on-premise data, on your retention terms rather than the provider's. If you run Microsoft 365 or Google Workspace, this is usually the largest unprotected surface in the business.

Two numbers govern everything else. Recovery Time Objective is how long you can afford to be down. Recovery Point Objective is how much work you can afford to lose — the gap between your last good copy and the moment things broke.

Most businesses have never set either, which means both get decided in the middle of an incident by whoever is most senior in the room. That is the worst possible time, because the honest answer to 'how much can we lose' is always 'nothing' when you are standing in the outage, and nothing is expensive.

Set calmly and in advance, the numbers are usually more relaxed and far cheaper to engineer. A finance system that must be back in two hours and an archive that can wait until Thursday should not receive the same protection, and paying for the strict tier across everything is how continuity budgets get wasted.

The failure we see most often is not an absent backup. It is a backup job that has been reporting success for two years onto media that cannot actually be restored from, or that has been silently skipping the one database that mattered.

A backup is only proven by a restore. We test restores rather than trusting the green tick in the console, because the console is reporting that a job ran, not that your business can be rebuilt from what it produced.

If you are not certain when your restore was last tested, that is the finding — and it is the sort of thing an infrastructure assessment exists to surface before it becomes an incident.