Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Backup Exec

Ten Backup Mistakes in a Virtual Environment - Part 5

Created: 13 Sep 2010 • Updated: 28 May 2014 • 2 comments
Digital Dave's picture
+1 1 Vote
Login to vote

Here’s the last post in our series on common backup mistakes in virtual environments.  For a quick recap, we covered the following in the first four posts in our series:

There are three more mistakes that are all-too-common among IT Managers.

Mistake #8: Treating Backup as an Island

You have invested a lot in virtualization tools – both in real money and in time to learn how to optimize them.  Backups should be a regular part of day-to-day activities and not seen as an obtrusive ‘out-of-band’ process.  Unfortunately, a lot of backup solutions do not work well with VMware and Hyper-V.  They don’t leverage new APIs or integrate with their infrastructure.  This lack of support and integration usually means you end up with extra steps during your backups, during your recovery, or during both.  The simple solution here is to ensure the roadmaps are aligned between the backup solution and the virtualization technologies…don’t get stuck with a backup vendor that doesn’t share your enthusiasm for the benefits of virtualization.     

Mistake #9: Failing to Use Your SAN

If you have a storage area network (SAN) then you should take advantage of it for your virtual server backups and restores.  Many IT organizations only use their local area network (LAN) as their backup network, missing the speed benefits afforded by a dedicated network while at the same time inflicting a performance drag on your LAN.  The new vStorage API from VMware makes restores of VMs over the SAN straightforward. In Backup Exec, for instance, you just need to provide a LUN for media server and make sure the SAN transport mode is enabled (it is on by default) in the VMware backup and restore settings.  So, make sure you know not only what you are backing up and where you are backing up, but also the path you are using to backup your virtual servers.

Mistake #10: Failing to Consider Restore

Backup is worthless if you can’t restore.  One of the most common challenges in backup is the failure to consider recovery.   This is even more common in virtualized environments because there are more options to restore than in the pure physical world.  When considering restore, you need to take into account what you want to restore and the level of granularity.  It’s also wise to consider where to restore to (physical or virtual, onsite or offsite, etc.).  Once again, IT needs to work with key stakeholders to consider objectives and the associated process for restore.  It’s also a good idea to have a written plan that all stakeholders agree to, and to test that plan regularly. 

That recaps our list of ten.  Any other additions?  I’d love to hear your thoughts.  From my perspective, the proliferation of virtualization produces a number of data protection challenges. I hope that recapping some of these challenges will help you identify simple solutions and steps to avoid the common pitfalls in your data protection strategy.

The move to virtual servers is a real opportunity to improve your backup infrastructure, so look for more entries on backup of VMware and Hyper-V backups.

Blog Entry Filed Under:

Comments 2 CommentsJump to latest comment

Symanticus's picture

Yes I agree, the last point is whee most people usually don't test it.

/* Infrastructure Support Engineer */

Login to vote
UrbanLegendPA's picture

This tip may seem obvious.

Keep at least 1 copy of the current backup software and license keys with your backups.

Imagine getting ready to restore and finding you don't have the software to do it?

I have seen several recovery attempts fail or seriously delayed by this one!

Login to vote