The 3-2-1 rule
for backups

Three copies of your data — the original plus two — on two different kinds of media, with one of them outside the building where the original lives. Each number covers a different failure: the second copy covers the first one failing; the second medium covers one type of fault (mechanical, firmware, a bad batch) hitting both at once; the off-site copy covers fire, theft, water or anything else that happens to the whole building. It's a design rule, not a checking rule: it tells you how many copies to keep and where to put them, but says nothing about whether those copies will actually open on the day you need them. That part — the one that really decides whether the rule did its job — is what this article covers: the restore test.

By restoring, not by reading the backup software's log. Pick any file — not the easiest one, a random one — remove it from view or work on a copy of the system, and recover it from the backup as if you had genuinely lost it. Then open it. If it opens and the content is what you expected, that backup works at that point in time. If the process fails, stalls, asks for a password nobody remembers, or the recovered file won't open, you've just found the problem with plenty of time to fix it, instead of discovering it on the day you've really lost something. A "backup completed without errors" report doesn't prove this: it confirms that bytes were written somewhere, not that those bytes make up a readable file.

It depends on how much you rely on that data, not on one fixed schedule for everyone. For a household with photos and documents, a quarterly check is reasonable: pick a random file and open it. For a small business with shared folders in daily use, monthly makes more sense, because more people are creating new data and there's more room for something to break without anyone noticing. For critical data — accounts, a server that stops the business if it goes down — it's worth adding a full restore, not just a single file, at least once a year, to check how long it takes to be up and running again. Getting the exact frequency right matters less than having one, written down somewhere, with the date of the last time it was done.

Treat it for what it is: a broken backup that has been giving you a false sense of security, and much better to find out now than on the day you really need it. First, check whether the problem is isolated — that particular file got corrupted during the copy — or general — the latest full restore doesn't work either, which points to the scheduled task, the connection to the destination, or a destination that filled up long ago so recent backups were never written. Check the real date of the file you did manage to restore: if it's months old, the backup hasn't been updated in months, whatever the software says. Once the fault is fixed, repeat the test with a different file before trusting the system again.

Because "no errors" only certifies that the writing process didn't hit a problem it knows how to detect, and some failures don't fall into that category: a file that got corrupted during compression but was written anyway, a folder left out of the backup job after a path change nobody updated, access credentials for the destination that expired while the system keeps retrying silently, a full destination disk where the latest backups simply don't fit and are discarded without any visible warning. Every one of these produces a "completed successfully" history and a useless backup at the same time. The only way to catch them before you need them is to try to recover something real and check that what comes out is what you expected.

One named person, with the task in their calendar — not as something "someone should look at now and then", which is the formula for it never happening. It doesn't need to be the most senior technical person: the test itself — pick a file, restore it, open it, note the date — can be done by anyone with access to the backup system following a fixed checklist. What does help is for the same person to do it every time, so they notice changes in behaviour, and for the result to be logged somewhere with a date, even if it's just a shared spreadsheet. If nobody in the company has the time or the know-how to take this on consistently, that is exactly the gap a managed maintenance service fills.