立即与支持人员聊天
与支持团队交流

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

Obtaining the directory ID for your Azure web application

As a prerequisite for this task, you must create an Active Directory (AD) web application in your Azure subscription. For more information, see Creating an Azure Active Directory web application.

When associating an Azure cloud account with the Rapid Recovery Core, one parameter you must provide is the tenant ID. Azure calls this parameter the directory ID. The directory ID is a property of the Active Directory (AD) web application you create within your Azure subscription.

Complete the steps in this procedure to obtain the directory ID for your AD web application from your Azure account.

  1. From the Azure navigation menu, click [AD]Azure Active Directory.
  2. From the Properties pane, scroll down if necessary and click [Properties] Properties.
  3. From the Properties Details pane, copy the Directory ID value to an easily accessible location. This parameter is referred to in the Rapid Recovery Core Console as the tenant ID.
  4. Finally, as an Azure user with administrative privileges, add the Owner role to your web application by doing the following:
    1. From the Azure navigation menu, click [All services] All services.
    2. From the General category, click [Subscriptions] Subscriptions and then click on your Azure subscription.
    3. In the Subscription blade, click [IAM] Access control (IAM), and then click + Add.

      The Add permissions dialog box appears.

    4. From the Role drop-down menu, select Owner.
    5. From the Assign access to drop-down menu, select Azure AD user, group, or application.
    6. From the Select drop-down menu, search for and select the name of your AD web application, and then click Save.

 

Obtaining a secret key for your Azure web application

As a prerequisite for this task, you must create an Active Directory (AD) web application in your Azure subscription.

You must have a secret key to connect to and use your Azure Active Directory (AD) web application with Rapid Recovery. Typically, a key is created as part of the process for defining the web application. When creating the secret key, immediately save the secret key to a secure location, as it cannot be recovered or viewed later.

NOTE: The steps for defining your secret key after creating the web application is described in the topic Creating an Azure Active Directory web application

If you do not record the secret key value, you can create a new secret key for your web application in Azure.

Complete the steps in this procedure to create a new secret key associated with an existing Azure AD web application.

  1. From the Azure navigation menu, click [AD] Azure Active Directory and select [App registrations] App registrations.
  2. Click the name of the appropriate AD web application in your Azure account.

    Details for the selected web application appear.

  3. From the details page for your web application, click [Settings] Settings.
  4. From the Settings pane, click [Subscriptions] Keys.
  5. From the Keys pane, do the following:
    1. In the Key description text area, enter a text description to help identify the purpose of the secret key. For example, to describe this key as the one you will use with Rapid Recovery Core, type RRCore-key.
    2. From the Expires drop-down menu, select a duration for this secret key, for example, 2 years.
    3. From the top of the Settings pane, click [Save] Save.

    Caution: Immediately record the secret key description and value in a secure location for the long term. If you do not retain the secret key for your Azure AD web application when you create it, it cannot be recovered.

Microsoft Azure documentation

Microsoft has substantial documentation on using Azure available in its documentation center.

For information on creating an Azure subscription or user account, selecting Azure resources for VMs you create on Azure, adding a storage account to your VMs, and more, see the Microsoft documentation at https://azure.microsoft.com/en-us/documentation.

For example, for information on provisioning or managing Windows VMs, see https://azure.microsoft.com/en-us/documentation/services/virtual-machines/windows/.

For online videos about using Azure, see http://azure.microsoft.com/en-us/get-started/.

Relevant Microsoft links

Some relevant articles on Microsoft websites are listed below:

Third-party related links

  • Azure VM comparison. This third-party website offers comparisons on Azure VM costs. If using PowerShell or Command Line commands to perform Azure tasks at the command line, you can obtain the VM name parameter from the first column in the this table.

Exporting and deploying VMs for Azure

Unlike virtual export for other platforms, virtual export for Azure is divided between two processes: exporting, and deploying.

Be advised that Microsoft Azure customers are responsible for their own fees. Some aspects of our integration with Azure are designed with this fee structure in mind. For example, Microsoft charges fees when you deploy a VM on Azure, and when data is transmitted from Azure to another source.

NOTE: Since Microsoft can change prerequisites, requirements, costs, and so on, always verify such information with Azure. For more information, see the Azure website or contact an Azure representative.

To avoid incurring unnecessary charges, virtual export to Azure consists of two separate processes.

The process of exporting extracts the necessary set of files from Rapid Recovery, validates them, and uploads them to the specified container in Azure. These files include:

  • One virtual hard disk (VHD) file for each volume in the recovery point.
  • One XML file, which contains metadata information about each disk (a list of files present on each disk and a flag indicating if a volume is a system disk).
  • One VHD file containing the backup snapshot.

Other than costs for the required storage, exporting by itself does not incur any Azure fees.

The deployment process combines these files into a bootable virtual machine. Deployment directly uses Azure cloud REST APIs. The original set of files placed on Azure during the export process is read-only in Azure, and consumes space but does not otherwise incur Azure charges. When you deploy these files, a duplicate copy of them is created, stored in a separate container you define, and combined into a working virtual machine. From an Azure account perspective, after you deploy, you are then charged fees for the VM on its servers. Since the deployed VM is a copy of the exported files, the deployment process also doubles the amount of storage space used in Azure for that virtual export.

For a one-time virtual export, there is no mechanism for deploying as a separate process. Thus, for the export to be useful, you should deploy to Azure when you create the virtual machine on demand. As a result, one-time exports to Azure have an immediate cost associated with the VM you deploy.

When establishing virtual standby for a protected machine on Azure, to avoid use of extra storage space and VM charges, you can simply define the export process. The result is an initial virtual export to Azure which is continually updated. Each time a snapshot is captured on the Core, the exported files are refreshed in your Azure account with updated information. Before the virtual export can be used as a bootable VM, you must deploy it, which triggers VM costs on Azure. If you do not need to convert the exported files for a protected machine to a bootable VM, no VM costs are incurred in your Azure account.

For information about performing a one-time export to Azure, including deployment, see the topic Performing a one-time Azure export.

For information about setting up continual export to Azure, excluding deployment, see the topic Setting up continual export to Azure.

For information about deploying the most recent exported files to create a bootable virtual standby VM in Azure, see the topic Deploying a virtual machine in Azure.

相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级