Backups you have actually tested rather than assumed

Aug 29
3 min read

Updated: 3 days ago

Introduction

A business has backups. Something runs overnight, there is a green tick somewhere, and everybody assumes the position is covered. Nobody has ever restored anything from it.

When it is finally needed, the backup turns out to have been failing for eight months, or to cover only one folder, or to be on a drive in the same building that burned, or to be encrypted with a password nobody has. A backup that has never been restored is a belief rather than a protection, and the distinction only becomes visible at the worst possible moment. By which point there is no alternative to fall back on.

1. Backups you have actually tested are the only ones that count

The central point.

An untested backup has an unknown probability of working. Restoring a file occasionally, and a full system periodically, is what converts an assumption into a known position.

2. Establish what is actually being backed up

Frequently less than assumed.

Accounting data, the customer system, email, shared drives, the website, and files on individual machines. Businesses discover during a restore that a critical system was never included at all. Email and cloud systems are the ones most commonly assumed to be covered.

3. Keep a copy somewhere else

The most common structural failure.

A backup drive in the same office as the server does not survive fire, flood or theft. At least one copy should be somewhere physically separate, which is what cloud backup provides most easily. A drive taken home weekly also works and depends on somebody remembering.

4. Keep versions, not just the latest copy

Protection against the slow problem.

Ransomware, corruption and accidental deletion can be replicated into the backup before anybody notices. Several historic versions, going back weeks, are what allow recovery to a point before the problem started.

5. Test a restore on a schedule

Quarterly is reasonable.

Restore an actual file, and periodically attempt a fuller recovery. This finds the missing folder, the expired credential and the corrupt archive while it is still an inconvenience.

6. Know how long a full recovery would take

The number nobody has.

Restoring from a cloud backup can take a considerable time on a normal connection. If the business cannot operate for three days, a backup that takes four days to restore has not solved the problem.

7. Check that cloud services are covered

The gap people assume away.

Software providers protect their own infrastructure and generally do not protect you from deleting something or from a departing employee removing data. Whether you need a separate backup of cloud data is worth establishing explicitly.

8. Secure the backups themselves

They contain everything.

A backup is a complete copy of your personal data and needs the same protection: encryption, access control, and consideration in your retention schedule. Backups are a common route by which data is exposed.

9. Write down what to do

Because the person who knows may not be there.

Where backups are, how to access them, what the credentials are and what order to restore in. This is the document nobody has when it is needed, usually because the one person who understood it is unavailable.

Include the backups in your retention thinking. Deleting data from live systems while it persists in backups indefinitely undermines the retention schedule, and most frameworks expect this to be addressed rather than ignored.

Conclusion

Test the restore, because an untested backup is an assumption.

Establish exactly what is included and confirm nothing critical is missing, keep at least one copy physically separate from the premises, retain multiple historic versions rather than only the latest, schedule an actual restore test at least quarterly, find out how long a full recovery would take against how long you can be down, check whether your cloud services need separate backup, secure and encrypt the backups themselves, document where they are and how to use them, and account for backups in your retention schedule.