Service updates in Site Recovery
This article provides an overview of Azure Site Recovery updates, and describes how to upgrade Site Recovery components.
Site Recovery publishes service updates on a regular basis. Updates include new features, support improvements, component updates, and bug fixes. In order to take advantage of the latest features and fixes, we recommend running the latest versions of Site Recovery components.
Updates support
Support statement for Azure Site Recovery
We recommend always upgrading to the latest component versions:
With every new version 'N' of an Azure Site Recovery component that's released, all versions below 'N-4' are considered to be out of support.
Important
Official support is for upgrading from > N-4 version to N version. For example, if you're running you are on N-6, you need to first upgrade to N-4, and then upgrade to N.
Links to currently supported update rollups
Review the latest update rollup (version N) in this article. Remember that Site Recovery provides support for N-4 versions.
Component expiry
Site Recovery notifies you of expired components (or nearing expiry) by email (if you subscribed to email notifications), or on the vault dashboard in the portal.
- In addition, when updates are available, in the infrastructure view for your scenario in the portal, an Update available button appears next to the component. This button redirects you to a link for downloading the latest component version.
- Vaults dashboard notifications aren't available if you're replicating Hyper-V VMs.
Emails notifications are sent as follows.
| Time | Frequency |
|---|---|
| 60 days before component expiry | Once bi-weekly |
| Next 53 days | Once a week |
| Last 7 days | Once a day |
| After expiry | Once bi-weekly |
Upgrading outside official support
If the difference between your component version and the latest release version is greater than four, this is considered out of support. In this case, upgrade as follows:
- Upgrade the currently installed component to your current version plus four. For example, if your version if 9.16, then upgrade to 9.20.
- Then, upgrade to the next compatible version. So in our example, after upgrading 9.16 to 9.20, upgrade to 9.24.
Follow the same process for all relevant components.
Support for latest operating systems/kernels
Note
If you have a maintenance window scheduled, and a reboot is included in it, we recommend that you first upgrade Site Recovery components, and then proceed with the rest of the scheduled activities in the maintenance window.
Before upgrading operating system/kernel versions, verify if the target version is supported Site Recovery.
- Azure VM support.
- VMware/physical server support
- Hyper-V support.
Review available updates to find out what you want to upgrade.
Upgrade to the latest Site Recovery version.
Upgrade the operating system/kernel to the required versions.
Reboot.
This process ensures that the machine operating system/kernel is upgraded to the latest version, and that the latest Site Recovery changes needed to support the new version are loaded on to the machine.
Azure VM disaster recovery to Azure
In this scenario, You can allow Site Recovery to manage updates as follows:
- During the enable replication process.
- By setting the extension update settings inside the vault.
If you want to manually manage updates, you may choose one of the following options:
When a new agent update is available, Site Recovery provides a notification in the vault towards the top of the page. In the vault > Replicated Items, click this notification at the top of the screen:
New Site Recovery replication agent update is available. Click to install ->
Select the VMs for which you want to apply the update, and then click OK.On the VM disaster recovery overview page, you will find the 'Agent status' field which will say 'Critical Upgrade' if the agent is due to expire. Click on it and follow the subsequent instructions to manually upgrade the virtual machine.
VMware VM/physical server disaster recovery to Azure
- Based on your current version and the support statement, install the update first on the on-premises configuration server, using these instructions.
- If you have scale-out process servers, update them next, using these instructions.
- To update the Mobility agent on each protected machine, refer to this article.
Reboot after Mobility service upgrade
A reboot is recommended after every upgrade of the Mobility service, to ensure that all the latest changes are loaded on the source machine.
A reboot isn't mandatory, unless the difference between the agent version during last reboot, and the current version, is greater than four.
The example in the table shows how this works.
| Agent version (last reboot) | Upgrade to | Mandatory reboot? |
|---|---|---|
| 9.16 | 9.18 | Not mandatory |
| 9.16 | 9.19 | Not mandatory |
| 9.16 | 9.20 | Not mandatory |
| 9.16 | 9.21 | Mandatory. Upgrade to 9.20, then reboot before upgrading to 9.21. |
Hyper-V VM disaster recovery to Azure
Between a Hyper-V site and Azure
- Download the update for the Azure Site Recovery Provider.
- Install the Provider on each Hyper-V server registered in Site Recovery. If you're running a cluster, upgrade on all cluster nodes.
Between an on-premises VMM site and Azure
- Download the update for the Azure Site Recovery Provider.
- Install the Provider on the VMM server. If VMM is deployed in a cluster, install the Provider on all cluster nodes.
- Install the latest Azure Recovery Services agent (MARS for Azure Site Recovery) on all Hyper-V hosts or cluster nodes.
Between two on-premises VMM sites
- Download the latest update for the Azure Site Recovery Provider.
- Install the latest Provider on the VMM server managing the secondary recovery site. If VMM is deployed in a cluster, install the Provider on all cluster nodes.
- After the recovery site is updated, install the Provider on the VMM server that's managing the primary site.
Next steps
Follow our Azure Updates page to track new updates and releases.