Backup Exec 2012 Hyper V /VMware Application GRT demystified.
Before we move ahead to understand how Virtual Application GRT works, let me give a short description on How application GRT Works.
In general when an application (exchange, AD, SharePoint) server is backed up with GRT enabled, there are two distinct phases of the backup.
1. Data moved from application server to the Backup Exec media server
2. Data is cracked open and analyzed for content, the same is being recorded and and saved in the catalogs.(In a layman’s term)
When the target media is disk storage, the data moves from the application server (The server which is being backed up.) to an IMG folder on the media server, data on the media server is cracked open and analyzed for content to build the catalogs.
Whereas when the target media is tape device, the data moves from the application server to the tape. , the data residing in snapshot on the application server is cracked open and analyzed for content.
For example, the backup of an Exchange server would result in an IMG folder containing files similar to those listed below.
You can see the Exchange LOG files and the EDB file. Also note, the PDI.TXT and PDI_STRM.BIN files , these two files contain information about the structure of the Exchange Info-Store, for example, where the files are located on the Exchange server, the various file permissions, etc…
There is an IMG folder created for each application entity that is backed up. For example, there would be an IMG folder for each Exchange Info-Store, one for each instance of SQL for AppGRT, one for Active Directory and one for each SharePoint item (ie: DLE), provided that item supports GRT.
Application GRT Backup, with Virtualization.(using VMware or Hyper-V):
Now talking about the Virtual agent backup process, a virtual agent like VMware /Hyper-V must drive the application agent like SQL Agent, Exchange Agent, and Active Directory Recovery Agent (ADRO) etc. through its phases to build its GRT view.
In order to gather all of the META DATA (necessary application information and status from the virtual machine), following conditions needs to be fulfilled.
- Remote agent of the identical version of Backup Exec must be installed and running on it.
- All of the application’s services must be up and running.
The virtual backup must drive the application agent through its phase of META DATA collection before the VHD / VMDK are transferred to the media server.
The backup process goes through the following steps, before the snapshot of the Virtual machine is taken.
- . Establish a connection from the media server(bengine) to the Backup Exec Remote Agent (beremote) running inside of the guest Virtual machine, selected to be backed up.
- . Logon to the guest with the provided credentials.
- . Request the Backup Exec Remote Agent running inside the Guest Virtual Machine to :
a. take the snapshot of the necessary guest drives using the available VSS framework.
b. Drive each application agent through a pseudo Backup, so that only Meta data of the backup is collected required for the GRT Process.
c. Delete the snapshot of the Guest Machine Drives.
- . Return status information to the Backup Exec Media Server.
The process discussed above takes place much before the snapshot of the virtual machine is taken by the respective virtual agent.(VMware or Hyper-V).
And the UI displays “Preprocessing” during this stage of the virtual backup.
During this phase, a small amount of data is generated and is stored inside the guest virtual machine.
Thus when the VHD / VMDK files are transferred to the media server, this data is transferred as well.
And it also provides additional advantage that this data is always kept in synch with the application’s data stored inside of the VHD / VMDK files.
This data is stored in the LOGS directory inside the guest and is deleted from the gust machine after a successful snapshot.
The credentials used to logon to the guest are set for the VM resource under the virtual host.
It is not possible to set application specific credentials.
In other words, if you have an SQL instance that uses SQL authentication or if the application implements access permissions such that the user is unable to access the application, you will be unable to perform Virt-App GRT for the application.
If all of four of the application GRT options are disabled (ie: unchecked) the entire metadata collection process is skipped.
Disabling an application GRT option means that application will be silently skipped during the metadata collection process inside of the guest.
The entire metadata process is silently skipped if the VM is powered off.
Once the VHD / VMDK files have been transferred to the media server, GRT processing begins. GRT processing in this context means file and folder GRT processing as well as Virt-App GRT processing.
In order to perform any sort of GRT processing, the VHD / VMDK files must be mounted so that they can be scanned for content and have that content added to the catalogs.
For VMware, the VMDKs are always mounted on the ESX server.(data store.)
For Hyper-V, the VHDs that are mounted for GRT operations depend on the target media.(Tape or disk.)
If the target is disk, the VHDs that are mounted are the VHDs that reside on the media server.
If the target is tape, the VHDs that are mounted are the VHDs that reside in the snapshot on the Hyper-V host.
Once the VHD / VMDK files are mounted, following things are done:
- Registry information on the mounted guest are queried for the drive identification, (e.g assigned drive letter, boot records and so on)
- After the VHD / VMDK files are mounted and the driver letter mapping determined, the “guest” volumes appear as “local” volumes. So for file and folder GRT, the NTFS doesn’t actually backup any data, the only thing that happens for the “guest” volumes is that every file in the VHD / VMDK gets “cataloged” under the drive letter used by the guest.
- Once file and folder GRT is completed, Virt-App GRT processing is started.
- So processing starts with application discovery.
- PDI.TXT and PDI_STRM.BIN files inside the VHD / VMDK (These were created during the phase 1, as discussed above.) are opened and analyzed, the locations of the files inside of the VHD / VMDK files are recorded to be used while creating the soft links.
- In this case the links are Windows symbolic links, but depending on the Operating System and virtualization type (ie: Hyper-V vs. VMware) the links might be VLINK generated by VFF.
- The application agent catalogs everything In other words, regardless of what the application agent supports for restore browse, all of the data in the restore browse view is coming out of the catalogs.
Once this phase is completed, the normal VERIFY job is executed and the status is updated in the database.
- With regards to restores, the VHD / VMDK files are mounted, but not all of the VHD / VMDK files may need to be mounted. If the VM has 2 VHD / VMDK files and the “item” to be restore is in the first VHD / VMDK, then only the first VHD / VMDK is mounted.