A backup you have never restored is not a backup

Almost every company we talk to has backups. Far fewer have ever restored one. The difference only shows on the worst day.

Two things we found in real work: a router whose nightly backup had stopped weeks earlier while everyone assumed it was running, and, after a ransomware attack, a 1.09 TB backup disk that had been encrypted together with the servers it was meant to protect.

Four ways backups fail quietly

1. The job stopped and nobody noticed. A password changed, a disk filled up, a scheduled task was disabled. Nothing alerts you, so the last good copy gets older every day.
2. The backup sits where an attacker can reach it. If it is on the same network and deletable with the same administrator account, ransomware treats it like any other disk.
3. It copies something it should not. On one network, the router's configuration export was copying an administrator password, in plain text, into every backup file on shared storage. Backups are as sensitive as the systems they copy. Protect them the same way.
4. It has never been restored. Missing files, the wrong version, a restore that takes three days instead of three hours: you only learn these by restoring.

A routine that works

• 3-2-1: three copies of the data, on two different kinds of storage, with one kept off-site or offline.
• Alert on failure, and on silence. Get a message when a backup fails, and also when none has succeeded for a day.
• Restore on a schedule. Once a month, restore to a test machine and open the data. For a database, run a query you already know the answer to.
• Write down two numbers: how much data you can afford to lose (an hour? a day?) and how long you can afford to be down. They decide how often you back up and how you restore.
• Separate the keys. The account that runs your servers should not be able to delete your backups.

For databases in particular

• A plain file copy of a running database is often unusable. Use the database's own backup tools.
• Use the engine's own check, such as RESTORE VERIFYONLY in SQL Server, and still do a full restore now and then, because a verified file is not the same as a working system.
• Restore to the same version you run in production. SQL Server has no supported way to move a database back to an older version; in one recovery we had to build a custom bridge to do it.

Not sure your backups would actually work? Talk to us about testing a restore together.