What It Actually Means
The word does a lot of quiet damage, because it makes people think about the copy. The copy is the easy part and it is not what protects you. What protects you is the restore, and a restore is a process involving people, access, decisions and time, not a file sitting on a disk.
The Only Question That Matters
When did you last restore from a backup and check the result?
If the answer is never, you do not have backups. You have the belief that you have backups, which is a different asset and worth considerably less.
This is not a pedantic distinction. Backups fail silently and routinely. A job that has been erroring for months while reporting success. A database dumped mid-write and therefore unusable. A backup running faithfully on a server that was decommissioned in March. Uploaded files excluded from the job because someone set it up to cover the database only. Every one of these looks completely healthy from the outside, and every one is discovered at the worst possible moment.
A restore test is the only thing that converts an assumption into a fact.
What Good Looks Like
Three copies, on two different kinds of storage, with one of them somewhere else entirely. That old rule survives because it addresses the three ways backups actually fail: the file is corrupt, the storage dies, or the event takes out the building.
For a modern business the third copy usually means a different provider rather than a different building, and that matters more than it used to. A backup held in the same cloud account as the live system shares that account’s fate. If the concern includes someone gaining access, or a billing failure, or an account suspension, a copy inside the same boundary is not a copy at all.
The other half is retention. Backups that only go back a week protect you against hardware failure and nothing else. Corruption and unwanted changes are frequently noticed weeks later, and by then the bad state has been faithfully copied over every version you hold.
What To Ask
- When did we last do a full restore, and how long did it take? The time is as important as the outcome.
- What is actually included? Database, uploaded files, configuration and email are four separate things, and jobs often cover one.
- How far back can we go? Then ask how long a problem typically takes to notice, and compare the two numbers.
- Who can perform a restore? If it is one person, and they are on holiday, you do not have a recovery plan.
- Where is the copy held, and does it share an account with the live system?
The Ransomware Change
One thing has shifted the requirements genuinely, rather than as a sales point. Attacks now target backups first, because encrypted backups are what turns an incident into a payment.
The practical answer is immutability: backups that cannot be altered or deleted for a defined period, by anybody, including someone holding your credentials. Most serious backup services offer this and it is often not switched on. It is worth asking specifically, because “we have offsite backups” and “we have backups nobody can delete” are very different positions to be in during an incident.
Backups are the first half of the problem. What happens next, and how long the business can tolerate it, is disaster recovery.
More terms are in the glossary.
