BENEFITS OF CHANGED BLOCK TRACKING AND ACTIVE BLOCK MAPPING Support for the Changed Block Tracking feature

in Quest vRanger Pro 4.5 was critical because many other data backup applications have supported this key feature for a while. Changed Block Tracking allows for much quicker incremental backups as the VMkernel keeps track of all the changed disk blocks so the backup application doesn't have to figure it out on its own. The Active Block Mapping feature is unique to Quest and ensures that data from deleted files inside the operating system are not backed up. All files on a Windows NTFS disk volume have entries in the Master File Table (MFT), which tracks the disk location of files. When a file is deleted, the entry for it in the MFT is given a deleted marker and the disk space that the file resides on is made available to be written on. However, the actual data for the file is still inside the operating system, and the disk block is not zeroed out. At some point, the data in those disk blocks may get overwritten by new data, but until that happens, backing up those disk blocks is a waste of time and resources. With the Active Block Mapping feature, vRanger reads the MFT from outside the virtual machine disk (VMDK) file, which tells it where deleted data, active data and white space (zeroed blocks) is located in NTFS file system. This process takes less than a second and has no overhead. Once this information is retrieved, vRanger is able to map this outside of the VMDK and create a map of only the active disk blocks so deleted and zeroed data can be skipped. But skipping deleted data is not only important for full backups, it's also essential to skip deleted data in incremental and differential backups. In vRanger Pro 4.5, Active Block Mapping and Changed Block Tracking are used in conjunction with each other to achieve this. For instance, although CBT knows nothing of the file system inside the virtual machine (VM), ABM does. Alternately, if data is deleted in between differential and incremental backups, CBT will include deleted data, but ABM can filter out deleted data from CBT. By using ABM and CBT together, backup windows become smaller, the amount of data backed up becomes smaller and deleted data is not processed, compressed, sent or stored. According to Quest, using Active Block Mapping can improve data backup performance by an average of 33% and reduce backup image sizes by an average of 25%. However, there is one caveat to ABM. ABM works by using a binary in the ESX Service Console that understands the VMware VMDK and the Windows NTFS MFT format. Because of this, ABM cannot currently be used with ESXi hosts because it has no Service Console. Quest hopes to develop a way to use ABM with ESXi in a future release. In addition to using ABM to reduce the amount of data backed up, vRanger uses compression on the target repository to reduce the size of the data by an average of 30% to 50%.
BACKING UP VIRTUAL MACHINES

Quest vRanger Pro supports backing up virtual machines on any ESX host from version 3.0.1 to 4.1, and any ESXi host from version 3.5 to version 4.1 can be backed up by

vRanger. However, vRanger cannot be used to back up virtual machines on the free version of ESXi due to restrictions placed by VMware. vRanger has three different methods for backing up virtual machines that can be used depending on the type of host (ESX or ESXi) and your storage configuration. The first method for backing up virtual machines is called Direct to Target and can only be used with ESX hosts. With Direct to Target, the vRanger server arranges the transaction using API calls and SSH commands. Backup data is sent directly from the host to the target repository using the ESX Service Console. This method allows for the best scaling of simultaneous backup jobs, but puts an additional load on the Service Console CPU and network. A custom agent is injected into the Service Console while the backup jobs are running to accommodate this method and is removed once they are completed. When using this method, make sure that your Service Console networking has sufficient bandwidth to handle the additional traffic that will be generated when backups are running. Also, you should create a second Service Console interface on each host connected to an isolated network that contains only your target repositories and vRanger servers. The next two methods are only for ESXi hosts and use a proxy server that sits between the source virtual machine, and target repository; this can be either a physical server or a virtual machine with vRanger installed on it. The proxy method can be done two ways: LAN mode or LAN-free mode. In LAN mode, all data is sent over the network from the ESX/ESXi host to the proxy server and then to the target repository. This method is slower and less efficient as the network traffic goes through the host management network. In LAN-free mode, the vStorage APIs are leveraged so the proxy can connect directly to the storage device of the host, it and does not need to go through the host management network. To use the LANfree method, the proxy server must be directly connected to the storage device which can be either iSCSI or Fibre Channel (FC). NFS storage is not supported for this method -- it isn't a block storage device that can be accessed with the vStorage APIs. Also, the LANfree proxy isn't supported if it's running as a virtual machine because vRanger currently does not support using the hot-add method to mount a disk from one virtual machine to another. Quest plans on supporting the LAN-free method on a VM proxy in a future release. In addition, when running vRanger on a virtual machine you cannot use vRanger to back up the virtual machine on which it is installed. In both proxy methods, the proxy server can become a bottleneck if all traffic is funneled through it. But multiple proxies (vRanger servers) are supported to help alleviate this. However, the vRanger servers must be managed individually because there is currently no centralized management for this. But be careful -- you shouldn't use multiple proxy servers against the same source LUNs. VMware doesn't recommend having more than one Windows server accessing VMFS volumes because they don't have the understanding of the VMFS file system and its special locking mechanisms that ESX and ESXi hosts do.
APPLICATION-CONSISTENT BACKUPS AND VIRTUAL SERVER DATA RESTORATION

To be able to achieve application-consistent backups, vRanger includes a special VSS driver(vzshadow.exe) developed by Vizioncore to address some deficiencies with the VMware VSS implementation built into VMware Tools. The VMware implementation in VMware Tools doesn't work properly with certain operating systems (Windows 2003/2008). This is why Quest developed its own driver that must be manually deployed to each Windows host before you can begin using it. You must also install the Microsoft Visual C++ 2008 Redistributable Package. In addition to providing application-consistent backups for Windows 2003 and 2008, the Vizioncore VSS driver is also required to automatically truncate application logs on Exchange servers. Starting with vSphere 4.1, VMware made changes to its VSS driver and now supports Windows 2003 and 2008 servers so the Vizioncore VSS driver is not required unless you want to truncate Exchange logs. Although vRanger 4.5 delivers application-consistent backups, there are three levels of consistency that can affect the integrity of the data when you try and restore it: 1. Crash consistent. This is the equivalent of pulling the power plug on a server. When this happens, the operating system and applications running on the server have no chance to save any data in memory or write any pending data/transactions to disk. Therefore, some data from open applications restored in this manner can become corrupt. 2. File system consistent. This is achieved by quiescing the operating system, which ensures any pending file writes are written to disk. This method uses the VMware Sync driver in VMware Tools and is not application-aware, but does help ensure the integrity of any operating system or application files to help ensure successful restores. 3. Application-consistent. This is achieved by communicating with applications so they can pause and complete any pending transactions to ensure the application data is in a good state to be backed up. This method uses the Microsoft VSS driver in VMware Tools to help ensure that transactional application data is not corrupted at all when restored. It's important that VSS is able to achieve application-consistent backups on transactional applications like Microsoft SQL Server and Exchange. Once the application is quiesced, a snapshot of the virtual disk is taken and the backup begins. But in order to achieve true application consistent backups, the following conditions must be met:

The application (i.e., Exchange) running inside the virtual machine must be written as a VSS writer. The backup application (i.e., vRanger) must be written as a VSS requestor. The VSS implementation present in the platform (i.e., VMware) must be implemented correctly.

Individual file-level restores are only supported for Windows VMs; Linux and other operating systems are not supported. But this doesn't mean that restoring individual files on non-Windows guests is not possible. You can restore the virtual machine to another

datastore/directory and either attach the backed up virtual machine's virtual disk to the original VM and copy the file off of it, or use another helper VM that is able to read the file system of the backed up VM and then copy the file to the original VM.
INSTALLING VRANGER PRO

The installation of vRanger Pro is pretty straightforward. vRanger comes with SQL Express and can be installed on a physical server or virtual machine running any of the latest Windows operating systems, but it requires dual CPUs, 1 GB of RAM and at least 4 GB of free disk space. For standard bare-metal backup and restores, vRanger supports any virtual machine guest operating system that VMware supports. The .NET 3.5 framework is required and automatically installed, and if you choose SQL Express, 2005 is also installed. You can also use an existing SQL Server 2005/2008. The installation will automatically set up the database for you with minimal input such as the db login credentials. Once the installation completes, a startup wizard will walk you through setting up initial configuration information, including the vCenter Server name/credentials, host information, email information and target repositories. Be sure to click the "Save" button after entering any information before clicking "Next" to go to the next section, otherwise the information will not be saved.
CONFIGURING REPOSITORIES IN VRANGER PRO

A repository is simply a directory on a supported file system that vRanger uses to store backup images. The file structure of a repository consists of directories and subdirectories for full and incremental backups that contain metadata files in XML format. The metadata files contain data about each backup, as well as backup image files with .var extensions. After creating repositories, you should manage them through vRanger; never directly interact with them through the OS file system. You can use vRanger in conjunction with tape backup software to sweep the disk repository to tape for long-term and offsite storage. This works by leveraging PowerShell scripts (called by precommands) set up in the tape backup job, which launches a special vRanger on-demand job that performs an incremental backup to a dedicated repository. The PowerShell scripts loop while the backup is running. Once the vRanger backup completes, the script exits, allowing the tape backup job to begin to back up the repository to tape. When configuring repositories for backed up data, you should use physical hardware such as a Windows/Linux server or a network-attached storage (NAS) device that supports either CIFS or SFTP. It is not recommended to use a virtual machine as a target repository, otherwise the overhead of writing all your data might saturate the host and target storage device, which can affect the performance of other virtual machines. A single backup can output up to 60 MBps of data, so having a dedicated and isolated target repository will ensure that your hosts and VMs are not starved for resources when backups are running. In addition, be sure to use higher performance disk drives on the physical hardware device for your repositories. Hard disks are mechanical and often the first resource

bottleneck encountered on a server. Because of this, try and use faster SAS drives instead of slower SATA drives, higher RPM drives (i.e., 15K) and RAID groups that have many spindles; that way the I/O can be written to multiple drives at once and you will get faster backups and shorter backup windows. Also, keep in mind that the disk partition type used for your repositories can affect the maximum size of the repository. A standard basic disk volume with an MBR partition for Windows servers cannot exceed 2 TB in size, limiting the size of the repository. Dynamic disks can be created from basic disks by converting them and support file sizes up to 64 TB, greatly increasing the size of the repository that you can have. Furthermore, a GPT partition type can be used instead of an MBR partition, which can give you disks up to 256 TB in size.
OPTIONS FOR CREATING BACKUP JOBS IN VRANGER PRO

Once your repositories and inventory are set up you can start configuring backup jobs. You can either choose a preconfigured template or customize your own options for creating your backup jobs. The three default template types are SQL Server, File Server and Workstation. They all have predefined features selected based on the job type. These templates are not editable in vRanger (they can be edited by modifying .xml files) and you cannot create your own templates. If you don't want to follow a template, you can also choose from eight basic options you can when creating backup jobs:

Backup power-on virtual machines only Check destination for free space Compress backup files Update notes with latest backup results Enable guest quiescing Enable active block mapping Use fiber or iSCSI Perform network backup on fiber or iSCSI failure

In most cases, you will want most of the options enabled. Guest quiescing is important to ensure file system and application consistent backups. Compression and active block mapping can help you reduce the amount of space on your target repositories. The "Use fiber or iSCSI" option is for LAN-free mode on ESXi. The "perform network backup on fiber" or "iSCSI failure option" switches from LAN-free mode to LAN mode if there is a failure connecting directly to the storage device. Note the changed block tracking feature is not set on backup jobs but must be enabled individually on each virtual machine by right clicking on a VM in the "my inventory" view and choosing "Enable Change Tracking". This is a one-time process and takes effect on all backups made on the VM; to enable this on multiple VMs simultaneously, you can utilize PowerShell and this cmdlet. In order to achieve the best possible backup performance in your data backup system, it is absolutely critical to architect and integrate your vRanger Pro installation correctly for your environment. Every environment is different and backup requirements can vary, so be sure to spend some time researching your requirements, sizing your environment

correctly and properly configuring vRanger jobs and repositories. If you fail in any one area, you may create a bottleneck or limitation that can greatly degrade or prevent your ability to properly backup and restore data. To help you understand vRanger and how to implement it in your backup environment, Quest has created a deployment guide for vRanger Pro. Be sure to read it, even if you have deployed vRanger already, because it will provide you with many additional tips and best practices. In addition, the vCommunity for vRanger Pro is a great place to go to get information and post questions you might come across when using it.