A backup you have never restored is not a backup

Backups fail quietly. The job reports "completed", the disk fills up, a password changes, a folder is excluded by mistake, and nobody notices until the day a restore is needed. A backup you have never restored is a hope, not a plan. Here is how to turn it into a plan.

Start with two questions

Before choosing any tool, agree two numbers with the people who run the business:

• How much work can we afford to lose? If the answer is "a day", a nightly backup is enough. If it is "an hour", you need something more frequent.
• How long can we be without this system? If the answer is "a day", restoring from a slow offsite copy may be acceptable. If it is "an hour", it is not.

These are often called the recovery point and recovery time. Writing them down for each important system (email, files, accounts, the website and its database) tells you what to buy and how often to test.

The 3-2-1 rule

A simple rule that has stood the test of time:

• 3 copies of the data (the live one and two backups),
• on 2 different kinds of storage or locations,
• with 1 copy somewhere else, away from the building and the main network.

A backup drive plugged into the same server it protects is one fire, theft or ransomware infection away from being useless.

Keep one copy that ransomware cannot reach

Ransomware tries to find and encrypt backups as well. Keep at least one copy that is offline, or stored so that it cannot be changed or deleted for a set period, and that uses different credentials from your everyday administrator account. If the same password opens everything, an attacker who gets it can reach everything.

Back up databases properly

Copying the files of a running database is not a reliable backup. Use the database's own export or snapshot tool so the copy is consistent. For a website, back up the database and the uploaded files, and keep the previous release of the application so you can roll back. We take a database export and keep the previous release before every deployment.

Do not assume a cloud service is your backup

Services such as email and shared files keep deleted items for a limited time and protect against their own failures, which is not the same as protecting your data from your mistakes or from an attacker with a stolen password. Check the retention period and the recovery limits in your plan, and decide whether you need a separate backup.

Test restores on a schedule

This is the step that matters most:

1. Pick something specific, such as one important folder, one mailbox or the website database.
2. Restore it to a separate place, never over the live copy.
3. Check that it opens and that the recent data is there.
4. Note how long it took and what went wrong, and fix it.

Do this regularly, and do it after any significant change to the systems. Test a full recovery of the most important system at least once, so the first time you do it is not during an emergency.

Write the procedure down

Keep a short, printed-or-offline document: where the backups are, how to get to them, who has the credentials, and the order to restore things in. Include the encryption keys or passwords for the backups, stored separately from the backups themselves. A backup you cannot decrypt is the same as no backup.

Watch for failure

Send backup job results to a person, not to a mailbox nobody reads, and treat a missing report as a failure. The most common cause of a lost backup is one that stopped working weeks ago.