When it comes to designing a redundant backup solution, there are three main areas that you need to focus on. These include minimizing the chances that you will have to perform a restoration, implementing redundant backup servers and using redundant backup media.
Avoiding a restoration
When possible, restoring data from backup should be avoided. The restoration process can be disruptive and often results in the loss of any data that has accumulated since the creation of the recovery point.
The best way to minimize your odds of having to restore data is to use redundant servers and redundant storage on your production network. For instance, the Windows Distributed File System (DFS) can be used to replicate file data to replica servers so that the data remains intact and accessible even if a file server or its storage array were to fail.
Although using redundant servers and redundant storage can protect your network against certain types of failures, this type of redundancy is not a substitute for backups. Imagine, for instance, that someone made an incorrect modification to a file. Assuming that redundant file servers were in use, the modified file would be replicated to all of your replica servers. The only way to recover the lost data would be to revert to an earlier version of the file.
Redundant backup servers
The next issue that should be considered when planning a redundant backup solution is your backup servers. In most cases, the backup server is a critical part of the overall backup infrastructure, so you don't want the backup server to become a single point of failure.
The way in which a redundant backup server should be implemented varies considerably, based on your backup architecture. In many cases, however, you should not attempt to implement parallel backup servers that operate independently of one another. Doing so almost always results in backup consistency problems.
If your organization is performing disk-based backups, then the best approach is usually to design a two-step backup process. The idea behind this technique is that one backup server protects your production servers. The second backup server protects the first backup server. That way, if the primary backup server were to fail, the secondary backup server can be used to rebuild the failed server and the data that it has backed up.
Redundant backup media
Another way to protect your backups through redundancy is to use redundant backup media. There are many different forms of media redundancy.
If your organization still uses tape backups, then you can implement redundancy by creating two separate copies of each tape. That way, one copy can remain on premise where it is easily accessible, while the duplicate tape is shipped off-site for safekeeping.
If you are performing disk-based backups, then there are a few different ways to achieve media redundancy. One option is to perform disk-to-disk-to-tape backups, which copy the contents of your disk-based backups to tape for safekeeping.
Another option is to use mirrored storage for your disk-based backups. This allows your backups to be replicated to an identical storage array. It is worth noting, however, that this approach does not produce a backup on removable media. That being the case, organizations that are considering this approach would be wise to consider replicating the backup server's contents to the cloud or to a secondary data center rather than depending exclusively on hardware-level replication within the local data center.
As you can see, there are a number of ways in which backup redundancy can be implemented. It is important to keep in mind, however, that even a fully redundant backup solution does not guarantee that data can be restored. As such, it is vitally important to test your backups on a regular basis to make sure that they are functioning as intended and that your data can be restored if necessary.
About the Author:
Brien M. Posey, MCSE, has received Microsoft's MVP award for Exchange Server, Windows Server and Internet Information Server (IIS). Brien has served as CIO for a nationwide chain of hospitals and has been responsible for the department of information management at Fort Knox. You can visit Brien's personal website at www.brienposey.com.
This was first published in December 2012