Ten Backup Mistakes in a Virtual Environment - Part 5
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:
- Mistake #1: Not Backing up Virtual Machines
- Mistake #2: Installing a Backup Agent on Every Guest
- Mistake #3: Running Two Backup Infrastructures
- Mistake #4: Failing to Protect Your Applications
- Mistake #5: Backing Up Applications Twice
- Mistake #6: Backing Up to Tape-only (or Disk-only)
- Mistake #7: Backing Up Redundant Data
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.