A step-by-step guide to testing your backups on World Backup Day

World Backup Day – which is March 31st – is coming up quickly. It’s the perfect day to test your backup system and make sure you can quickly recover critical business data in the event of a disaster or outage. World Backup Day is a great opportunity to make sure your backup is configured properly and that you have the necessary know-how and access to recover data when needed.

Here’s a step-by-step guide to three different backup and recovery tests that you can perform. Master these tests and it will help ensure that your business stays in business following an outage.

1. Spot checking file system backups
File level backup is the most basic and it’s the right choice for folks who are backing up file systems in Mac, PC or server hard drives. In order to make sure you can recover files that are lost, first go to the file system being backed up and choose a few files that have some value to you and have been recently added or changed. Let’s assume they were accidentally deleted and you want to recover them. Create a temporary folder called “test-restore” and use your backup software to locate the files in your backup system. Restore them to the “test-restore” folder and compare the restored files to the originals. Are they the same size in bytes? Can you open the restored files and view their contents? Using this simple test you have confirmed that you know how to find files in your backup system, that the backups are current, and that you are familiar with the backup system’s restore functionality.

Repeat that process a few times with a random sampling of files. If you’re able to recover the files each time, then you can reasonably assume that all files are being backed up correctly. Just remember, when you run this test, use different files each time. That will give you the most reliable results. Using this simple test you have confirmed that you know how to find files in your backup system, that the backups are current, and that you are familiar with the backup system’s restore functionality.

2. Testing a full file system restore
The second recovery test we’ll talk about also applies to file systems found in Mac, PC or server hard drives. But it’s a little more challenging because it requires sufficient free space to accommodate the volume of data to be restored and is also more time consuming.

This test ensures you can recover from a total loss in the event your computer has been destroyed, stolen, lost, or just won’t work. In those events you’re going to need to complete a full system restore. And it’s a good idea to test your ability to perform this function at least once in a while so why not give it a whirl on World Backup Day?

To get started, you’re going to need enough free disk space to recover all of the files in your backup. If you have a spare computer or server with sufficient free space, you can use that for the recovery. Simply use your backup system to restore the files to the spare computer. After the files are restored, do another random sampling of files to make sure they were restored properly. If you do not have a spare system, you can complete the full system restore on the same server or hard drive if there is enough space. Just be careful not to overwrite your existing files.

In addition to spot checking a few files, another way to confirm that a full system restore test was successful is to compare the total storage utilization of the files you restored to the original source of the files. The numbers may not match up exactly because of normal changes that have occurred since the last time the system was backed up. But if the numbers are reasonably close, you’ll know the test was a success and that your backup is working and actively protecting your valuable data.

3. Database Recovery and Verification
Now I’d like to talk about testing your database backup – and it’s important to understand that this testing mechanism is somewhat different than the other two.

First off, when testing database backup and recovery, you absolutely must have a place to restore the data that won’t interfere with the original database. But the server that you choose to restore the data to should have the database management system software already installed. For example, if you’re attempting to restore a SQL Server database, you need to restore it to a machine that’s running the SQL Server engine so you can verify the integrity of the recovered database.

You can recover the database to the same machine that houses the production database if you don’t have a spare and there is enough space. But be careful. The key here is to use a different name for the restored database so you don’t overwrite your real database or interfere with the production use of that database. This is the way to go if you only have one database server. But if you have the resources to test the restore capabilities on a spare server – that is the preferred way to go. Another option is to run the test by restoring the data to a virtual machine in the cloud.

Once you’ve restored the database to your chosen location, there are three types of tests you can do for verification:

• The first is to run a spot check. You can accomplish this by running queries against the production database and the recovered database and comparing the results. If the results match up, you’ll know the recovery was a success. For example, run a query that adds up last week’s sales in both the production database and the restored database. Do you get the same result?
• The second is to run a macro test. In this case, you could simply count the number of rows in a critical table or get the overall size of the database itself in terms of storage utilization. Those numbers should roughly match your production database and any difference should be easily explainable by the normal operation of the database.
• A third type of test is a little bit harder to set up but is very effective. The idea is to connect your applications to the recovered database and make sure they operate correctly. This is an important test because when you recover systems following a disaster, what people ultimately care about is whether the business applications they use are working.

Testing your backup is important since it verifies that your backups actually contain your data and that you know the steps to follow to recover from a data loss. This practice is important so that you stay calm and efficient when under the pressure of a real data loss. Testing once a year is better than never so give it a try on World Backup Day this year!