Chat now with support
Chat with Support

Rapid Recovery 6.6 - 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 Credentials Vault 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

Manually truncating Oracle database logs

This procedure is only appropriate for Oracle database severs protected on your Core.

When protecting an Oracle database in ARCHIVELOG mode, substantial log files accumulate on the local database server. To support the protection of Oracle databases in Rapid Recovery, you can enable a nightly job to truncate Oracle logs.

NOTE: Log truncation for Oracle is disabled by default.

For any protected Oracle server, you can also manually truncate Oracle database logs on demand at any time, as described in this topic. Truncating will delete the logs from the local server. In each recovery point saved to your repository, the database logs persist to reflect the state of the database at the time the backup snapshot was captured.

Complete the steps in this procedure to manually truncate Oracle log files.

  1. Navigate to the protected Oracle machine in the Rapid Recovery Core Console.
    The Summary page displays for the protected machine.
  2. On the Summary page, scroll down to the Oracle Server Information pane.
  3. In the table row representing the Oracle database instance for which you want to truncate logs, click the [More options] (More options) drop-down list and select Force Log Truncation.
    The Force Log Truncation dialog box displays.
  4. If you want to delete all of the Oracle logs from the local database server, from the Deletion policy drop-down menu, select Automatic, and then click Force.
    A log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
  5. If you want to delete all of the locally stored logs from the Oracle server (copies of which are stored in the most recent recovery point), do the following:
    1. From the Deletion policy drop-down menu, select Keep newest.
    2. In the Keep logs for text field, enter a number, and then from the time period drop-down menu, select the relevant a period of time (days, weeks, months, or years).
    3. Click Force.
      A log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
  6. If you want to keep a specific number of Oracle log files, and truncate the remaining logs, then do the following:
    1. From the Deletion policy drop-down menu, select Keep specified number.
    2. In the Number of archive files text field, enter a number representing the amount of the newest database logs to retain.
    3. Click Force.
    A log truncation job queues. If the system is not busy, the job executes immediately and the logs are truncated.
  7. If you want to truncate logs for other database instances on this server, repeat step 3 through step 6 for each relevant database listed in the Oracle Server Information pane.

About managing Exchange and SQL servers in Rapid Recovery Core

Options specific to Exchange Server and SQL Server appear in the Rapid Recovery Core Console only when an instance of the software and related files are detected on protected servers. In those cases, additional options are available when you select the protected machine in the Core Console.

For example, if you select a protected Exchange server in the left navigation menu, then the menu options that appear for that protected machine include an Exchange drop-down menu option.

If you select a protected SQL server in the left navigation menu, then the menu options that appear for that protected machine include a SQL drop-down menu.

While these options may work differently, there is some commonality. Functions you can accomplish for protected Exchange and SQL servers (and for no other protected machines) include:

  • Forcing server log truncation. Both SQL servers and Exchange servers include server logs. The process of truncating SQL logs identifies available space on the server. When you truncate logs for an Exchange server, in addition to identifying the available space, the process frees up more space on the server.
  • Setting credentials for the relevant server. Exchange servers allow you to set credentials for the protected machine on the Summary page for the protected server. SQL servers allow you to set credentials for a single protected SQL Server machine, or to set default credentials for all protected SQL servers.
  • Viewing status for checks on recovery points from Exchange Server or SQL Server. Recovery points captured from a protected SQL or Exchange server have corresponding color status indicators. These colors indicate the success or failure of various checks relevant for SQL servers or Exchange servers.

This section includes the following topics specific to managing protected machines that use Exchange Server or SQL Server:

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.6 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.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating