Chat now with support
Tchattez avec un ingénieur du support

Rapid Recovery 6.3 - User Guide

Introduction to Rapid Recovery The Core Console Repositories Core settings Managing privacy Encryption 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 Credentials Vault Snapshots and recovery points Replication Events Reporting VM export Restoring data Bare metal restore
About bare metal restore BMR Windows and Linux 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

Factors when choosing agent-based or agentless protection

The Rapid Snap for Virtual feature of Rapid Recovery is supported on vCenter/ESXi or on Hyper-V hypervisors. This feature, also known as agentless protection, lets you protect VMs running on your protected hypervisor in your Core without installing the Rapid Recovery Agent software on each guest machine.

General recommendations

Rapid Snap for Virtual has nearly achieved parity with protection provided by installing the Rapid Recovery Agent software. As a general rule, Quest recommends using agentless protection on ESXi or Hyper-V virtual machines. If the Agent software is installed on ESXi or Hyper-V VMs, unless there is a compelling reason to explicitly protect your VM using Rapid Recovery Agent, Quest recommends removing the Agent software, and protecting your VMs agentlessly.

There are some advantages to protecting agentlessly, and some limitations. These are clearly described in the topic Understanding Rapid Snap for Virtual.

Exceptions to the recommendation to use agentless protection are as follows:

  • Gathering metadata for agentless machines is slower than for machines protected by the Rapid Recovery Agent software. If you experience performance issues related to metadata (specifically for agentlessly protected Exchange Server or SQL Server machines), Quest Data Protection Support may suggest installing the software-based Agent on specific application servers for troubleshooting purposes.
  •   If protecting only one or two VMs on a hypervisor with multiple sockets, you may consume fewer licenses by installing Agent directly on the VMs instead of the host.
  •  If you require features exclusive to Rapid Recovery Agent, install the Agent software on relvant VMs.

Some features are unique to protection by installing the Rapid Recovery Agent software. The following examples apply:

  • Performing a SQL attachability check is a capability of the Rapid Recovery Agent software. If protecting your SQL Server machine agentlessly, you must perform SQL Attachability checks using an instance of SQL Server installed on the Core server. To perform this check, you must adjust your Core Attachability setting on the Core to Use SQL Server on the Core.
  • Dynamic volumes protected agentlessly are protected at the disk level, not the volume level.
  • Live Recovery is a feature of the Rapid Recovery Agent software. You cannot use this feature when restoring volumes protected using Rapid Snap for Virtual (nor for Linux machines or when restoring CSVs).

If you require any of the features described in the previous list for a specific VM, Quest recommends installing Agent instead of protecting the VM agentlessly.

For more information, see the topic Understanding Rapid Snap for Virtual.

Release 6.3 license consumption concepts

As described in the Rapid Recovery 6.3 Installation and Upgrade Guide topic "Managing licenses," Rapid Recovery 6.2 and later uses only two license pools: Capacity, and Enterprise. If licensing for your Core is set up to use a capacity-based pool, you cannot use another pool type.

NOTE: In the future, Quest may add license pools based on other units of measure. Capacity and Enterprise pools continue to be supported.

DL series backup appliances use back-end capacity-based licensing, and are not affected by license pool restrictions. Software-based Rapid Recovery environments using front-end capacity licensing likewise receive no license benefits from using agentless protection. Other benefits for using agentless protection are relevant even when Capacity license pools are in use.

If your Rapid Recovery release 6.2 or later environment uses an Enterprise license pool, then the following rules apply:

  • Hyper-V or vCenter/ESXi hypervisor hosts protected with Rapid Recovery Agent consume one license from the pool for each processor socket. If your hypervisor host has six CPU sockets, it consumes 6 licenses from the Enterprise pool.
  • Any other machine (physical or virtual) protected in your Core with Rapid Recovery Agent consumes one license from that pool. This is true even for application servers (such as Exchange Server, SQL Server, or Oracle Database 12c) with multiple CPU sockets.

Licensing benefits of using agentless protection

You can protect guest VMs on a vCenter/ESXi hypervisor host by running the Protect Multiple Machines Wizard. On the Connection page of this wizard, if you specify Protect selected VMs agentlessly, the guest VMs on that host are protected agentlessly. For those VMs, no licenses are consumed from your license pool. While Rapid Recovery Agent is not installed on the host, adding that host to your Core consumes one license for each CPU socket.

When you protect a Hyper-V Server, Rapid Recovery Agent is installed on the host. For each CPU socket on that hypervisor host, one license from your Enterprise pool is consumed. If you specify protecting the Hyper-V server agentlessly, guest VMs are protected agentlessly, and for those VMs, no licenses are consumed from your available license pool.

When you protect a Hyper-V cluster, Rapid Recovery Agent is installed on each node in the cluster. Only a single license is consumed from your license pool. The total number of CPU sockets in the cluster are consumed. If you specify protecting the Hyper-V cluster agentlessly, guest VMs are protected agentlessly, and for those VMs, no licenses are consumed from your available license pool on the cluster.

The chief licensing benefit to using Rapid Snap for Virtual is a reduction in consumption of licenses from your Enterprise license pool for the VMs you protect. If you specify agentless protection for an ESXi hypervisor host, or a Hyper-V server or cluster, all new VMs created on the host are automatically protected agentlessly, and do not consume licenses from your Enterprise license pool.

If some of the VMs on that hypervisor host previously had Rapid Recovery Agent installed, and your Core is running Rapid Recovery release 6.2 or later, you should do one of the following:

  • Remove the Agent software and protect the VM agentlessly. No licenses from your pool are consumed.
  • If you require the machine to be protected by Agent, and the host is added to the Core, associate the VM with its parent host. You get the benefit of Agent-based protection, and no license is consumed.
  • Make no changes. The VM is protected using the APIs in Rapid Recovery Agent, and a single license is consumed.

Each virtual machine on a hypervisor added to your Core is protected agentlessly without consuming a license. To obtain this benefit, you must do the following:

The chief licensing benefit to using Rapid Snap for Virtual is a reduction in consumption of licenses from your Enterprise license pool for the VMs you protect. Each virtual machine on a hypervisor added to your Core is protected agentlessly without consuming a license. To obtain this benefit, you must do the following:

  • Protect VMs agentlessly. You can explicitly protect VMs by using the Protect Multiple Machines wizard. When protecting a hypervisor host, you can also select the option to Auto protect new virtual machines, which implicitly protects new VMs when they are created.
  • Associate the guest VM with its protected hypervisor host. If Rapid Recovery Agent is installed, its APIs (not those native to the hypervisor) are used to protect the VM. However, you can reduce licenses consumed by associating the VM with the host that has been added to the Core. This association is performed at the machine level for each virtual machine. The process of linking the guest VM with its parent hypervisor host is described in step 3 of the procedure Viewing and modifying protected machine settings.
  • Uninstall Agent. Unless otherwise recommended, remove any copies of the Agent software from the virtual machine.

For a discussion of benefits and limitations regarding agentless protection, additional software recommended, minimum requirements for the host, and so on, see the topic Understanding Rapid Snap for Virtual.

 

About protecting Linux machines with Rapid Recovery

The Rapid Recovery Agent software is compatible with multiple Linux-based operating systems (for details, see the system requirements now defined in the Rapid Recovery System Requirements Guide ). The Rapid Recovery Core is compatible only with Windows machines. While you can manage protected Linux machines from the Rapid Recovery Core Console, several procedures for Linux machines have steps that differ from their Windows counterparts. Additionally, you can perform some actions directly on a protected Linux machine by using the local_mount command line utility.

If you want to protect a single Linux machine, you can now use the Protect Machines Wizard. See the topic Protecting a machine. To protect multiple Linux machines simultaneously using the wizard from the Core Console, see the topic Protecting multiple machines manually.

To deploy or install the Agent software to a Linux machine from the Core Console, you must have the following:

  • The user account must have SUDO privileges.
  • The Linux machine you want to protect must have access to an SSH server.

If a Linux machine you want to protect does not meet these prerequisites, consult with a Linux administrator. Comply with these requirements and then you can complete the relevant wizard to deploy and install the Agent software.

About protecting Oracle database servers

Rapid Recovery expands application support in release 6.2 and later to include Agent-based protection of Oracle 12c relational database servers. You can protect an Oracle database server and all of its databases, and perform related tasks.

In this release, the following restrictions apply:

  • Oracle 12c is the only tested and supported version for protection on the Rapid Recovery Core. Use any other Oracle versions at your own risk.
  • Protected Oracle database servers must run 64-bit versions of Windows Server 2012 R2 x64 or Windows Server 2016.
  • You must install the Rapid Recovery Agent software (release 6.2 or later) on your Oracle server. Agentless protection is planned for a future release.
  • Protection of Oracle12c databases is limited to using Volume Snapshot Service (VSS) in the ARCHIVELOG mode.

NOTE: Support for NOARCHIVELOG (the default Oracle database log mode) is planned for a future release. Oracle databases with ARCHIVELOG mode enabled must also be set to archive all online redo logs using the ARCH (archive) process. A database administrator (DBA) can change the mode and set archiving of redo logs using Oracle SQL*Plus or Oracle Enterprise Manager. For more information about enabling ARCHIVELOG mode and archiving, see Oracle documentation or consult a qualified Oracle 12c DBA.

To fully protect Oracle servers, perform the following tasks:

  • Install the Rapid Recovery Agent software (release 6.2 or later) on your Oracle server and begin protection. Use the Protect Machine Wizard to locate the Oracle server on your network, deploy the Agent software, and establish a protection schedule. For more information, see About protecting machines with Rapid Recovery.
  • Enter credentials for each database in the Rapid Recovery Core Console. The Core securely caches your credentials and lets you access the metadata from the UI. Before you enter credentials, you cannot view details for databases on your protected Oracle server. For more information, see Entering or editing credentials for Oracle databases.
  • Enable ARCHIVELOG mode for the protected Oracle server, and verify the Oracle VSS writer, from the Core Console. For more information, see Enabling archive log mode and adding VSS writer for protected Oracle databases.
  • Review log truncation deletion policies offered in Rapid Recovery Core and implement a log truncation regime. When an Oracle database is set to ARCHIVELOG mode, the logs accumulate quickly and consume substantial disk space. You can truncate Oracle logs manually on demand, or configure automatic log truncation using the "Log truncation for Oracle" nightly job. Both methods offer the same Deletion policies for Oracle log truncation. To avoid eventual errors and snapshot failures when storage for the logs is full, implement a consistent approach for managing Oracle logs. For more information, see About truncating Oracle logs.

    You can also truncate Oracle database logs manually on demand. For more information about this procedure, see Manually truncating Oracle database logs.

Once you install the Agent, protect the machine in your Core, and configure settings properly, you can do the following:

  • View metadata. From the protected machine Summary page, you can view metadata about each database on your Oracle server, including connection and status for each log file, control file and data file.
  • Check database integrity. You can perform integrity checks from the Core Console using the DBVERIFY utility.
  • Truncate archive logs, using one of three deletion policies.
  • Restore databases. Restore entire volumes, or volumes that contain selected databases. Once you enable Archive log mode, snapshots of the Oracle database are crash-consistent from the point of view of the Oracle service.
  • Perform virtual export. You can make a one-time export, or set up a virtual standby VM that continually updates a VM with new information as backups on your protected database are captured.

    If you boot up a VM of an Oracle database, you may have to manually start the database services, and manually disable backup mode for database data files.

Entering or editing credentials for Oracle databases

Before performing this procedure, you must first add an Oracle database server to protection on your Core.

To enter or edit Oracle database credentials:

  • The Windows user account of the Rapid Recovery user performing this procedure must have SYSDBA privileges on the protected database server.
  • The database must be accessible to the Rapid Recovery Core server, and a connection must be successfully established.

NOTE: SYSDBA is an Oracle systems database administrative privilege required to perform high-level administrative operations. These functions include creating, starting up, shutting down, backing up, or recovering an Oracle database.

After protecting your Oracle database server, you cannot access database metadata or view database details until you enter credentials for each database. This one-time step caches your database credentials securely and provides the Core Console with access to status information about all protected transaction log files, control files, and data files that comprise your Oracle databases.

For example, on the Summary page for the protected Oracle machine, before entering credentials, you cannot expand details about any of the protected databases in the Oracle Server Information pane.

NOTE: This is a one-time step required for each new protected Oracle database.

Complete the steps in this procedure to provide the Rapid Recovery Core Console with access to the required metadata for your protected Oracle databases.

  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. For the first database in the table, click the [More options] (More options) drop-down list and select Edit Credentials.
    The Edit Instance Credentials dialog box displays.
  4. Two connection types are supported: basic, and Transparent Network Substrate (TNS, a proprietary Oracle networking technology). Do one of the following:
    • To connect using a basic connection, enter the information in the following table:
    Option Description
    Connection Type Basic
    Host Name Enter the host name or IP address.
    Port Enter the appropriate port. The default port open for this purpose is 1521.
    SID or Service Name Select the appropriate connection method. You can use one of the following:
    • SID. The Oracle System Identifier (SID) is a unique ID that uniquely identifies your database instance.
    • Service Name. The service name is the TNS alias used to remotely connect to your database.

    NOTE: The service name can be found in the TNSNAMES.ORA file.

    Service Name The service name is the TNS alias that you give when you remotely connect to your database and this Service
    • To connect using TNS, enter the information in the following table:
      Option Description
      Connection Type TNS
      Network Alias Select this drop-down menu to view database aliases available to the network, and select the appropriate alias.
  5. Two credential types are supported: Oracle, and Operating System. Do one of the following:
    • To connect with Oracle credentials, enter the user name and password for the Oracle database in the relevant text fields.

      NOTE: Your Windows user account must have SYSDBA privileges.

    • To connect using cached credentials from the operating system, select Operating System.

      NOTE: Your Windows user account must be a member of the ORA_DBA local group, which ensures the user has SYSDBA privileges.

  6. To verify credentials, click Verify.
    A dialog box displays, indicating if the test connection was successful.
  7. Do one of the following:
    • If the verification succeeded, click OK to close the message dialog box.
    • If not successful, close the dialog box and revise the instance credentials until connection is verified. Consult your system administrator if you have questions about credentials.
  8. In the Edit Instance Credentials dialog box, after successful verification, click OK.
    The dialog box closes, and Rapid Recovery Core Console immediately applies and caches the credentials. Very soon afterward, metadata is available in the Core Console, and the status indicator for the selected database displays a green (online) status.
  9. Repeat step 3 through step 8 for each database listed in the Oracle Server Information pane.

After entering and caching credentials for all databases on this protected Oracle machine, perform the procedures described in the topic Enabling archive log mode and adding VSS writer for protected Oracle databases.

Documents connexes