Back up and restore Azure VMs using Azure PowerShell
სტატია
This article describes how to back up and restore an Azure VM in an Azure Backup Recovery Services vault using PowerShell cmdlets.
Azure Backup provides independent and isolated backups to guard against unintended destruction of the data on your VMs. Backups are stored in a Recovery Services vault with built-in management of recovery points. Configuration and scaling are simple, backups are optimized, and you can easily restore as needed.
Before you can back up (or protect) a virtual machine, you must complete the prerequisites to prepare your environment for protecting your VMs.
Find the Azure Backup PowerShell cmdlets available by typing the following command:
PowerShell
Get-Command *azrecoveryservices*
The aliases and cmdlets for Azure Backup, Azure Site Recovery, and the Recovery Services vault appear. The following image is an example of what you'll see. It isn't the complete list of cmdlets.
Sign in to your Azure account using Connect-AzAccount. This cmdlet brings up a web page prompts you for your account credentials:
Alternately, you can include your account credentials as a parameter in the Connect-AzAccount cmdlet, using the -Credential parameter.
If you're a CSP partner working on behalf of a tenant, specify the customer as a tenant, by using their tenantID or tenant primary domain name. For example: Connect-AzAccount -Tenant "fabrikam.com"
Associate the subscription you want to use with the account, since an account can have several subscriptions:
If you're using Azure Backup for the first time, you must use the Register-AzResourceProvider cmdlet to register the Azure Recovery Service provider with your subscription.
In the command output, the RegistrationState should change to Registered. If not, just run the Register-AzResourceProvider cmdlet again.
Create a Recovery Services vault
The following steps lead you through creating a Recovery Services vault. A Recovery Services vault is different than a Backup vault.
The Recovery Services vault is a Resource Manager resource, so you need to place it within a resource group. You can use an existing resource group, or create a resource group with the New-AzResourceGroup cmdlet. When creating a resource group, specify the name and location for the resource group.
Use the New-AzRecoveryServicesVault cmdlet to create the Recovery Services vault. Be sure to specify the same location for the vault as was used for the resource group.
Many Azure Backup cmdlets require the Recovery Services vault object as an input. For this reason, it's convenient to store the Backup Recovery Services vault object in a variable.
The output is similar to the following example, notice the associated ResourceGroupName and Location are provided.
Output
Name : Contoso-vault
ID : /subscriptions/1234
Type : Microsoft.RecoveryServices/vaults
Location : WestUS
ResourceGroupName : Contoso-docs-rg
SubscriptionId : 1234-567f-8910-abc
Properties : Microsoft.Azure.Commands.RecoveryServices.ARSVaultProperties
Back up Azure VMs
Use a Recovery Services vault to protect your virtual machines. Before you apply the protection, set the vault context (the type of data protected in the vault), and verify the protection policy. The protection policy is the schedule when the backup jobs run, and how long each backup snapshot is retained.
Set vault context
Before enabling protection on a VM, use Set-AzRecoveryServicesVaultContext to set the vault context. Once the vault context is set, it applies to all subsequent cmdlets. The following example sets the vault context for the vault, testvault.
We plan on deprecating the vault context setting in accordance with Azure PowerShell guidelines. Instead, you can store or fetch the vault ID, and pass it to relevant commands. So, if you haven't set the vault context or want to specify the command to run for a certain vault, pass the vault ID as "-vaultID" to all relevant command, as follows:
Storage Redundancy can be modified only if there are no backup items protected to the vault.
Create a protection policy
When you create a Recovery Services vault, it comes with default protection and retention policies. The default protection policy triggers a backup job each day at a specified time. The default retention policy retains the daily recovery point for 30 days. You can use the default policy to quickly protect your VM and edit the policy later with different details.
Use Get-AzRecoveryServicesBackupProtectionPolicy to view the protection policies available in the vault. You can use this cmdlet to get a specific policy, or to view the policies associated with a workload type. The following example gets policies for workload type, AzureVM.
The timezone of the BackupTime field in PowerShell is UTC. However, when the backup time is shown in the Azure portal, the time is adjusted to your local timezone.
A backup protection policy is associated with at least one retention policy. A retention policy defines how long a recovery point is kept before it's deleted.
The schedule and retention policy objects are used as inputs to the New-AzRecoveryServicesBackupProtectionPolicy cmdlet.
By default, a start time is defined in the Schedule Policy Object. Use the following example to change the start time to the desired start time. The desired start time should be in UTC as well. The following example assumes the desired start time is 01:00 AM UTC for daily backups.
You need to provide the start time in 30 minute multiples only. In the example above, it can be only "01:00:00" or "02:30:00". The start time can't be "01:15:00"
The following example stores the schedule policy and the retention policy in variables. The example uses those variables to define the parameters when creating a protection policy, NewPolicy.
Name WorkloadType BackupManagementType BackupTime DaysOfWeek
---- ------------ -------------------- ---------- ----------
NewPolicy AzureVM AzureVM 4/24/2016 1:30:00 AM
Enable protection
Once you've defined the protection policy, you still must enable the policy for an item. Use Enable-AzRecoveryServicesBackupProtection to enable protection. Enabling protection requires two objects - the item and the policy. Once the policy has been associated with the vault, the backup workflow is triggered at the time defined in the policy schedule.
მნიშვნელოვანი
While using PowerShell to enable backup for multiple VMs at once, ensure that a single policy doesn't have more than 100 VMs associated with it. This is a recommended best practice. Currently, the PowerShell client doesn't explicitly block if there are more than 100 VMs, but the check is planned to be added in the future.
The following examples enable protection for the item, V2VM, using the policy, NewPolicy. The examples differ based on whether the VM is encrypted, and what type of encryption.
To enable the protection on non-encrypted Resource Manager VMs:
To enable the protection on encrypted VMs (encrypted using BEK and KEK), you must give the Azure Backup service permission to read keys and secrets from the key vault.
To enable the protection on encrypted VMs (encrypted using BEK only), you must give the Azure Backup service permission to read secrets from the key vault.
If you're using the Azure Government cloud, then use the value ff281ffe-705c-4f53-9f37-a40e6f2c68f3 for the parameter ServicePrincipalName in Set-AzKeyVaultAccessPolicy cmdlet.
If you want to selectively back up a few disks and exclude others as mentioned in these scenarios, you can configure protection and backup only the relevant disks as documented here.
Monitoring a backup job
You can monitor long-running operations, such as backup jobs, without using the Azure portal. To get the status of an in-progress job, use the Get-AzRecoveryservicesBackupJob cmdlet. This cmdlet gets the backup jobs for a specific vault, and that vault is specified in the vault context. The following example gets the status of an in-progress job as an array, and stores the status in the $joblist variable.
Instead of polling these jobs for completion - which is unnecessary additional code - use the Wait-AzRecoveryServicesBackupJob cmdlet. This cmdlet pauses the execution until either the job completes or the specified timeout value is reached.
When you create a protection policy, it's assigned a start-time by default. The following examples show how to modify the start time of a protection policy.
PowerShell
$SchPol = Get-AzRecoveryServicesBackupSchedulePolicyObject -WorkloadType"AzureVM"$UtcTime = Get-Date -Date"2019-03-20 01:00:00Z" (This is the time that you want to start the backup)
$UtcTime = $UtcTime.ToUniversalTime()
$SchPol.ScheduleRunTimes[0] = $UtcTime$pol = Get-AzRecoveryServicesBackupProtectionPolicy -Name"NewPolicy" -VaultId$targetVault.ID
Set-AzRecoveryServicesBackupProtectionPolicy -Policy$pol -SchedulePolicy$SchPol -VaultId$targetVault.ID
Modifying retention
The following example changes the recovery point retention to 365 days.
The default value will be 2. You can set the value with a minimum of 1 and maximum of 5. For weekly backup policies, the period is set to 5 and can't be changed.
Creating Azure Backup resource group during snapshot retention
Note
From Azure PowerShell version 3.7.0 onwards, one can create and edit the resource group created for storing instant snapshots.
Azure VM backup provides a capability to selectively exclude or include disks which are helpful in these scenarios. If the virtual machine is already protected by Azure VM backup and if all disks are backed up, then you can modify the protection to selectively include or exclude disks as mentioned here.
Trigger a backup
Use Backup-AzRecoveryServicesBackupItem to trigger a backup job. If it's the initial backup, it is a full backup. Subsequent backups take an incremental copy. The following example takes a VM backup to be retained for 60 days.
The timezone of the StartTime and EndTime fields in PowerShell is UTC. However, when the time is shown in the Azure portal, the time is adjusted to your local timezone.
Change policy for backup items
You can either modify existing policy or change the policy of the backed-up item from Policy1 to Policy2. To switch policies for a backed-up item, fetch the relevant policy and back up item and use the Enable-AzRecoveryServices command with backup item as the parameter.
If you wish to stop protection, you can use the Disable-AzRecoveryServicesBackupProtection PowerShell cmdlet. This will stop the scheduled backups but the data backed up until now is retained forever.
If the protection is stopped and the backup data is retained, you can resume the protection once more. You have to assign a policy for the renewed protection. The cmdlet is same as that of change policy of backup items.
There's an important difference between the restoring a VM using the Azure portal and restoring a VM using PowerShell. With PowerShell, the restore operation is complete once the disks and configuration information from the recovery point are created. The restore operation doesn't create the virtual machine. To create a virtual machine from disk, see the section, Create the VM from restored disks. If you don't want to restore the entire VM, but want to restore or recover a few files from an Azure VM backup, refer to the file recovery section.
რჩევა
The restore operation doesn't create the virtual machine.
The following graphic shows the object hierarchy from the RecoveryServicesVault down to the BackupRecoveryPoint.
To restore backup data, identify the backed-up item and the recovery point that holds the point-in-time data. Use Restore-AzRecoveryServicesBackupItem to restore data from the vault to your account.
The basic steps to restore an Azure VM are:
Select the VM.
Choose a recovery point.
Restore the disks.
Create the VM from stored disks.
Now, you can also use PowerShell to directly restore the backup content to a VM (original/new), without performing the above steps separately. For more information, see Restore data to virtual machine using PowerShell.
Select the VM (when restoring files)
To get the PowerShell object that identifies the right backup item, start from the container in the vault, and work your way down the object hierarchy. To select the container that represents the VM, use the Get-AzRecoveryServicesBackupContainer cmdlet and pipe that to the Get-AzRecoveryServicesBackupItem cmdlet.
Use the Get-AzRecoveryServicesBackupRecoveryPoint cmdlet to list all recovery points for the backup item. Then choose the recovery point to restore. If you're unsure which recovery point to use, it's a good practice to choose the most recent RecoveryPointType = AppConsistent point in the list.
In the following script, the variable, $rp, is an array of recovery points for the selected backup item, from the past seven days. The array is sorted in reverse order of time with the latest recovery point at index 0. Use standard PowerShell array indexing to pick the recovery point. In the example, $rp[0] selects the latest recovery point.
Use the Restore-AzRecoveryServicesBackupItem cmdlet to restore a backup item's data and configuration to a recovery point. Once you identify a recovery point, use it as the value for the -RecoveryPoint parameter. In the sample above, $rp[0] was the recovery point to use. In the following sample code, $rp[0] is the recovery point to use for restoring the disk.
To restore the disks and configuration information:
If the backed VM has managed disks and you want to restore them as managed disks, we've introduced the capability from Azure PowerShell RM module v 6.7.0. onwards.
Provide an additional parameter TargetResourceGroupName to specify the RG to which managed disks will be restored.
მნიშვნელოვანი
It's strongly recommended to use the TargetResourceGroupName parameter for restoring managed disks since it results in significant performance improvements. If this parameter isn't given, then you can't benefit from the instant restore functionality and the restore operation will be slower in comparison. If the purpose is to restore managed disks as unmanaged disks, then don't provide this parameter and make the intention clear by providing the -RestoreAsUnmanagedDisks parameter. The -RestoreAsUnmanagedDisks parameter is available from Azure PowerShell 3.7.0 onwards. In future versions, it will be mandatory to provide either of these parameters for the right restore experience.
Once the Restore job has completed, use the Get-AzRecoveryServicesBackupJobDetail cmdlet to get the details of the restore operation. The JobDetails property has the information needed to rebuild the VM.
Azure Backup also allows you to use managed identity (MSI) during restore operation to access storage accounts where disks have to be restored to. This option is currently supported only for managed disk restore.
If you wish to use the vault's system assigned managed identity to restore disks, pass an additional flag -UseSystemAssignedIdentity to the Restore-AzRecoveryServicesBackupItem command. If you wish to use a user-assigned managed identity, pass a parameter -UserAssignedIdentityId with the Azure Resource Manager ID of the vault's managed identity as the value of the parameter. Refer to this article to learn how to enable managed identity for your vaults.
Restore selective disks
A user can selectively restore few disks instead of the entire backed up set. Provide the required disk LUNs as parameter to only restore them instead of the entire set as documented here.
მნიშვნელოვანი
One has to selectively back up disks to selectively restore disks. More details are provided here.
Once you restore the disks, go to the next section to create the VM.
Restore disks to a secondary region
If cross-region restore is enabled on the vault with which you've protected your VMs, the backup data is replicated to the secondary region. You can use the backup data to perform a restore. Perform the following steps to trigger a restore in the secondary region:
The output will be similar to the following example:
Output
WorkloadName Operation Status StartTime EndTime JobID
------------ --------- ------ --------- ------- -----
zonevmeus2 Restore InProgress 1/3/2022 10:27:20 AM b2298...
Cross-zonal restore is supported only in scenarios where:
The source VM is zone pinned and is NOT encrypted.
The recovery point is present in vault tier only. Snapshots only or snapshot and vault tier are not supported.
The recovery option is to create a new VM or restore disks. Replace disks option replaces source data; therefore, the availability zone option is not applicable.
Creating VM/disks in the same region when vault's storage redundancy is ZRS. Note that it doesn't work if vault's storage redundancy is GRS, even though the source VM is zone pinned.
Creating VM/disks in the paired region when vault's storage redundancy is enabled for Cross-Region Restore and if the paired region supports zones.
Replace disks in Azure VM
To replace the disks and configuration information, perform the following steps:
After you restore the disks, use the following steps to create and configure the virtual machine from disk.
Note
AzureAz module 3.0.0 or higher is required.
To create encrypted VMs from restored disks, your Azure role must have permission to perform the action, Microsoft.KeyVault/vaults/deploy/action. If your role doesn't have this permission, create a custom role with this action. For more information, see Azure custom roles.
After restoring disks, you can now get a deployment template which you can directly use to create a new VM. YOu don't need different PowerShell cmdlets to create managed/unmanaged VMs which are encrypted/unencrypted.
Create a VM using the deployment template
The resultant job details give the template URI that can be queried and deployed.
The template isn't directly accessible since it's under a customer's storage account and the given container. We need the complete URL (along with a temporary SAS token) to access this template.
First extract the template name from the templateBlobURI. The format is mentioned below. You can use the split operation in PowerShell to extract the final template name from this URL.
Attach the OS disk and data disks. This step provides examples for various managed and encrypted VM configurations. Use the example that suits your VM configuration.
Non-managed and non-encrypted VMs - Use the following sample for non-managed, non-encrypted VMs.
Non-managed and encrypted VMs with Microsoft Entra ID (BEK only) - For non-managed, encrypted VMs with Microsoft Entra ID (encrypted using BEK only), you need to restore the secret to the key vault before you can attach disks. For more information, see the Restore an encrypted virtual machine from an Azure Backup recovery point. The following sample shows how to attach OS and data disks for encrypted VMs. When setting the OS disk, make sure to mention the relevant OS type.
Non-managed and encrypted VMs with Microsoft Entra ID (BEK and KEK) - For non-managed, encrypted VMs with Microsoft Entra ID (encrypted using BEK and KEK), restore the key and secret to the key vault before attaching the disks. For more information, see Restore an encrypted virtual machine from an Azure Backup recovery point. The following sample shows how to attach OS and data disks for encrypted VMs.
Non-managed and encrypted VMs without Microsoft Entra ID (BEK only) - For non-managed, encrypted VMs without Microsoft Entra ID (encrypted using BEK only), if source keyVault/secret are not available restore the secrets to key vault using the procedure in Restore an non-encrypted virtual machine from an Azure Backup recovery point. Then execute the following scripts to set encryption details on the restored OS blob (this step isn't required for a data blob). The $dekurl can be fetched from the restored keyVault.
The following script needs to be executed only when the source keyVault/secret isn't available.
Non-managed and encrypted VMs without Microsoft Entra ID (BEK and KEK) - For non-managed, encrypted VMs without Microsoft Entra ID (encrypted using BEK & KEK), if source keyVault/key/secret are not available restore the key and secrets to key vault using the procedure in Restore an non-encrypted virtual machine from an Azure Backup recovery point. Then execute the following scripts to set encryption details on the restored OS blob (this step isn't required for a data blob). The $dekurl and $kekurl can be fetched from the restored keyVault.
The script below needs to be executed only when the source keyVault/key/secret isn't available.
Managed and encrypted VMs with Microsoft Entra ID (BEK only) - For managed encrypted VMs with Microsoft Entra ID (encrypted using BEK only), attach the restored managed disks. For in-depth information, see Attach a data disk to a Windows VM using PowerShell.
Managed and encrypted VMs with Microsoft Entra ID (BEK and KEK) - For managed encrypted VMs with Microsoft Entra ID (encrypted using BEK and KEK), attach the restored managed disks. For in-depth information, see Attach a data disk to a Windows VM using PowerShell.
Managed and encrypted VMs without Microsoft Entra ID (BEK only) -For managed, encrypted VMs without Microsoft Entra ID (encrypted using BEK only), if source keyVault/secret are not available restore the secrets to key vault using the procedure in Restore an non-encrypted virtual machine from an Azure Backup recovery point. Then execute the following scripts to set encryption details on the restored OS disk (this step isn't required for a data disk). The $dekurl can be fetched from the restored keyVault.
The script below needs to be executed only when the source keyVault/secret isn't available.
Managed and encrypted VMs without Microsoft Entra ID (BEK and KEK) - For managed, encrypted VMs without Microsoft Entra ID (encrypted using BEK & KEK), if source keyVault/key/secret are not available restore the key and secrets to key vault using the procedure in Restore an non-encrypted virtual machine from an Azure Backup recovery point. Then execute the following scripts to set encryption details on the restored OS disk (this step isn't required for data disks). The $dekurl and $kekurl can be fetched from the restored keyVault.
The following script needs to be executed only when the source keyVault/key/secret isn't available.
Push ADE extension.
If the ADE extensions aren't pushed, then the data disks will be marked as unencrypted, so it's mandatory for the steps below to be executed:
For VM with Microsoft Entra ID - Use the following command to manually enable encryption for the data disks
Ensure to manually delete the JASON files created as part of encrypted VM restore disk process.
Restore files from an Azure VM backup
In addition to restoring disks, you can also restore individual files from an Azure VM backup. The restore files functionality provides access to all files in a recovery point. Manage the files via File Explorer as you would for normal files.
The basic steps to restore a file from an Azure VM backup are:
Select the VM
Choose a recovery point
Mount the disks of recovery point
Copy the required files
Unmount the disk
Select the VM (when restoring the VM)
To get the PowerShell object that identifies the right backup item, start from the container in the vault, and work your way down the object hierarchy. To select the container that represents the VM, use the Get-AzRecoveryServicesBackupContainer cmdlet and pipe that to the Get-AzRecoveryServicesBackupItem cmdlet.
Use the Get-AzRecoveryServicesBackupRecoveryPoint cmdlet to list all recovery points for the backup item. Then choose the recovery point to restore. If you're unsure which recovery point to use, it's a good practice to choose the most recent RecoveryPointType = AppConsistent point in the list.
In the following script, the variable, $rp, is an array of recovery points for the selected backup item, from the past seven days. The array is sorted in reverse order of time with the latest recovery point at index 0. Use standard PowerShell array indexing to pick the recovery point. In the example, $rp[0] selects the latest recovery point.
OsType Password Filename
------ -------- --------
Windows e3632984e51f496 V2VM_wus2_8287309959960546283_451516692429_cbd6061f7fc543c489f1974d33659fed07a6e0c2e08740.exe
Run the script on the machine where you want to recover the files. To execute the script, you must enter the password provided. After the disks are attached, use Windows File Explorer to browse the new volumes and files. For more information, see the Backup article, Recover files from Azure virtual machine backup.
Unmount the disks
After the required files are copied, use Disable-AzRecoveryServicesBackupRPMountScript to unmount the disks. Be sure to unmount the disks so access to the files of the recovery point is removed.
WorkloadName Operation Status StartTime EndTime
------------ --------- ------ --------- -------
V2VM Restore InProgress 26-Apr-16 1:14:01 PM 01-Jan-01 12:00:00 AM
The last command triggers an alternate location restore operation to create a new VM in Target_RG resource group as per the inputs specified by parameters TargetVMName, TargetVNetName, TargetVNetResourceGroup, TargetSubnetName. This ensures that the data is restored in the required VM, virtual network and subnet.
Learn about Azure Backup before learning to implement Recovery Vaults and Azure Backup Policies. Learn to implement Windows IaaS VM recovery, perform backup and restore of on-premises workloads, and manage Azure VM backups.