I just lately labored up a script for a buyer to create a snap-and-restore of an present VM utilizing PowerShell. The script requires solely three parameters: VM identify, snapshot identify, and motion (backup or restore). The logic behind the script was across the snapshot identify. When offering that data and performing the safety (backup), a collection of snapshots can be created with the present identify of the disks added by .snap.<snapshotname> in the identical resource group of the unique VM.
The identical holds when a restore was requested. Nevertheless, at the moment the script would create a managed disk referred to as <OriginalDiskName>.<Snapshotname> and the final step can be the substitute of all VMs disks with the newly created disks. We might maintain the unique disks round, so it could possibly be used as plan B in case of an surprising drawback that will require us to revive the VM to the unique state.
The identical buyer was utilizing the script to guard and restore greater than 30-plus VMs throughout the identical useful resource group, and the efficiency wasn’t ultimate, for apparent causes. The script is linear, and it will execute one machine at a time, and having 30 VMs with a number of disks would take a few hours to finish.
The second grievance was associated to the method. Though a PowerShell script saves plenty of time and constantly performs all validation, they needed one thing easier and resilient. Primarily based on the necessities, I needed to implement two modifications: First, transfer the present script to Azure Automation to create the snapshot — Azure Automation is great and makes it extra accessible for anybody to make use of it. Nevertheless, I used to be saving JSON files on the file system, so we needed to incorporate Storage Accounts to maintain that data in a central location. The second change was across the efficiency, and the one method was utilizing multithreading, which isn’t that easy as a result of it requires some refactoring of the present script.
Understanding the runbook operation
The aim is to permit the operations crew to have the ability to use an Azure Automation runbook to create a snapshot of all VMs in any given useful resource group and be capable of restore to that cut-off date when required as nicely.
We’re going to work on a situation just like the picture under. The present VM (apvm) has 4 disks — one for the working system and the opposite three are knowledge disks. We additionally created two snapshots referred to as Time0 and AP6. A snapshot is only a snapshot useful resource in the identical useful resource group, and they’ll have the unique identify added by .snap.Time0 or .snap.AP6.
To make it possible for the script is working as anticipated, I’ve created a special sort of Storage Account sort for every knowledge disk and configured totally different Host Caching settings to make it possible for when restoring a snapshot these settings are preserved.
Our operations crew will deploy a patch on the utility degree on all VMs within the useful resource group, and earlier than beginning the method, we have to create a snapshot. We’re going to name it Patch5, and we advocate to deallocate all VMs earlier than working the runbook.
When working the runbook, the operator must outline the useful resource group identify, snapshot identify, and by default, the runbook goes to again up. Restore is disabled.
After the runbook is submitted, we are able to test the standing by taking a look at any of the tabs obtainable. Within the instance, we’re monitoring the output of the script, we offer an output for every important process being accomplished, and on the finish of the script, we additionally present the overall time to execute all assignments.
The results of the operation might be seen on the useful resource group degree when looking for the snapshot identify (patch5 in our case), and we’ll see all disks related to all VMs with their snapshots.
Restoring a snapshot
Primarily based on the earlier part, we all know that every one disks related to the working VM have the AP6 identify. After making use of all patches, we realized that was an enormous mistake, and we have to restore to the purpose earlier than the precise change, and that’s our snapshot Patch5.
The script was created to suit the necessities of a selected buyer, however you’ve got all of the instruments to implement it in your atmosphere, and you probably have any particular wants, please be at liberty to alter it.
Watch for the completion of the runbook. Take into account that we’re utilizing multithreading, which implies all of the VMs will run on the identical time. The outcomes are simple to be seen within the Azure Portal, test the disks of any given VM on the useful resource group, and the consequence can be disks being hooked up to the VM having the snapshot identify (in our case patch5).
The place is the script? I shared the code in GitHub, and you’ll click on here to get the entire code. The code was tailored from a daily PowerShell script to PowerShell Workflow, which permits the multithreading functionality. Once more, the script was created primarily based on the necessities of a single buyer to make use of Azure Automation to create a snapshot of all Azure digital machines. Nevertheless, you should use the identical code to implement it in your Azure subscription and carry out modifications to adapt to your wants.
Featured picture: Shutterstock