How to “backup” resources in Azure

Have you ever wonder how to backup a resource in Azure in order to rebuild it in case it is accidentally deleted? Or imagine that you want to reconfigure it in other subscription/customer.

With Powershell we can do that, it is pretty straightforward and powerful. In my case, what I want to backup is an Azure Firewall, because for example I have configured the AZFirewall with multiple rules, and I want to reuse them in another subscriptions.

To do that, what we have to is to get the firewall resource ID

$AzFirewallId = (Get-AzFirewall -Name "MyFirewallName" -ResourceGroupName "MyRgName").id

Then configure a file to export the configuration:

$FileName = ".\MyResourceBackup.json"

and finally… export the JSON to the previous file:

Export-AzResourceGroup -ResourceGroupName "MyRgName" -Resource $AzFirewallId -SkipAllParameterization -Path $FileName

Take note that I have used the “SkipAllParameterization” parameter, it allows to recreate exaxtly what we have “backup” in the JSON. In case that we want to change the names to the resources we can avoid that parameter. Also it is important, that the json contains all the configurations that we have done in the service, so, we are not losing anything.

And now… how to restore them in Azure? Pretty simple as well:

New-AzResourceGroupDeployment -name "RestoreJob" -ResourceGroupName "MyRgName" -TemplateFile ".\MyResourceBackup.json"

That’s all for one resource, and what if I whant to “backup” all the resources contained in a Resource Group? You can do it as well! But in this case, you must change some of the parameters to export the file:

Export-AzResourceGroup -ResourceGroupName "MyRgName" -SkipAllParameterization -Path $FileName

You will avoid what is in the resource itself, but you will have a laaaarge JSON, with all the parameters and configurations. Then you can restore the resources with the same method explained earlier.

Also, a good point would be to configure an automation account to export all the configuration files from the portal and store them in a blob in order to have a copy of all the resources in the subscription.

Advertisement

Azure Site Recovery: Manual installation

Sometimes, deploying ASR to protect our OnPrem VM fails, so in order to solve this situation we need to connect remotely to the VM in question and install the ASR agent manually.

But, the most important point, is to get the binaries to install the agent, whether you want to protect Windows or Linux, you can navigate to the PRocess Server and get those binarires.

You can found them in the following location: %\ProgramData\ASR\home\svsystems\pushinstallsvc\repository

quick solution, quick post!

Creating a Disaster Recovery Strategy

When you’re creating a disaster recovery strategy, there are two main criteria that you need to consider: your Restore Point Objectives (RPOs) and your Restore Time Objectives (RTOs). Although these acronyms sound complex, the idea behind them is fairly straightforward. Let’s have a closer look at how your RPOs and RTOs affect your DR strategies.

Determining RPOs

To better understand what your RPO is you should ask yourself “How much data can I afford to lose if a disaster occurs?” Your RPO represents the amount of data loss that your organization is able to sustain in the event of a disaster. This can vary between organizations as well as applications. Some businesses have zero tolerance for data loss, other, can tolerate a couple days’ worth of data loss and can therefore afford to have a much higher RPO.

Determining Your RTOs

Similarly, to understand what your RTO is you should ask yourself “How long can I can afford to be without service if a disaster occurs?” They might be able to work manually for days by temporarily substituting manual paper-based actions for their normal computerized operations? It’s up to you

Building Your DR Strategy

The DR strategy you build, needs to consider the organization’s and applications’ RPOs and RTOs. The right answer for RPOs and RTOs depends on the nature of the business, the workload, and its value to the business. As you can imagine, solutions that provide low RPOs and RTOs are also typically much more costly than solutions with that allow for higher RPOs and RTOS.

In some ways, the DR strategy for a smaller business is even more important than for an enterprise. While a larger organization might be able to sustain a significant outage and pick back up again, a lengthy outage for a smaller organization might put it out of business permanently. Basing your DR strategy on your businesses RPOs and RTOs ensures that you can be up and running after a disaster with a minimum of cost.