Now that disk is being used as a primary backup target in more enterprise shops, companies need to reevaluate what role, if any, multiplexing should play in their future backup plans. Here are some questions to ask to help you decide if multiplexing still makes sense technically and financially:
How much data do you have to back up? (And how much money do you have to do it?)
Despite the growing capacities and shrinking costs of disk, the cost per gigabyte of tape is still a fraction of that of disk. Companies backing up multi-terabyte databases or multiple application servers with short backup windows may still need to use tape drives in conjunction with multiplexing in order to complete backups affordably and within the desired backup window.
In what format do you wish to store backup data?
When backup data streams are multiplexed, the data is stored in a format that is only readable by the enterprise backup software product that performed the multiplexing. Conversely, most backup software products give users the option to back up and store data in a format (such as tar) that is readable by other backup software products or native operating system utilities.
What is your recovery time objective (RTO)?
Disk can provide almost instantaneous recovery times, while trying to recover multiplexed data from tape can add significantly to the time required to recover the application data. Because multiple backup data streams are stored as one, de-multiplexing this interleaved data can add significantly to the recovery time.
How fast is your tape drive?
Disk's most desirable component is that it isn't impacted by the flow of backup data. Whether data is backed up at a rate of 2 MB/sec or 200 MB/sec, there's no chance of shoeshining, resulting in faster, successful backups. Conversely, today's new, faster tape drives may require multiplexing even more backup jobs into one in order to stream backup data fast enough to the tape drive to avoid shoeshining.
About the author: Jerome M. Wendt is lead analyst and president of DCIG Inc.
This was first published in May 2008