In this chapter we will learn how to test that our backup works. There are three major steps to take: restoring your backup, performing integrity tests, and analyzing the logs.
Let’s start with the first step!
Restore Your Backup
Creating a backup is one thing, but what if you want to get something back? And before that eventful day, wouldn’t it be a good idea to check that your backups are working as expected?
Let’s take a look at how to check our backups and then do a test restore in this video:
The first thing we did was to tell Robocopy to compare a list of the files in the last backup to those in the source folder now. To do this, the command used was:
robocopy e:\backup c:\windows\fonts /L /NJS /NJH /NDL /FP
An empty list of differences is a very good sign. You should expect some differences for a busy source folder, such as one containing documents, due to new and deleted files.
A long list of files could mean a lot has changed since the last backup, or that something is not right and needs investigating; it could be as silly as a typo in the file or folder names, so we’re comparing the wrong files - check for that!
Once it looked like we had a good backup, we restored it to a test location to check it out.
robocopy e:\backup restore /E
It’s good to know that we could retrieve what we backed up!
That’s progress, but how do we know that our backup and restore operations are working as expected? Let’s see how to perform an integrity test to find out.
Perform Integrity Tests on the Results
Ther earlier backup list check and test restore looked good, but a more definite test is performing a manual file comparison, which is an important part of backup integrity tests.
The integrity test ran a binary (/b) file comparison between one of the restored files and the original:
fc.exe /b restore\arial.ttf c:\windows\fonts\arial.ttf
If all goes well, we’ll be told there are no differences:
A more thorough test would be to compare all the restored files against the originals, but that level of scripting is outside the scope of this course.
Analyze the Logs
Earlier, we learned how Robocopy can create log files with the /LOG: option.
The log is a standard text file that can be examined in different ways; let’s take a look:
To display the contents of the log file, PowerShell has the “type” command - for example:
type logfile.txt
The name of the log, logfile.txt , allows you to view your text file without modifying it.
As you saw in the video, if you want to check out a larger file, you can put it in Notepad. And guess what? You can actually do it from the PowerShell console with the following command rather than heading back to the graphics world, just like this:
notepad logfile.txt
Although this log gives a written audit trail of what files were copied, it does not confirm the integrity of the files. And as a final trick, instead of writing a new log for each operation, you can append to existing ones by using the /LOG+:FileName syntax.
Let’s Recap!
To test that our backup works we need to:
Try and restore our backups.
Perform integrity tests.
Analyze the logs.
If we can restore a backup, we know we’ll be safe if we lose something one day.
Running integrity tests allows you to know that restored data is the same as the original.
Robocopy can create log files so that we can confirm that backups are being attempted.
We’ve covered the basics of Robocopy, and we can now create scripts to run specific operations on-demand. Still, it would be great to have some things, such as a backup, happen automatically. So let’s see how Windows lets you schedule your scripts.
