As of release 6.2, Quest Rapid Recovery supports Azure Stack. It is available in the Azure Marketplace items available for Azure Stack listed under "Quest Rapid Recovery Core."
Azure Stack is Microsoft's proprietary answer to the open source OpenStack platform. Essentially, Azure Stack is a hybrid cloud software solution (based on the Azure cloud platform) that organizations can use in their own data centers. In other words, it is an on-premises cloud service instead of a service hosted in Microsoft's cloud. In practice, users could seamlessly move from their private cloud to the Azure public cloud if needed.
Azure and Azure Stack share a standardized architecture, including the same portal, a unified application model, and common tools.
For some time, Microsoft supported two sets of APIs: the original Azure deployment technology, Azure Service Management (ASM, known as the Classic deployment model), and its replacement, Azure Resource Manager (ARM). New to Rapid Recovery in this release is support for ARM.
When using ARM with Rapid Recovery, additional steps are required for your Azure account. These prerequisites are fully addressed in the topic "Before virtual export to Azure" in the Rapid Recovery 6.3 User Guide.
Microsoft announced that support for ASM is retired as of June 30, 2018. Accordingly, in release 6.3, Rapid Recovery no longer supports ASM for virtual export. Instead, Rapid Recovery virtual export to Azure exclusively supports ARM.
Rapid Recovery Core also includes the ability to archive recovery points to Azure. For both virtual export to Azure and archiving to Azure, you must first create a cloud account in the Rapid Recovery Core Console to connect your Core and Azure accounts. In this release, cloud account requirements differ for these two functions.
When setting up an Azure cloud account in Rapid Recovery Core release 6.3 for use with virtual export to Azure, select the cloud account type Microsoft Azure Resource Management (for Virtual Export).
Customers already using virtual export to Azure before upgrade to this release are advised to remove the Rapid Recovery virtual exports from their Azure accounts and perform fresh virtual exports after upgrading to release 6.3.
For more information about performing one-time or continual virtual export to Azure, see the Rapid Recovery 6.3 User Guide.
When setting up an Azure cloud account in Rapid Recovery Core release 6.3 for use with archiving recovery points to Azure, select the cloud account type Microsoft Azure (for Archive).
NOTE: In previous releases, this cloud type was simply called Microsoft Azure.
For more information about archiving recovery points (on demand or continually, based on a schedule), see the Rapid Recovery 6.3 User Guide.
Azure supports storage accounts created using ARM. When viewing these storage accounts in Azure, the account type shown in the Azure GUI is simply Storage account. This is the recommended storage account type.
At the time of publication, Azure continues to support storage accounts created using ASM. When viewing these storage accounts in Azure, the account type shown in the Azure GUI is Storage account (classic). Note that you can no longer create a classic storage account using ASM.
When performing archive to Azure in this release, you can use storage accounts created using either deployment method, ARM or ASM, as long as the cloud account type is Microsoft Azure (for Archive).
However, the use of classic Azure storage accounts in Rapid Recovery Core is deprecated, and support in Rapid Recovery Core is expected to be removed in a future release. As a best practice, Quest recommends creating storage accounts using ARM and using this fully supported storage account type for both virtual export and archiving recovery points. For more details in these Release Notes, see Azure Service Management features deprecated.
For more information about Microsoft ending support for ASM, please see Microsoft blogs, knowledge base articles, and online Azure documentation, including the following:
Credentials Vault is a new Rapid Recovery usability feature that manages account login credentials used within the Rapid Recovery Core Console.
When performing operations such as adding a machine or cluster to protection, setting up virtual export or replication, connecting to a repository, archiving or restoring archived recovery points, and so on, you are prompted to enter account credentials. For each account, credentials include the user name, password, and a description parameter where you can identify the account. After you enter your credentials, if you choose to, you can add them to the Credentials Vault.
Thereafter, the next time you want to perform an operation in the Core Console that uses the same account, instead of manually entering your user name and password, you can select the account from a drop-down menu.
The Credentials Vault simplifies management of your passwords. For example, if your organization has a security policy mandating password changes at frequent intervals, one visit to the Credentials Vault page can let you easily update your password for each user account accessed from the Rapid Recovery Core Console.
The Credentials Vault is unobtrusive. Sections of the Core Console UI that are enabled for the Credentials Vault include a + sign next to the User name text box when prompted for credentials. When you place your cursor over it, you see a hint that reads "Save account to Credentials Vault." To add an account to the vault, click the + sign to open the Add New Account dialog box, then enter the user name, password, and a meaningful text description. Then click OK to save the account to the vault.
NOTE: Unlike most descriptions, the text you enter describing each account in the Credentials Vault is functional. Passwords, once entered into the vault, are not displayed. Thus, the combination of the user name and this description uniquely identifies each account in the vault. This value can later be edited.
After accounts have been added to the Credentials Vault, when prompted to authenticate, you can view the list of accounts and select an account with one click, rather than manually entering your account user name and password.
From a location on the Rapid Recovery Core Console in which you are asked for credentials, click the downward-facing arrow in the User name text box. The view expands to show a drop-down grid, with each row representing one account in the Credentials Vault.
Scroll through the list to identify the account for which you want to enter credentials. Then click on the row for the appropriate account.
The Credentials Vault drop-down grid appears. Each row shows the user name and description associated with an account held in the vault. The grid closes, and the account information is passed to the window or dialog box. Since passwords are hidden, the password parameter is not shown.
From the Rapid Recovery Core Console, you can also view and manage all accounts in the vault. From the More menu, select Credentials Vault. The Credentials Vault page appears. For each account, the user name, description, and utilization appears. You can do the following:
Rapid Recovery encrypts credentials in the vault using the Microsoft Data Protection API (DPAPI) using local machine scope.
For detailed information about this feature, including step-by-step procedures, see the "Credentials Vault" section of the Rapid Recovery 6.3 User Guide.
Active Block Mapping (ABM) is a feature developed to optimize image-based data protection by keeping inactive blocks out of managed images. This addition brings critical performance advantages for capturing incremental backups (specifically for virtual machines).
While not available on the Core, ABM can be configured on two levels as follows:
ABM is implemented as a query to the volume's file system header (MFT for NTFS), which returns a list of active blocks in the image. ABM can be used by itself to read only active blocks from a VM during a backup process. ABM can also be combined with Changed Block Tracking (CBT) to read only active and changed blocks when capturing incremental backups specifically of virtual machines.
Implementation is based on the integration with DiskUtils library, which is already used within the Core for multiple features including Agentless protection of ESXi and Hyper-V VMs.