Showing posts with label Azure. Show all posts
Showing posts with label Azure. Show all posts
Configuring backups on VM creation in Azure
In this blog post I will be detailing how to enable virtual machine (VM) level backups during VM creation in Azure. This is a great function as it enables you to automatically create backups of your VM's directly within the Azure portal while creating a new VM.
You can also use the same basic steps below in order to create backups on your existing VM's by selecting the VM and Backup tab on your existing VM's within the Azure portal.
1. Log into the Azure portal and select New - Windows Server 2016 VM (or any other version that you are requiring). Select your relevant basic settings and continue:
2. Select the size of the VM that you would like to create and continue:
3. Under the backup tab, select "Enabled". You can now specify your new or existing "recovery services" or backup vault. This will be a storage location for your VM level backups. You will also be able to select an existing or new resource group:
4. The next step is to configure the backup policy itself, this can be done by selecting "Backup policy" and creating your policy based on your individual or compliance needs.
5. After this has been done you can complete the new VM wizard and your new VM will be provisioned in Azure. Your VM backups will automatically start running based on your policy.
Please note: The steps 3 & 4 can also be completed on an existing VM in order to create an automatic backup procedure. A recovery services vault will also be required for storage.
Once you have completed these steps your backups will be handled by Azure and recovery points will become available under the backup and restore tab of the individual VM's. You can use this to perform point in time restores of your VM's in any backup restore scenarios.
I hope that you have found this article interesting and can enable this on your next VM build!
Source: Please read the official Microsoft documentation for further information:
Why using availability sets is critical in Azure
Yesterday we learnt that using availability sets are more than just a recommended best practise in Microsoft Azure. As Microsoft had scheduled maintenance updates for the Spectre/Meltdown vulnerability for January 10th these were suddenly scrambled into action due to the public announcement of the issue, and updates automatically completed from January 3rd into January 4th without any advance warning.
These updates were obviously critically required and absolutely the right decision from Microsoft but it did also create issues for customers that had production servers rebooted during business hours. Of course these issues did not impact customers that were already utilising availability sets within their infrastructure for high availability.
Availability sets consist of update domains that two or more virtual machines (VM's) are connected to when originally provisioned. These update domains are updated and rebooted at different times thus preventing downtime across VM's that have been provisioned in them creating a high availability redundancy across your applications.
This is useful in the three scenarios - unplanned hardware maintenance events, an unexpected downtime or a planned maintenance event. Each VM in an availability set is placed in an update domain (UD) and a fault domain (FD). A fault domain is used for shared power and network at the rack level. Please read about this more in further detail in the official documentation linked at the bottom of this article.
Microsoft also recommends utilising managed disks when provisioning new VM's in availability sets (or in general) as this creates better availability of disks by isolating them using different storage clusters, as well as creating less overhead management of storage accounts associated to various VM's that you are provisioning.
It is also a good idea to add VM's of different application tiers into their own availability sets as this creates better redundancy for your applications. For example you can place front end web servers in one availability set and back end database servers into a separate availability set. This creates a situation that you will have one server from each tier online at the same time preventing downtime to your application.
To sum it up availability sets need to be thought about and addressed in planning of your architecture and should really be implemented for any business critical VM's or applications in order to prevent any downtime as some experienced yesterday.
Subscribe to:
Posts (Atom)
