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

Hyper-V 2012 and Backup Exec 2012: The History of Support

Created: 19 Jul 2012 • Updated: 28 May 2014 • 5 comments
Scott_Baker's picture
+6 10 Votes
Login to vote

Hyper-V 2012 and Backup Exec 2012

As I mentioned in last week’s entry – I’m going take a look at where Backup Exec has been in support of Microsoft’s virtual platform; from Microsoft Virtual Server to Hyper-V. It started with Backup Exec 12.5 which was released in October of 2008 and the Backup Exec Agent for Microsoft Virtual Servers. It supported Microsoft Virtual Server 2005 R2 SP1 or later as well as Hyper-V 2008.

That original agent packed quite a bit of functionality:

  1. Host-based backup and recovery of any virtual machine regardless of the operating system.
  2. Backup and recovery of the Virtual Server and Hyper-V configuration settings.
  3. Redirected restore of a virtual machine to an alternate Virtual Server or Hyper-V host.
  4. Granular recovery of individual files and folders from the image backup into the virtual machine.

Much of this was possible by taking advantage of the Microsoft VSS provider to quiesce the Virtual Server which would in turn quiesce the virtual machines; Backup Exec was fully integrated with Virtual Server and Hyper-V to perform host-based backups. From the very first release there has NEVER been a requirement to install the Backup Exec Agent for Windows on a virtual machine for protection; this fact seems to be lost on a lot of people so it’s worth saying again – Backup Exec does not require an “agent” of to be running in a virtual machine to protect it.

Backup Exec 2010 was originally released in February of 2010; at that time support for Microsoft Virtual Server was dropped to concentrate on Hyper-V with new features such as Cluster Share Volumes. This Backup Exec 2010 Agent for Hyper-V included all of the features of the original agent plus some new features that at the time were unmatched by other data protection solutions.

New features of the Backup Exec 2010 Agent for Hyper-V included:

  1. The ability to backup a virtual machine that moves between clustered Hyper-V hosts.
  2. Support for Cluster Shared Volumes (CSV’s).
  3. Granular recovery of Exchange, Active Directory and SQL databases without performing an application backup.

The addition of support for virtual machines that move between clustered Hyper-V hosts takes advantage of a Backup Exec feature called Dynamic Inclusion. Dynamic Inclusion allows you to select the root Microsoft Hyper-V host node which will select all virtual machines present at backup time for protection. But Dynamic Inclusion alone isn’t enough to provide the vigorous support necessary to protect a Hyper-V cluster where virtual machines could migrate from one cluster node to the other. To make this possible Backup Exec also added support for CSV’s which are volumes shared between two Hyper-V cluster nodes allowing simultaneous access. A CSV and Windows Failover Clustering allow a Hyper-V cluster to quickly pass management of a virtual machine from one host to the other; a process called Live Migration. Combining support for CSV’s and Live Migration provided Backup Exec users with a robust solution for protecting an enterprise class Hyper-V environment.

Backup Exec 2010 also delivered AppGRT. AppGRT permits the recovery of Exchange, Active Directory and SQL data from a virtual machine without ever running an application level backup of any of those applications. This means that if you have virtualized your Exchange server then you no longer need to run an Exchange backup. When the backup starts Backup Exec will recognize that Exchange is installed and will query Exchange for the metadata associated with the Exchange Information Store. This process takes a very short time, usually seconds, and can be thought of as getting the “blueprint” of a building. This blueprint allows Backup Exec to mount the virtual machines VHD(s) and access the files that make up an Exchange Information Store. By accessing these files Backup Exec can interrogate the Exchange Information Store as a whole or drill down into each level of the Information Store.  This went all the way to an individual email, allowing you to select an item for restore every step of the way. Backup Exec will also truncate Exchange transaction logs to complete the full cycle of support. This same level of application data recovery is possible with Active Directory making it possible to restore data points as granular as Active Directory Object Properties as well as recovering SQL Databases.

AppGRT for your virtual machines means you no longer have to run application specific backups of those supported applications. So you no longer need to run an Exchange, SQL or Active Directory backup to protect and recover data for those applications. AppGRT and file GRT for virtual machines saves you time by protecting the entire guest machine in a single pass image-based backup and allow multiple ways to recover your data.

Moving on to Backup Exec 2012 and the latest enhancements to the Agent for Hyper-V.

  1. AppGRT support for SharePoint
  2. Incremental backup support for Hyper-V, something not even Microsoft has delivered.
  3. Support for block optimization.
  4. Deduplication of data inside a virtual machine.

Just as I explained how Backup Exec 2010 can a allow you to recover Exchange, Active Directory and SQL data without ever running an application level backup, the same is now true for SharePoint in Backup Exec 2012.

Another big enhancement in Backup Exec 2012 is the addition of Incremental backups of Hyper-V virtual machines. This may not seem like a big deal when you first read it but it is since Microsoft doesn’t even have an API that allows incremental backups for Hyper-V virtual machines and if you’re reading this blog I expect that you know the benefit of an incremental backup over a full backup.

Next is support for block optimization which tells Backup Exec exactly what blocks are occupied with active data. If a block doesn’t have data in it then why back it up? So this saves time and space in backup processing.

Lastly is the ability to look inside a Hyper-V virtual machine, look inside the VHD and identify each file and its binary content. Knowing this information allows Backup Exec to deduplicate the data inside the VHD at the same rates and the same method as physical machine backups. This allows for deduplication across the entire virtual and physical environment at rates no other software only vendor can claim.

If we combine these last three enhancements: 1) incremental backups, 2) block optimization and 3) internal VHD content deduplication Backup Exec provides superb backup performance and huge storage savings all the while letting you recover every virtual machine, individual files and folders and application data for Exchange, Active Directory, SQL and SharePoint.  This is a powerful single solution that encompasses not only your Hyper-V environment but your physical environment as well and I’m betting most of you still have some physical assets still in operation.

Now comes the part that has allowed some competitors that also support virtual environments to generate FUD. By the way FUD stands for fear, uncertainty and doubt for those of you who may not have heard of that term. In order to perform AppGRT as I describe in the paragraphs above there must be a process running in the virtual machine that recognizes the presence of Exchange, Active Directory, SQL and SharePoint and that process is the Backup Exec Agent for Windows.

This is where the FUD begins. Our competitors would have you believe an agent in the virtual machine is bad and that it means Backup Exec isn’t “optimized” for a virtual environment and is a “legacy” backup solution; that’s not true and that’s the definition of FUD. By equating the presence of an agent in a virtual machine with the term “legacy” our competitors are attempting to convince you the architecture is old and outdated. Again, it’s not true. Having the agent in the virtual machine makes it possible to do things these competitors can’t do. Some questions to ask yourself:

  • Can your virtual backup solution recover data without powering on the virtual machines from the backup destination using precious virtual host resources?
  • Does your virtual backup solution allow you to search for file and application data for restore operations and restore that data directly from the search results window?
  • Does your virtual backup solution support the protection of physical assets as well or do you have to spend money to purchase and manage multiple backup solutions?
  • Does your virtual backup solution support tape archiving of your backup images?

Backup Exec has been supporting virtual environments since those competitor applications were wearing diapers. Some of these applications like to say they are “agentless” when in fact they’re not. If there’s ever any doubt run a filesystem monitoring tool that will audit the creation and deletion of files on the virtual machines during backup and find out for yourself just how “agentless” these competitive backup solutions really are. By the way, if you only want to restore an entire virtual machine, VHD or individual files and folders then Backup Exec does not require an agent in the virtual machine during backup and there are no agent executables injected under the covers without your knowledge.

It seems I’ve gotten off topic as I gave into a rant in the prior paragraph, so I digress.

When the Backup Exec Agent for Windows is installed in a virtual machine and a backup is taken via the Hyper-V host, the agent sends only the application metadata…recall that the application metadata is the “blueprint” that I described previously and that this process takes mere seconds to complete. The agent also coordinates with the virtualized application to make it possible to truncate transaction logs. However, no backup data is ever sent from the agent inside the virtual machine UNLESS you treat the virtual machine as a physical machine and run backups by selecting these virtual machines outside of the Hyper-V host (Tip: don’t treat a virtual machine like a physical machine, always select the virtual machine through the Hyper-V host).

So…I’ve gone a lot further this week than I had planned but I think I covered quite a bit of ground and hopefully you understand the history of the Backup Exec Agent for Hyper-V. Next week I’m going to start looking ahead at what we see “coming soon to a Hyper-V server near you” with Hyper-V 2012.

Blog Entry Filed Under: