Problem solve Get help with specific problems with your technologies, process and projects.

Enterprise virtual tape library (VTL) decision: Performance issues

A number of factors should be weighed when helping customers make a decision around an enterprise virtual tape library (VTL). Find out how to evaluate whether your customer's infrastructure is matched to the performance of an enterprise VTL.

In a recent article on, titled "How to choose an enterprise-ready virtual tape library," Robert L. Scheier gave a high-level overview on what your customers should look for in when making a decision on an enterprise virtual tape library (VTL). The challenge for you is that you need to know the nitty-gritty details so you can be assured that your customer will be happy with the investment and see you as the trusted advisor.

One of the details that you need to examine is performance/speed. While every customer wants to reduce their backup window, the first question you have to ask is, If you put a faster device in your customer's environment, would it actually make a difference? In other words, can their environment and their infrastructure actually deliver the performance to the speedy new backup target?

To determine the answer to that question, first look at their network. Can it deliver the backup payload as fast as the enterprise VTL can receive it? In many cases, it won't be able to. For many data centers, getting that performance will require a considerable investment in SAN-based backups -- which increases the cost and complexity of the backup process. It may mean moving more servers to the SAN and enabling those already on the SAN to actually use the SAN for the backup process.

Implementing a SAN-based backup process and upgrading the infrastructure may be required to get maximum performance and a maximum decrease in the backup window out of an enterprise virtual tape library. But rather than SAN-based backup and a VTL, a network-based backup target, like those from Exagrid, Data Domain or FalconStor, might be a better decision. Some of these systems can receive data as fast as virtually any IP-based network can send the data, and while that may not be as fast as the enterprise boxes, it may be all the customer can achieve. The customer is likely to still decrease the backup window but do so at a lower cost and fewer infrastructure changes than those required for SAN-based backup and a VTL. With today's thin IT staffs, minor changes are more popular than major changes.

Another alternative may be to advise your customer to implement an archive system that eliminates a significant portion of the data to be backed up, as we discuss in our article on using archiving to fix backup network weaknesses. This can be complementary to a VTL but would reduce the size of that investment substantially. It may also eliminate the need altogether. Removing 50% of the data set cures a lot of backup issues.

After you've considered the network and data issues, the servers and the applications on those servers are the third area to look at; can they deliver the performance that the network and the virtual tape library are able to sustain? Slow, old servers or inefficient backup applications may not be able to keep up with the backup process. Also, the backup software may have to send backups from multiple servers simultaneously (known as streaming) to be able to fully utilize the backup network. Some customers will balk at streaming. It's a well-vetted technology, but some companies don't want to intermingle data, and in some cases, it can impact recovery performance.

Application backup can be a pokey process -- faster or slower depending on the application and the backup tool. Beyond specific applications, another challenge is backing up big file servers: They often have millions and millions of files, and backup applications get bogged down trying to decide which files need to be protected and which ones don't. Again, another great case for archiving; by reducing the amount of data to be backed up on a regular basis, your customer can significantly lighten the load on the VTL.

That's only a portion of what you need to consider when guiding your customers around an enterprise VTL decision. In our next article, we'll address the scalability issue.

Here's what Robert Scheier had to say about the topic:

How to choose an enterprise-ready virtual tape library

Definitions of an enterprise virtual tape library (VTL) environment vary, but vendors and analysts generally agree that an enterprise-class virtual tape library should back up at least tens of terabytes of data daily and be able to store hundreds of terabytes of data. These high-end virtual tape libraries also need to scale easily and support complex backup and recovery environments, such as those that include multiple remote offices or multiple VTLs in the storage fabric.

The ability to easily add disk capacity is important not only because organizations are backing up more and more data all the time, said Lauren Whitehouse, an analyst at Milford, Mass.-based Enterprise Strategy Group (ESG), but because companies often buy their first VTL to meet the needs of a specific department and then add to it as they see the value it provides.

Read the rest of the story on how to make a decision on an enterprise-ready virtual tape library by Robert L. Scheier.

About the author

George Crump is president and founder of Storage Switzerland, an IT analyst firm focused on the storage and virtualization segments. With 25 years of experience designing storage solutions for data centers across the United States, he has seen the birth of such technologies as RAID, NAS and SAN. Prior to founding Storage Switzerland, George was chief technology officer at one of the nation's largest storage integrators, where he was in charge of technology testing, integration and product selection. Find Storage Switzerland's disclosure statement here.

Dig Deeper on Storage Backup and Disaster Recovery Services

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.