Our FSR to Azure agent restores your data by creating a virtual machine in Azure and then doing a bare metal recovery (BMR) to that virtual machine. Restoring in this way has two main benefits:
- cost savings (since the data does not need to be transferred to and from Azure), and
- improved performance (since the data does not need to be transferred via a local machine), especially if the recovery is initiated from a Storage Platform that is also in Azure.
- To recover an entire system, you need to have done at least one Full System Backup (FSB) of your data. To enable FSB, switching on radio button in your ESE Agent. The button will turn green.
- When enabling FSB on an Azure Virtual Machine with a temporary disk, we recommend excluding the temporary disk from the backup selection. Read more here.
- To restore to Azure on Linux, see Article 1281.
- To restore to Azure using the command-line, see the Target parameter in Article 1184.
- For FSR to Azure limitations and troubleshooting, see Article 1234.
Three connections are important for FSR to Azure:
- Local machine to Storage Platform - used for authentication and to select the backup to be restored to Azure
- Local machine to Azure - used for creating resources, including the VM in Azure
- Azure to Storage Platform - used for restoring the actual data to the target machine in Azure (this connection requires the SP to be publicly available from Azure).
To recover to Azure, you will therefore need the following:
- An Azure account with access to an Azure subscription (the user is required to authenticate with credentials that have permission to create resources in this subscription)
- A resource group for the virtual machine to restore into
- A storage account in the subscription - this is needed for the following purposes:
- As a target for uploading the restore agent and for configuration into Azure. The resulting blob is then converted into a Managed Disk, which is used for starting the restore.
- As temporary storage for the the WinPE bootstrapper image. This is because we need to copy the image into the correct Azure region before we can convert it into a Managed Disk.
- We also use the Storage Account's Azure region and resource group for creating the new VM.
- A virtual network for the machine to run on (which can connect to the internet), and a virtual network subnet - these are needed to connect out to the Storage Platform during the restore, and for virtual machine connectivity when the restore is completed
How to recover to Azure:
- In the Storage Platform Console, right-click the account you wish to restore and select InstantData > Share.
- On the web launch page, select Full System Recovery and click Download.
- Run the downloaded .exe file.
- In the dialog that appears, enter your account details and click Next.
- Under Target, select Azure, then click Next.
Note: To restore only the OS drive, tick Configure volume settings at the bottom, select all the OS disk volumes from the list that appears, and click Next.
- Select a Microsoft account from the list that appears, and sign in. Accept the permissions.
- Provide your hypervisor details and click Next.
- Check your recovery details and click Start. The restore process will begin.
- Restore progress will be shown in the workspace and the progress bar.
- When the restore completes, the newly created virtual machine will be stopped. Restart it from the Azure portal to access your data.
Post-restore Windows RDP
Because of the number of ways of configuring connectivity to a restored VM, the VM will initially only be assigned a private IP. There are two options if you want to RDP to the restored machine:
- Assign a public IP to the VM: https://docs.microsoft.com/en-us/azure/virtual-network/associate-public-ip-address-vm
- Create a VPN into Azure in order to access the VM: https://docs.microsoft.com/en-us/azure/vpn-gateway/create-routebased-vpn-gateway-portal