on 11-11-2013 09:50 AM
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.
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.
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.
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.
Phase 2:
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.
Note:
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:
Once this phase is completed, the normal VERIFY job is executed and the status is updated in the database.
Kind Regards,
S
Good share
Good indepth info on AppGRT backup process !
thanks guys!
Very good explaination about APP GRT. This is just something I was looking for from a very long time.
Thank you Vishal for sharing this ..
Thank for explaination about APP GRT.
Very valuable information. Thank you for sharing. :)
Thank you for sharing. I now have a better understanding.