Chatee ahora con Soporte
Chat con el soporte

Rapid Recovery 6.9 - User Guide

Introduction to Rapid Recovery The Core Console Repositories Core settings Protecting machines
About protecting machines with Rapid Recovery Understanding the Rapid Recovery Agent software installer Deploying Agent to multiple machines simultaneously from the Core Console Using the Deploy Agent Software Wizard to deploy to one or more machines Modifying deploy settings Understanding protection schedules Protecting a machine About protecting multiple machines Enabling application support Settings and functions for protected Exchange servers Settings and functions for protected SQL servers
Managing protected machines Snapshots and recovery points Managing privacy Encryption Authentication Replication Events Reporting VM export Restoring data Bare metal restore
About bare metal restore Differences in bare metal restore for Windows and Linux machines Understanding boot CD creation for Windows machines Managing a Linux boot image Performing a bare metal restore using the Restore Machine Wizard Using the Universal Recovery Console for a BMR Performing a bare metal restore for Linux machines Verifying a bare metal restore
Managing aging data Archiving Cloud accounts Core Console references REST APIs Glossary

About protecting server clusters

In Rapid Recovery, server cluster protection is associated with the Rapid Recovery protected machines installed on individual cluster nodes (that is, individual machines in the cluster) and the Rapid Recovery Core, which protects those machines, all as if they were one composite machine.

You can easily configure a Rapid Recovery Core to protect and manage a cluster. In the Core Console, a cluster is organized as a separate entity, which acts as a container that includes the related nodes. For example, in the left navigation area, under the Protected Machines menu, protected clusters are listed. Directly below each cluster, the associated individual nodes or agent machines appear. Each of these is a protected machine on which the Rapid Recovery Agent software is installed. If you click on the cluster, the Summary page for the cluster appears in the Core Console.

At the Core and cluster levels, you can view information about the cluster, such as the list of related nodes and shared volumes. When showing information for a cluster in the Core Console, you can click Protected Nodes in the top navigation menu to view a summary table of individual nodes in the cluster. From that summary table, for each node, you can perform functions such as forcing a snapshot; performing a one-time export or setting up virtual standby; mounting or viewing recovery points; restoring from a recovery point; converting the cluster node to its own protected machine; or removing the node from protection. If the node is an Exchange or SQL Server, you will also see the option to truncate logs.

At the cluster level, you can also view corresponding Exchange and SQL cluster metadata for the nodes in the cluster. You can specify settings for the entire cluster and the shared volumes in that cluster.

If you click on any node in the cluster from the left navigation menu, the information displayed in the Core Console is specific to that node of the cluster. Here you can view information specific to that node, or configure settings just for that node.

For more information about CSV clusters, see topics "Supported applications and cluster types" and "Support for Cluster-Shared Volumes" in the Rapid Recovery System Requirements Guide.

Understanding Rapid Snap for Virtual

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.

Caution: Quest recommends that you limit initiating agentless protection to no more than 200 VMs at once. Do not select more than 200 VMs when using the Protect Multiple Machines Wizard. Attempting to start protection of more than 200 VMs results in slow UI performance. There is no limit to how many VMs a Core can agentlessly protect over time. For example, you could protect 200 VMs today and another 200 VMs tomorrow.

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 Esxi appears differently than the icon on an ESXi VM protected using Rapid Recovery Agent[Protected machine].

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

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 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 System Requirements Guide. For more information, see the topic "Rapid Recovery release 6.9 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.

NOTE: Rapid Recovery supports the VHDx disk file format. It does not support the VHD format.

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.

NOTE: For best performance, it is recommended that the maximum concurrent transfers for the Hyper-V host or node be set to 1, which is the default setting.

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.

NOTE: Application support does not apply to applications installed on Linux VMs.

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.

Benefits of installing hypervisor tools for agentless protection

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:

Table 39: Backup type conditions for VMs
Hypervisor Tool VM Powered On Backup Type
Not installed Yes Crash-consistent
Not installed No (dirty shut-down) Crash-consistent
Not installed No (clean shut-down) Application-consistent
Installed Yes Application-consistent
Installed No (dirty shut-down) Crash-consistent
Installed No (clean shut-down) Application-consistent

Understanding crash-consistent and application-consistent backups

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.
Documentos relacionados

The document was helpful.

Seleccionar calificación

I easily found the information I needed.

Seleccionar calificación