Backing up my Azure workload to Azure

AzureI’ve looked at using Azure to back up on-premise workloads in a couple of posts now (Azure Backup for smaller loads, and Azure Backup Server for things like a Hyper-V cluster), so I think it’s time I looked at backing up workloads that are already running from Azure. I’m going to look at backing up Virtual Machines and storage accounts – there’s not much more I store in Azure that would need backing up.

I’m going to take a quick look at the options for storage accounts, virtual machines and databases.

So the first question must be “Where do we back this up to?” – you could make a case for backing it up to an on-premise backup server, or even to a competing cloud provider, using one of many products designed for “backing up your Azure and Office 365 data”. I see backups as having three purposes really – to get you up and running again after a disaster (such as losing your on-premise servers, or in this case your Azure workload being irreversibly lost),  to recover from user error, and finally (becoming more and more important these days) to recover from ransomware/encryption based attacks. I back up my Azure workload to Azure because I feel the way it is configured – with availability zones, geo-redundant data etc – that it’s highly unlikely that my backup will disappear along with my workload. I’d also think there’s much more chance of something going wrong with my backup if it was stored on-premise rather than in Azure.

Storage Accounts

If you’ve configured zone or geo replication for the storage account you’re fairly safe to say your data isn’t going to vanish by any sort of local disaster at a Microsoft datacentre, but you’d still be vulnerable to the data being modified or deleted, either accidentally by an authorised user or through some more malicious means. If you scroll down the menu for your storage account you should see Data protection.

Data protection options for a storage account

So the options you have available are:

  • Point-in-time restore for containers: This will allow you to restore containers to an earlier state – it requires all the other options except blob soft-delete to be enabled for this to work.
  • Soft delete for blobs: This allows you to recover blobs that were marked for deletion, even if they’ve been overwritten.
  • Soft delete for containers: Similar thing, you can recover containers that have been marked for deletion.
  • Versioning for blobs: Basically like the previous versions feature on a Windows Server, you can restore previous versions of blobs
  • Blog change feed: Keeps track of changes made to blobs in your account.

I’m not 100% sure on the cost implications but I’d expect most of these to incur usage charges – as you’d be storing additional data. If your data doesn’t change much then it’d be minimal.

If you’re going to implement any of these I’d recommend giving the Microsoft Docs a quick read through as it will cover everything in much more detail than I have.

Virtual Machines

If you click on one of your virtual machines in the Azure Portal and have a look down the menu you should notice two items that will be helpful here – Backup, and Disaster recovery. I’m going to cover Backup in detail and then quickly touch on DR.

Virtual machine backup uses Azure Recovery Service Vaults. If you’ve looked at my posts on backing up on-premise workloads to Azure you’ll be familiar with RSVs. The charges for an RSV are covered here but essentially you pay a fixed rate per instance (based on its size) and then also for the storage.

Configuring backup for a virtual machine – pick your vault and your backup policy

If you’ve already got a vault set up you can use this if you wish, or you can create a new one. The default backup policy is a daily backup, when I’ve tried it I’ve been given 4:30am (UTC) – I’m not sure if this is the default for everyone or if it randomises it to spread the load – with a 2 day instant recovery snapshot, and the backups are retained for 6 months (180 days).

If you want to change this, you can click Create a new policy and you’ll get the Backup policy screen to work through:

Creating a new backup policy

You can pick Daily or Weekly for the frequency – Weekly will let you pick which day(s) of the week you back up, and you can configure the retention policy too. Once you’re happy click OK to set the policy, then Enable Backup.

Now you’ll get some backup and recovery options if you visit the Backup page – notably Backup now, Restore VM and Undelete. If you’ve deleted the Virtual Machine and need to get it back, you won’t be able to get to this page via the Virtual Machine – don’t worry, you can go into your Recovery Services Vault, click on Backup Items, then Azure Virtual Machine, and you’ll see the exact same set of options as below where you can undelete the VM.

The Backup screen once you’ve configured Backup.

The other option you have with Virtual Machines is to configure Azure Site Recovery – this will replicate your VM to another Azure region and you can switch over in the event of an outage in the original region. More detail on this can be found on the Microsoft Docs.

Databases

Azure SQL Databases are backed up daily automatically, simply click the Restore button and pick the backup you want to restore. Not much else to say on these!

Restoring a SQL Database

 

Further Reading:

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.