지금 지원 담당자와 채팅
지원 담당자와 채팅

Rapid Recovery 6.4 - 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 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 Azure storage accounts

Users are advised to research features of Azure before using them with Rapid Recovery. Proper research enables you to balance your needs, preferences, and costs.

Take the example of an Azure storage account, which contains data objects: Binary Large OBjects (or “blobs”,) files, queues, tables, and disks. When creating an Azure storage account, consider the following aspects:

  • What type of objects are you storing?
  • Is the retention length expected to be brief or long?
  • Do you intend to access data frequently or rarely?
  • How quickly do you need access to the information stored there (immediately, minutes, hours)?

When performing virtual export to Azure, you must select or create a storage account that supports the relevant type of blobs. For export, Rapid Recovery uses page blobs, which are a collection of 512-byte pages optimized for random read and write operations. Azure now supports a maximum page blob size of 8TB. Eventually, this Azure restriction is likely to be increased in the future. Accordingly, as of release 6.4, Rapid Recovery Core has doubled the supported maximum data disk size for virtual export and deploy to Azure from 4TB to 8TB.

Azure storage offers different access tiers, which affect cost, restrict data types, affect speed of access, and apply to the frequency of use. Select the Azure storage account kind that best reflects your needs.

For Azure storage, there are 3 account kinds, which is relevant when determining which blobs you want to store and how quickly or often you need to access them. These are shown in the following table:

Kind Description Recommendations
Storage (general purpose v1), or GPV1 Legacy storage type. Supports page blobs, required for virtual export. Does not have an access tier. Can be used for virtual export or archiving to Azure. Microsoft documentation suggests using GPV2 instead when possible.
Storage V2 (general purpose v2), or GPV2 Contemporary and default storage account type. Supports page blobs, required for virtual export. Lets you select an access tier when creating the storage account. Incorporates all of the functionality of GPV1 and BlobStorage accounts. Recommended by Microsoft. Hot access tier has higher storage costs, but the lowest access costs. Use GPV2 with hot access tier for continual export to Azure; consider GPV2 with cool access tier for one-time export.
BlobStorage Legacy account kind. Supports only block and append blobs, not page blobs, and thus does not support virtual export. Lets you select an access tier when creating the storage account. Can be used for archiving but not for virtual export. Microsoft documentation suggests using GPV2 instead when possible.

NOTE: You can upgrade a GPV1 or BlobStorage account to a GPV2 account with no downtime and without the need to copy data. For more information, see Azure article Upgrade to a General-purpose v2 storage account.

Creating an Azure storage account

You must have administrative access to an account on Azure.

NOTE: The Microsoft Azure interface is subject to change. For more information, see Azure interface disclaimer.

To perform certain functions (including virtual export from Rapid Recovery Core to an Azure account), you must first create a storage account on Azure.

NOTE: When creating a storage account, many of the options have additional information available by clicking the [Information]information icon. Place your cursor over the icon for more information.

Complete the steps in this procedure to create an Azure storage account.

  1. Open the Microsoft Azure dashboard.
  2. From the left navigation area, click [All resources] All resources.
  3. From the All resources pane, click + Add.
  4. In the New blade, click [New Storage Account]Storage Account.
  5. On the Create storage account page, enter the parameters for your Azure storage account as described in the following table:
    Option Description

    Subscription

    Required. Select the subscription into which you want this storage account to be created.

    Resource group

    Required. Select the resource group in which you want this storage account to be created.

    NOTE: For successful virtual export, this owning resource group must be created using Azure Resource Manager.

    Storage account name

    Required. Provide a clear unique description for your storage account, using between 3 and 24 characters consisting only of lower-case letters and numbers.

    For example, companyabcstorage1.

    Location

    Required. Choose the appropriate Azure region.

    Performance

    Select Standard or Premium.

    Account kind

    Select an account kind. The default, StorageV2 (general purpose v2), is recommended for most scenarios.

    Replication

    Choose a replication strategy for your storage account. The default is Read-access geo-redundant storage (RA-GRS).

    Access tier (default)

    Choose from Cool or Hot, based on frequency of access.

  6. Optionally, to change the requirement for secure transfer or to associate with a virtual network, click Next: Advanced. Otherwise, skip to step 10.
  7. On the Advanced page, in the Security area, to disable or enable secure transfer, click the appropriate selection. Secure transfer is enabled by default.
  8. Optionally, on the Advanced page, in the Virtual Networks area, to select an existing virtual network associated with your subscription, location, and resource group, from the Virtual network drop-down menu, select a network and skip to step 9. To create a new virtual network associated with this subscription, location, and resource group, do the following:
    1. Under the Virtual network option, click Create new.
    2. On the Create virtual network page, in the Name text field, enter a name for your new virtual network.

      NOTE: Restrict the name to letters, numbers, underscores, periods, or hyphens. See additional name restrictions in the Azure UI.

    3. In the Address Space area, select the default address range to restrict access to IP addresses between 10.1.0.0 and 10.1.255.255. To restrict to a narrower set
    4. In the Subnets area, select a subnet name contained by the address range specified in the previous step. For example, select default.
    5. When satisfied with your virtual network settings, click Create.

      The Advanced page closes and the virtual network you created is selected.

  9. On the Advanced page, in the Virtual Networks area, if you selected an existing virtual network, from the Subnets drop-down menu, select an appropriate subnet for your virtual network.
  10. When satisfied with your storage account details, click Review + create to validate the settings.
  11. If validation errors are found, visit the page with the error, update the parameters you defined, and review again.
  12. When satisfied, click Create.

    You see a message indicating that the deployment of your storage account has started. If toast alerts are active, you see another message when the deployment is completed.

Creating a container in an Azure storage account

The following items are prerequisites:

  • You must have administrative access to an account on Azure.
  • You must have a storage account defined within your Azure account.

When you perform virtual export, the information is stored in a container within an Azure storage account. You can define the container from your Azure account before performing virtual export, using the procedure below.

NOTE: If you do not define containers in advance, you can choose default containers (named export and deploy, respectively)

Complete the steps in this procedure to create a container in an Azure storage account.

  1. Open the Microsoft Azure dashboard.
  2. From the left navigation area, click [All resources] All resources.
  3. From the All resources pane, click the name of the [Storage accounts] storage account in which you want to store data from your Rapid Recovery virtual exports.
  4. In the Settings pane, under Services, click [Blobs] Blobs.
  5. From the top of the Blob service pane, in the header, click + Container.
  6. From the New container pane, in the Name field, type the name for your new container.

    NOTE: Type a name between 3 and 63 characters, using only lowercase letters, numbers, and hyphens.

  7. From the New container pane, from the Public access level drop-down menu, select an access level to define whether the container can be accessed publicly. Use the following as guidance.
    Option Description
    Private (no anonymous access) This option restricts the container to the account owner.
    Blob (anonymous read access for blobs only) This option allows public read access for Binary Large Objects (Blobs).
    Container (anonymous read access for containers and blobs) This option allows public read and list access to the entire container.
    For example, select Container (anonymous read access for containers and blobs).
    • Click OK.
      If Toast alerts are active, you should see a message indicating that the container was successfully created.

      The Blob service page refreshes, with the new container name displayed in the list.

Creating an Azure Active Directory web application

Perform these steps before attempting virtual export to Azure.

You must use an Azure Active Directory (AD) web application to serve as a connection between your Rapid Recovery Core and your Azure subscription. After creating the web application, record its application ID, and create a secret key associated with the application.

You should also gather the tenant ID. Finally, associate the appropriate privileges to your web application.

Complete the steps in this procedure to create an Azure AD web application with the appropriate keys and privileges.

  1. From the Azure navigation menu, click [AD] Azure Active Directory and select [App registrations]App registrations.
  2. Click + New application registration.
  3. On the Create page, in the Name field, provide a name for your application. Your name must have at least 4 characters.
  4. From the Application type drop-down field, select Web app / API.
  5. In the Sign-on URL field, enter the URL where a user can sign into Azure and use the app. This value can later be changed, but it must be a valid URL, for example: http://YourAppLogin.com or https://YourSecureAppLogin.net.
  6. When satisfied click Create.

    The details pane for your web application appears.

  7. From the details pane for your web application, copy the Application ID to an easily accessible location (for example, to a Notepad document on your Core server).
  8. From the details page for your web application, click [Settings] Settings.
  9. From the Settings pane, click [Subscriptions] Keys.
  10. From the Keys pane, do the following:
    1. In the Description field, enter a text description to describe the secret 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.

  11. Now obtain the Directory ID for the AD web application (described in the Rapid Recovery Core Console as the Tenant ID) by doing the following:
    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.
  12. 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.

 

관련 문서

The document was helpful.

평가 결과 선택

I easily found the information I needed.

평가 결과 선택