Chat now with support
Chat with Support

Rapid Recovery 6.2 - User Guide

Introduction to Rapid Recovery Core Console Core settings
Core settings key functions Rapid Recovery Core settings Core-level tools
Repositories 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 Snapshots and recovery points Replication Events Reporting VM export Restoring data Bare metal restore
Bare metal restore for Windows machines Understanding boot CD creation for Windows machines 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 The Local Mount Utility Core Console references REST APIs About us Glossary

Creating a container in an Azure storage 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. Or you can define the container as part of the export process from the Destination page of the wizard.

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

3.
From the All resources pane, click the name of the storage account in which you want to store data from your Rapid Recovery virtual exports.
4.
In the Settings pane, click 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.
7.
From the New container pane, from the Access type drop-down menu, select the appropriate container type, which defines whether the container can be accessed publicly. Use the following as guidance.

Option

Description

Private

This option restricts the container to the account owner.

Blob

This option allows public read access for Binary Large Objects (Blobs).

Container

This option allows public read and list access to the entire container.

8.
Click Create.

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

Microsoft Azure documentation

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

For information on creating an Azure account, spinning up a VM for use with a Rapid Recovery or AppAssure Core, adding a storage account, 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:

Before virtual export to Azure

Rapid Recovery lets you perform virtual export (one-time, or virtual standby) to Microsoft Azure.

Before you can perform a virtual export of any machine protected in Rapid Recovery, you must first associate your Azure cloud account with your Core, as described in the topic Adding a cloud account.

You must have an adequate storage account on Azure. For more information on creating a storage account in Azure, refer to Azure's support information, which is referenced in the topic .

In your storage account, you can dynamically create a container to store exports, or you can use an existing container. For more information about creating a storage container, see Creating a container in an Azure storage account.

Unlike other forms of virtual export using Rapid Recovery, VM export for Azure includes two processes, described in detail in the topic Exporting and deploying VMs for Azure.

Exporting and deploying VMs for Azure

Unlike virtual export for other platforms, virtual export for Azure is comprised of 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.

To avoid incurring unnecessary charges, virtual export to Azure consists of two separate processes, to defray costs that may not be necessary.

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:

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.

Related Documents