This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(224.00000000000003, 19%, 31%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJD%3C/text%3E%3C/svg%3E)
Hello everyone
I'm currently researching the Azure Backup and Azure Site Recovery mechanisms and intend to prepare our infrastructure.
As far as I'm concerned, I'd use the Azure Backup to backup and restore individual VMs and VMs part of an availability zone or availability set.
The Azure Site Recovery feature would be used to quickly switch to another Azure region by restoring multiple Azure VMs (and Resource groups, vnets, subnets..) to another Azure region.
Unfortunately, the Azure Site recovery cannot backup and restore NSG. So in the event of restoring my Azure Site to another region, I'd need to manually (depending on my preparation of course) create each NSG and assign it to the correct subnet.
To ensure a rapid and smooth failover, my idea was to prepare all the target regions with:
Resource Groups
Virtual networks (incl. Network mapping)
Subnets
NSG
And in the event of a failover, the Site recovery, the target region would be ready and my infrastructure up and running as soon as it has been restored.
Is there anything else, I need to prepare in my target regions?
Are there any other resources the Recovery Services Vault cannot backup/restore?
How do you see this approach?
Am I missing any capabilities able to simplify this?
Is there a better way to prepare myself for a failover?
Thanks for your help in advance!
Best regards
Joel
@Joel Dietshci Your questions are highly subjective. It is completely dependent on what you’re trying to achieve, along with the type of target resources.
For example, you could use Azure Backup to restore in another region, since Azure Backup now supports Cross-Region Restore. But of course, that is subjective to target RTOs, RPOs, and SLAs.
As you have discovered, Azure Site Recovery (ASR) does not currently support protecting/replicating any non-Compute objects (ie. VNets, NSGs, ASGs, UDRs, Ultra Disks, etc.). That means you need to also think about your production process for managing updates. For example, if someone makes an update to an NSG in RegionA, how will those changes also be applied in RegionB (the DR region)?
In a proper DR architecture, you should think about, and plan, for all of the other elements required to make the failover happen with minimal issues. Will you be deploying a pair of VMs as domain controllers in the DR region in advance? How will you manage updates to DNS? What about DR for the DR? If the systems are failed over for a specific period of time, do you need to be re-configured for Backup, DR (back to the primary region), monitoring, patching, etc.?
Like I mentioned at the beginning, all of this is highly subjective to your environment, resource types, etc. This is all a part of proper planning and BCDR architecture you should be doing.
Ref: About networking in Azure VM DR
With that I keep this conversation open for other community members on this platform to share their experiences.
@SadiqhAhmed-MSFT Thank you for your time.
It would of course be necessary to have essential systems up to make a site replication work. For systems further down the priority list I was thinking on using scripts to deploy the non-Compute objects as pre-actions in the recovery plan. If the machines are grouped in the recovery plan at the resource group level, a script could identify all the resources that need to be created and deploy these, as long as the codebase is up to date with recent changes.
I try to avoid having my target infrastructure ready and waiting for the compute objects as the target regions's sole purpose is of disaster recovery. Would such an approach be advisable? Or is it recommended to have the target region practically up and running beforehand? Or should the overall infrastructure already span across multiple regions to replicate into a fully functioning part of the infrastructure where other services are already provided from?
@Joel Dietshci It is always recommended to prepare the target environment and keep it ready. When target environment is ready, it doesn't mean your VMs are up and running unless you trigger a failover. For your target environment you will be billed for the underlying storage resources but not for compute.
Thank you for these answers. The rest of it will be part of my individual research.