To integrate your SAML single sign-on authentication identity provider (IdP) server with your Rapid Recovery Core server, complete the following steps.
|
|
NOTE: Before you configure SAML settings in Rapid Recovery, you must enable SAML with a compatible IdP. For more information, see Understanding SAML single sign-on.
NOTE: Rapid Recovery Core supports two types of authentication: Windows-based and SAML-based. The Core uses Windows-based authentication by default. After you enable SAML, the Core begins to use SAML-based authentication. |
|
|
Caution: After you configure the SAML settings, you must restart theRapid Recovery Core Service for the changes to take effect. Before you restart the Core Service, you must complete all of the steps in the configuration procedure. If you restart the Core service before completing the SAML configuration, the Core Console becomes inaccessible. |
To configure SAML settings
- Navigate to the Rapid Recovery Core Console.
- On the icon bar, click
![[Settings]](/ko-kr/technical-documents/image/5c303bbd-9e34-46f3-bcca-4c0b5ff4786e)
(Settings), and then do one of the following:
- Next to Enable configuration, select Yes.
- Copy or take note of the following information provided by Rapid Recovery Core:
- Sign on URL
- Reply URL (Assertion Consumer Service URL)
- Logout URL
- Go to your IdP.
- On the Single Sign-on or SAML page, paste or enter the Rapid Recovery information in the corresponding areas.
- On the same page of your IdP, copy or take note of the following information:
- Metadata URL (Issuer URL)
- Audience (Entity ID)
- If you have token encryption enabled, upload the certificate file and provide the password.
- Return to the Rapid Recovery Core Settings page.
- In the SAML section, paste or enter the Metadata URL and Entity ID that you copied from the IdP.
For each setting, when satisfied with your changes, click ![[Check mark]](/ko-kr/technical-documents/image/bf495898-d16b-4479-9189-5f6944f193f6)
to save the change and exit edit mode, or click ![[Check mark]](/ko-kr/technical-documents/image/978886e6-8723-43fa-a386-2a7ec90cc08c)
to exit edit mode without saving.
- Modify the SAML settings as described in the following table. For each setting, when satisfied with your changes, click to save the change and exit edit mode, or click to exit edit mode without saving.
Find the following details on the SAML page of your IdP.
Table 38: SAML connection settings information
| Enable configuration |
Select Yes. |
| Metadata URL |
Enter the metadata URL from your IdP. This URL provides an endpoint on the Rapid Recovery Core that Rapid Recovery uses to furnish keys and additional SAML endpoints to the IdP. |
| Entity ID |
Enter the entity ID from the IdP. This URL serves as the identifier that represents the Rapid Recovery Core server, and should be the same as the Entity ID on the IdP. |
| Signature algorithm |
If using a certificate, select the signature algorithm from the following options:
- RSA-SHA1
- RSA-SHA256
- RSA-SHA384
- RSA-SHA512
|
| Certificate validation |
Select the validation you want to use from the following options:
- None
- ChainTrust
- PeerOrChainTrust
- PeerTrust
|
| Enabled token encryption |
Select whether to enable token encryption.
NOTE: Not all IdPs support token encryption. |
- If you enabled token encryption, the Certificate option appears.
- Next to Certificate, click Upload and complete the following steps:
- In the Upload certificate window, upload the certificate file by clicking Choose File.
- Enter the password for the certificate.
- Click Continue.
- To run a validation of the current settings and confirm the login with the IdP, click Check SAML.
- To return the settings to their original state, click Reset.
- To apply the SAML settings, restart the Core service.
To protect your data using Rapid Recovery, you need to add the workstations, servers, desktop, and laptop machines you want to protect to your Rapid Recovery Core.
In the Rapid Recovery Core Console, using one of the Protect Machine wizards, you can identify the machines you want to protect. You can do the following:
- Protect a single machine using the Protect Machine wizard, which connects to the machine using network hostname or IP address. For more information about how to protect a single machine, see Protecting a machine.
- Protect a network cluster using the Protect Cluster wizard, which connects to the cluster and its nodes using network hostname or IP address. For more information about how to protect a cluster, see Protecting a cluster.
- Protect multiple machines simultaneously using the Protect Multiple Machines wizard. This wizard lets you connect to the machines associated with a Microsoft Active Directory server; machines on a vCenter or ESXi host; or to machines on a Hyper-V host or a Hyper-V cluster. You can also manually enter connection information (network hostname or IP address, username and password) for multiple machines. For more information about how to protect multiple machines, see About protecting multiple machines.
|
|
NOTE: Quest recommends limiting the number of machines you protect simultaneously to 50 or fewer, to preclude experiencing resource constraints that may cause the protect operation to fail. |
When identifying your protection requirements for a single machine in the wizard, you can specify which volumes to protect. When you protect multiple machines, all volumes are protected by default. (You can change this later on an individual machine basis).
When protecting a virtual machine on a vCenter/ESXi or Hyper-V host, you must define whether to protect the machine using the Rapid Snap for Virtual feature or by installing Rapid Recovery Agent. For more information, see Factors when choosing agent-based or agentless protection.
The wizard also lets you define a customized schedule for protection (or re-use an existing schedule).
Using advanced options, you can add additional security measures by specifying or applying an encryption key to backups for the machines you want to protect.
Finally, if one does not already exist, you can define a repository using the wizard.
After installing the Agent software, each machine must be restarted after installation.
For more information on how to protect workstations and servers, see Protecting a machine.
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).
|
|
NOTE: Rapid Recovery supports Windows Server 2012 and 2012 R2 for agentless protection only. |
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.7 license consumption concepts
As described in the Rapid Recovery Installation and Upgrade Guide topic "Understanding Rapid Recovery 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.
