Backups that have actually been restored

Every business we assess has backups. A meaningful proportion of those backups would not have worked. The job had been failing silently for months. The backup covered the file server but not the application database. Everything was backed up to a drive in the same room as the server, which addresses hardware failure and nothing else. Or the backups were technically fine and nobody had ever attempted a restore, so nobody knew how long one would take.

That last category is the most common and the most dangerous, because it feels safe right up until the moment it matters.

Testing is the entire point

We restore from your backups on a schedule and document the results. Not a verification that the file exists, an actual restore into an isolated environment, confirming the data is intact and usable. This is the only way to know whether your backup strategy works, and it is skipped almost universally because it takes time and nothing appears to be wrong.

Two numbers that define your strategy

Recovery point objective is how much data you can afford to lose, which determines backup frequency. Recovery time objective is how long you can afford to be down, which determines the recovery method. A business that can tolerate losing a day and being down for two has a completely different and much cheaper design than one that can tolerate neither.

Most businesses have never been asked these questions directly, and answering them honestly is usually the most valuable hour of the whole engagement. It converts backup from a vague sense of caution into an engineering requirement with a cost attached.

Ransomware changes the design

Modern ransomware seeks out and encrypts backups before triggering, because that is what makes victims pay. A backup reachable from the network it protects is not reliable protection. We use immutable and air-gapped copies that cannot be altered or deleted within their retention window, even by an account with full administrative rights.

What a written plan contains

Who is contacted and in what order. Which systems come back first, because trying to restore everything simultaneously is how a bad day becomes a bad week. Where the credentials are, given that your password manager may be among the things that are down. How you communicate with staff and customers. Writing this during an incident is how a recoverable event becomes a prolonged one.