Rapid Recovery 6.3 - User Guide

The Rapid Snap for Virtual feature of Rapid Recovery is also known as agentless protection, because you can protect virtual machines (VMs) in your Core without installing the Rapid Recovery Agent on every VM.

Whether adding protection for a single machine agentlessly or multiple machines simultaneously, the tool to access agentless protection is the Protect Multiple Machines wizard.

Protecting VMware vCenter/ESXi VMs

Rapid Recovery lets you protect vCenter/ESXi VMs without installing the Rapid Recovery Agent on the VM or ESXi host, resulting in fully agentless protection. Rapid Recovery uses the ESXi client and the application program interface (API) native to VMware to detect and protect selected VMs on a single host. The Rapid Recovery Core then communicates with the virtual machine disk (VMDK) to determine the necessary details of the protected volumes. Because Rapid Recovery creates recovery points based on volumes, not VMDKs, each volume can be separately mounted, restored, and exported.

Rapid Recovery does not technically protect a VMware vCenter/ESXi hypervisor host. When you select a vCenter/ESXi host using the Protect Multiple Machines wizard, you add the host as a parent entity on your Rapid Recovery Core. No data files or data from the actual host are included in snapshots on the Core. However, the VM guests on the host can be protected. The protected VMs are represented in the Core GUI as children under the parent host. If you select agentless protection for ESXi VMs, the icon for the protected VM appears differently than the icon on an ESXi VM protected using Rapid Recovery Agent.

When VMware Tools are installed, agentless protection uses VMware Changed Block Tracking (CBT) to reduce the time needed for incremental snapshots. CBT determines which blocks changed in the VMDK file, letting Rapid Recovery back up only the portions of the disk that have changed since the last snapshot. This backup method often results in shorter backup operations and reduced resource consumption on network and storage elements.

There are multiple benefits to using agentless protection. Some of the most useful attributes include the following characteristics:

• No additional software is required on the host machine.
• Agentless protection lets you opt to automatically protect new VMs added to the ESXi host or Hyper-V host.
• A restart is not required during the protection process.
• Credentials are not required for each individual VM.
• Agentless protection lets you protect a VM even if it is powered off.
• Agentless protection lets you restore to disks.
• Agentless protection supports all guest operating systems.
• If you associate a guest VM with its protected parent hypervisor host, an Enterprise license is not consumed when protecting the VM in your Core.
• You can optionally protect and collect metadata for SQL Server and Exchange.
• The Core (not the Agent) can perform attachability checks, log truncation, and mountabillity checks on recovery points captured from protected
  Oracle,
  SQL and Exchange servers.
• Agentless protection lets you export dynamic disks or volumes.

  NOTE: If dynamic volumes are complex (striped, mirrored, spanned, or RAID), they export as disk images and parse into volumes after the export operation completes on the exported VM.

While there are many reasons to use agentless protection for ESXi VMs, opt for the protection method that best suits your environments and business needs. Along with the previously mentioned benefits, there are also the following considerations to keep in mind when choosing agentless protection:

• Agentless protection of Oracle database servers does not gather Oracle-related metadata. While files and the operating system are backed up in snapshots, no Oracle-related features are supported. For Oracle database application support, protect your server using Rapid Recovery Agent.
• Agentless protection does not support protection of dynamic volumes (for example, spanned, striped, mirrored, or RAID volumes) at the volume level. It protects them at the disk level.
• Agentless protection does not support Live Recovery. For more information about this feature, see Understanding Live Recovery.
• During the restore process of a single volume to the protected VM, the VM is automatically restarted.
• Agentless protection does not display the actual amount of space used on a VM if the virtual disk type is thick provision eager zeroed.

If you choose to use agentless protection for your ESXi VMs, the host must meet the following minimum requirements for agentless protection to be successful.

• The host machine must be running ESXi version 5.0.0 build 623860 or later.
• The host machine must meet the minimum system requirements stated in the Rapid Recovery 6.3 System Requirements Guide.
• For volume-level protection, VMDKs must include either Master Boot Record (MBR) partition tables or GUID partition tables (GPTs). VMDKs without these partition tables are protected as whole disks rather than as individual volumes.
• Each VMware virtual machine must have VMware Tools installed to ensure snapshot consistency.

Protecting VMs on Hyper-V servers and clusters

To protect Hyper-V VMs agentlessly, you do not need to install the Rapid Recovery Agent on each VM. You need only install it on the host machine or cluster nodes. The Agent protects the virtual hard disk on the host and converts any changes to the hard disk files to a volume image or disk image, depending on the file system. A new driver provides file-level support for VMs on hosts and on cluster-shared volumes (CSVs).

Agentless support for Hyper-V is determined by the operating system on the host. A complete list of operating systems, and Rapid Recovery components supported for each, is maintained in the Rapid Recovery 6.3 System Requirements Guide. For more information, see the topic "Rapid Recovery release 6.3 operating system installation and compatibility matrix" in that document.

Quest recommends that Hyper-V Integration Services be installed on virtual machines (VMs) you want to protect on Hyper-V hosts. When Hyper-V Integration Services are installed on a VM using a Windows OS, the backups that the Rapid Recovery Core captures use Microsoft VSS. This provides the capacity for application-consistent backups. For information on the behavior of agentless VMs with or without Hyper-V Integration Services, see Benefits of installing hypervisor tools for agentless protection and also Understanding crash-consistent and application-consistent backups.

For protecting VMs on a CSV, the Rapid Recovery Agentand driver must be installed on each cluster node using the auto deployment feature in the Protect Multiple Machines Wizard. From the nodes, the Agent can protect all VMs operating on CSVs by creating two types of changes for every file. The first type of change is saved only before or after a snapshot or clean system restart. The second type of change resides on the disk, which makes an incremental snapshot available even if there is a power failure or dirty shutdown. The Agent installed on the node merges all of the changes into one before transferring the data.

When a host or node is running, Rapid Recovery creates a backup. If the host is not running, no backup can be created; however, if one of the nodes is not running, then Rapid Recovery can continue taking snapshots of the VMs on the cluster.

Agentless Hyper-V protection has many of the same capabilities as traditional protection where the Agent is installed on every VM, including:

• Archiving
• Recovery point integrity checks
• Mounting recovery points
• Auto discovery of new VMs (unique to agentless protection)
• Protecting SQL and Exchange servers and collecting their metadata
• Performing Exchange mountability checks
• Performing SQL attachability checks
• Replication
• Restoring VMs, including restoring to CSVs, or to CIF shared folders
• Restoring files in a guest VHDX format
• Rollup
• Virtual export to Hyper-V VMs and other hypervisors, including ESXi, VMware Workstation, and VirtualBox

However, there are limitations to consider when choosing agentless Hyper-V protection. Capabilities that are not performed include:

• Live Recovery
• Restoring VMs on CIFS using VHD format
• Restoring files in a guest VHD (.vhd) format
• Restoring files in a guest VHD Set (.vhds) format

  NOTE: For an application-consistent snapshot, you must have the SCSI Controller installed on each VM. Without this controller, the result is always a crash-consistent snapshot.

Application support

Rapid Snap for Virtual lets you enable agentless protection of SQL Server and Exchange applications running on Hyper-V and ESXi VMs. This optional capability is available for VMs running Windows operating systems.

After you enable application support, application metadata displays on the Summary page for the VM, as does an icon beside the VM name on the Machines page. If there is an error preventing healthy application support, the icon changes from green to red.

Before you opt to agentlessly protect an SQL Server or Exchange Server, take note of the following considerations:

• To protect the application, the VM must be powered on. The Core does not retrieve metadata from machines that are off.
• VMware Tools or Hyper-V Integration Services utilities must be installed on VMs you want to protect.
• On a VM that has both Exchange Server and SQL Server installed, there is no ability to truncate the logs separately. If both applications are installed, then the logs truncate together.
• SQL Server attachability checks are available only on the Core and cannot be conducted on the protected machine.
• To run log truncation on an ESXi VM, the host must use ESXi version 6.5 or later.

When protecting virtual machines (VMs) without using the Rapid Recovery Agent Agent, Quest recommends installing VMware Tools on protected VMs on vSphere or ESXi hosts. In the same way, Quest recommends installing Hyper-V Integration Services on VMs you want to protect on Hyper-V hosts.

Installing these native hypervisor utilities lets Rapid Recovery take full advantage of Microsoft Volume Shadow Copy Services (VSS) functionality.

When these utilities are installed on VMs running Windows operating systems, the backups that the Rapid Recovery Core captures can also use VSS. When these tools are not installed, Rapid Recovery still collects snapshots, but only in a crash-consistent state. For more information, see Understanding crash-consistent and application-consistent backups.

The following conditions apply based on whether VMware Tools or Hyper-V Integration Services are installed and on the powered-on state of the VM:

When protecting virtual machines agentlessly using the Rapid Snap for Virtual feature, the data in the backup snapshots you capture can be in one of two states:

• Crash-consistent. At minimum, all agentless backups captured by the Rapid Recovery Core are crash-consistent. The backup is a snapshot in time of all the data and operating system files on each protected volume, at the time those files were captured. If you restore from a crash-consistent recovery point, the VM OS starts and can read and understand the file system, and all files in it.

  If you recover a transactional application from a crash-consistent state, the database returns to the last valid state. That most recent valid state may be from the time of the crash, or it may be from earlier than the crash. If it is from earlier, then the database must roll forward some work to make the data files match the information in the logs. This process takes some time when you first open the database, which causes a delay when starting up the machine.

• Application-consistent. Application-consistent backups use Microsoft's Volume Shadow Copy Service (VSS) to ensure the consistency of application data when a shadow copy is created. Using VSS writers, pending input/output operations are completed and log files committed prior to snapshots being captured. As a result, if you restore from an application-consistent recovery point, the VM OS starts and can read and understand the file system. Additionally, files for transactional applications such as SQL Server or Exchange are in a consistent state. For example, SQL Server logs match the data files, and the database opens quickly without needing any repairs.