Video Screencast Help
Backup Exec

Ten Backup Mistakes in a Virtual Environment - Part 2

Created: 31 Aug 2010 • Updated: 28 May 2014 • 2 comments
Digital Dave's picture
+2 2 Votes
Login to vote

Mistake #2: Installing a Backup Agent on Every Guest
As I mentioned in PART 1 of this blog article, I’m taking some time this week to talk through the common pitfalls in backing up data in virtual environments.  Installing a backup agent on every guest in the IT environment is one common strategy – and one that can result in higher costs from backup agents and unnecessary management complexity.
According to Enterprise Strategy Group, 62 percent of companies still backup virtual machines by installing a backup agent on every guest.  This has been a common strategy because of uncertainty about the ability to recover granularly, as well as the limitations imposed by virtualization vendors. 
Virtualization vendors have improved APIs to support centralized backup with granular restore, and many vendors have the ability to backup at the hypervisor level – all making it unnecessary to install a backup agent on every guest for backup purposes. 
Mistake #3: Running Two Backup Infrastructures
As we covered in the first blog post, the growth of virtualization has been a lot like the growth of many disruptive technologies.  In the early days of Linux, for example, there were specialized professionals and niche technologies that supported the exciting new technology.  Today, Linux is simply part of how IT organizations work.
In a similar fashion, some IT organizations have developed a divergent approach to make backups of their virtual servers.  This is another common mistake.  The divergent approach has festered because of past limitations in backup support from virtualization vendors, the unique skill-set required of backup professionals vs. virtualization professionals, and the historically poor support from major backup vendors. 
While some IT organizations have invested in two separate tools for backup (one for physical servers and virtual servers), IT has consistently asked for a single vendor to manage both environments.  Another ESG report this year found that 74% of companies want a single tool for both physical and virtual backups.

This is because a differing approach to backup leads to inconsistent data management, backup confusion, and even conflict between various IT organizations.  The solution is for IT to bring together the virtualization and backup teams, assign ownership, authority and resources for backup of *both* physical and virtual machines. 

Comments 2 CommentsJump to latest comment

Rockey Wen's picture

It's not the best practice to use traditional methods to backup virtual machines, e.g. install agent on each guest and backup data.  However, in certain scenarios, this might be the best solution not only for the management purposes but also for legacy applications/platforms support.  People more likely to deploy the traditional backup solution rather than hypervisor level backups in the following user cases:
-  Virtual databases farm, e.g. Exchange/SQL farm.  The current hypervisor API based backup approaches still limit to file level backups.  In order to achieve database level restores, backup agents are still required.
-  Physical/virtual mixed environment.  Using different approaches to backup physical and virtual machines will increase management complexity, such as change backup/restore strategy, required training for backup administrators/operators, etc,
-  Not all the guest operating system can be backed up at image level and restore at file level.  

Login to vote
Dimitris Peppas's picture

In a native and modern MS environment , if is relatively up to date, the VSS snapshot functionality allows for the file level restore of database files.
Even Oracle can be put in backup mode before the backup. 

Linux/Solaris X86 are not currently supported on a file level, so those are full image only.

Login to vote