Enter your email address:
Delivered by FeedBurner
Previous Blog Posts
Monday, August 24, 2009
It seems lately that server virtualization has become the poster child for wringing out costs from legacy IT environments. Our tough economic climate has everyone focused on short-term cost reductions, with virtualization and server consolidations topping the list of projects that can produce fast and sizable cost savings. So, I wasn't too surprised when every client and prospect I met with while in New York City recently told me about server virtualization projects they'd all given the green light this year.
Industry research reveals a growing trend to jump on the virtualization bandwagon. More than 1,400 U.S. CIOs were polled in a recent Robert Half Technology spending survey, of which approximately 70 percent said they'd spend money on new IT initiatives in the next 12 months. Of those CIO's that indicated plans to invest in IT, 39 percent at large (1,000+ employees) and midsize (500 to 999 employees) companies plan to invest in virtualization. From the survey, added budget pressures were forcing many companies to focus on more cost-effective solutions for servers, storage and networking; virtualization tools were noted as enabling "greater consolidation, lower hardware costs, and reduced space and power requirements."
While it's easy to see how you can justify server virtualization and consolidation projects solely on cost reductions, I say there's no better time to overhaul the backup and recovery platform you've most likely outgrown. If your backups can't handle virtualization adequately, you'll most likely quickly lose the cost benefits. That's why any server virtualization or consolidation project provides a great opportunity to revisit and improve your underlying data management infrastructure. If you don't address it now, it's like building a new house and then carting over and installing the rickety, energy-wasting furnace from your old house. You wouldn't consider doing that, especially since it's obvious it would cost you more in the long run to keep the faulty furnace operational.
The same can be said for a backup and recovery solution. If you think your backups were in bad shape before you embarked on virtualization, what do you think will happen when you try to manage and protect the greater volumes of data now residing on both physical and virtual systems With less CPU resources, I/O, etc.? DCIG's Jerome Wendt wrote a blog recently on how server virtualization turns the data protection model upside down. In this post, he describes many of the same things I've been telling people: that running backup jobs on both virtual and physical machines can overload servers, congest network connections and result in even more failed backups. What's more, the performance of the apps you're running on virtual machines can be severely impacted by poor backup performance on physical servers. The bottom line: you need to think about data protection before you leap into virtualization.
Timing is everything, so waiting to tackle backup problems until you're in the midst of a virtualization project could be too late. Backup and recovery is a core infrastructure element, so it needs to be part of the design phase when you can look at all aspects of data management, including data protection, archiving, replication and reporting, as well as how these different areas change in a virtualized environment.
We believe strongly that if you extend your thinking about virtualization to consider the economic and performance benefits of fixing broken backups, you'll achieve a more favorable ROI overall. Otherwise, you're missing a huge opportunity to get rid of some major cost inefficiencies and fix some nagging problems. Why wait when you can reduce more costs, lower management overhead and improve data protection at the same time? I'd love to hear from anyone deploying virtualization to learn whether you're taking advantage of this IT infrastructure project to revisit your backups.
Please note that your comments will be sent directly to the author of this blog, and will be published upon approval per CommVault's comment policy.
The content of this blog reflects the thoughts and opinions of the author, and does not represent the thoughts, opinions, plans or strategies of CommVault Systems, Inc. ("CommVault") and CommVault undertakes no obligation to update, correct or modify any statements made by the author of this blog. Any and all third party links provided by this blog are not affiliated with, nor endorsed by, CommVault.