Why testing your backups is critical by Ask Leo

Play
Audio

(not supported by Internet Explorer)

Testing your backups is an easy step to overlook, but an important step to take. Make sure your backups will be there when you need them.
As you might expect, after doing this for over a decade, there are individuals that I hear from fairly regularly, and whose names and/or email addresses become quite familiar to me. Over time, they start to feel like extended family.
This comment came from one of my long-time readers – a member of that family – after she detailed a story of … well, it really all boils down to this heartbreaking statement:
I had FIVE YEARS’ worth of files backed up in multiple places […]. Leo, I am astonished–just mind-blowingly astonished: while both [external drives had] backed up random, helter-skelter, files–sometimes redundant to the point of absurdity–BOTH did not make a backup.
She experienced a failed Windows 10 upgrade, and restored to Windows 7 only to find that massive amounts of data had been lost in the process.
A member of the family requests that we all learn from her painful experience.

Why testing your backups matters
I had to look up exigent: “requiring immediate attention: needing to be dealt with immediately” (via Merriam-Webster online).
Indeed, testing a backup – or rather, how to test a backup – was one of the most common issues when I first polled for questions relating to backups, some years ago.
“How will I know the backup will work when I need it?”
It’s an important question to ask, and an equally important question to act on. That’s why every one of my “Saved” series of books (which cover backing up with specific backup tools) includes a chapter dedicated to the topic, and why each of the companion video courses includes a step-by-step video on exactly that.
The only thing worse than no backup at all is a backup that doesn’t work when you need it.
How to test your backups
While the steps differ for each backup program, the conceptual approach to testing your backups is roughly the same everywhere.
After you have successfully backed up, then:
Pick an important (to you) file on your hard disk. Rename it. Now go restore the original from your backup, and make sure it’s the same. Assuming it’s successful, repeat this for several different files in different locations on your hard disk, to ensure that the files you expect to be backed up actually have been, and can be recovered if needed.
Create and boot from the “emergency disk” or “rescue media”, to make sure that it works and can “see” the back up you’ve created, as well as the hard disk onto which that backup might be restored. (This assumes your backup strategy involves making full image backups, as I recommend.)
Follow the sequence to actually perform an image restore, stopping at the very last step. Do not actually perform the restore. I’ll elaborate on why in a moment. (Again, assuming your backup strategy involved image backups.)
That first bullet – restoring a randomly selected file – is perhaps the most critical. In fact, it’s not uncommon at all in corporate environments for individuals to “test” their own IT departments or whoever is responsible for backing up, by running the exact same test. “Could you please restore this file from last night’s backup?”
Sometimes it can be quite the revelation when the IT department itself fails.
Why not actually restore that image?
The only true test of an image restore is to restore the image. Anything else – from extracting individual files from the image to walking through the restore process, but stopping short of actually initiating the actual restore – is actually an incomplete test.
Those tests are critical, because they do test important components of the process – and indeed, the components most likely to cause a problem – but they don’t test the entire process.
Only a complete, actual restore will do that.
Why not give that a whirl?
Because the whole point here is that we don’t know with 100% certainty that it will work. We might be 98% certain, or even higher, but not absolutely, 100% positive.
Our tests have significantly increased our confidence, but as absolute proof, they fall short.
The problem happens when that 2% chance of failure actually happens. You’ll have proven that the backup isn’t working, but there’s a good chance you’ve destroyed what’s on your hard disk in the process.
That risk, then, albeit a small one, is a risk we only elect to take when we must perform a restore “for real”.
The only other thing that might be possible to increase the confidence just a little further is to restore the image to an unused additional internal drive – an option most people simply don’t have.
When to test your backups
I recommend testing your backup strategy right after you’ve set it up, and of course, any time you make any major changes to the process.
What that probably means, in reality, is that you’d test it after it makes its first image backup, or after it’s backed up whatever it is you’ve configured it to back up.
I’d also be very tempted to set yourself a reminder some time in the future – say somewhere between two and six months – to test it again.
And then I’d also set a reminder to “every so often”, say once a month, just ensure that the backup is happening as expected. This doesn’t need to be a full test; just check that backup files or images are being created as you expect. One of the common failure modes for any backup tool is for its automation to simply stop for some reason, and without notice. And yes, that’s happened to me.

What to do if your test fails
Unfortunately, I can’t give you specifics on what to do if your test fails because, of course, it depends on what your backup strategy is, what tools you’re using to perform the backup, and exactly what the failure is.
What I can tell you is this: if your test fails, stop and fix it. Until you’re confident that your backup is working and working properly, you have no back up.
That is not a situation you want to be in for any length of time.
Backups generally work
I don’t want to scare you with all this talk of testing and failing backups. In fact, what I told the person asking the question was this:
"You’ve seen no broadcast warning from me because, to be honest, yours is an extremely rare case of failure. I regularly hear from people who are backing up who then successfully restore for a variety of reasons. I know it doesn’t help you, but stories like the one you’ve experienced are truly rare. More common are people who don’t try to back up at all. In most cases when people at least TRY to back up to the degree that you have, they are at least partially successful"
Backups generally work.
And generally, even if a restore fails, the fact that you have a backup – ideally an image – gives you options on how to proceed without massive data loss.
But as you can see, that’s not a guarantee.
Testing your backups is a key step – I’ll even say exigent – to increasing the likelihood that they’ll be there when you need them.