SQL Server Backups to Azure, Part 1: Introduction

Gone to Cloud!

I’ve said it before, and I say it again: Understanding how database backups and restores work is one of the more important topics for DBAs to understand. This time we’ll approach the topic from the cloud, and more precisely, from the Azure perspective. Why cloud perspective, you might as? For one simple reason. Even if you’re not (yet) running your SQL Server workloads in Azure, it doesn’t mean that you can’t make use of it for other purposes, such as backups. And while the idea of placing your data into Azure, or into any other cloud platform, might still seem scary to some, I want to help put your minds at ease. To accomplish this, I’ll just point you to this fine piece of documentation describing the Azure infrastructure security. I think you’ll find it quite satisfying.

As there’s quite a few topics to cover with database backups to Azure, I have split the details into 4 separate posts. You’re now reading Part 1, the introduction.

What I will and won’t cover?

These post will focus on two different methods for backing up to Azure. First we’ll look at how you’ll do a scripted backup using my all-time favorite method, Ola Hallengrens’ Backup Solution. After that, we’ll take a look at SQL Server Managed Backup that was introduced with SQL Server 2014.

What I will not cover is the option to take snapshots in Azure, mostly because this would require you to have all your data also in a Blob Storage, and for now, we’re just focusing on backups.

What you need to backup to Azure

Not all that much, really. You need to have an Azure Account, which you can create for free. And then you have to create a Storage Account to host your Block Blob containers. Azure Block Blob storage is a storage solution that is specifically designed, among other things, for storing backups. So that is what we will be setting up as well.

But first, let’s take a step backward and consider…

Why backup to azure?

Like pretty much with everything else related to cloud, I like to approach this topic from the perspective of availability and costs. If you are looking for a cost-effective way to store backups that also provide geo-redundancy alongside encryption, auditing, etc. it’s pretty difficult to beat the cloud in that competition. In fact, I dare to argue that building an equally secure, highly available and scalable solution in on-premises for the same cost would be impossible.

Let’s start with the SLAs, which in the case of backups tends to be rather important. In this matter, Azure puts quite (literally) big numbers on the table, starting with 11 9’s for a Locally Redundant Storage and up to 16 9’s with Geographically Redundant Storage. That’s a lot of nines, for sure.

Data Redundancy Options in Azure
Redundancy optionSLA
Locally Redundant Storage (LRS)Provides at least 99.999999999% (11 9’s) durability of objects over a given year.
Zone Redundant Storage (ZRS)Provides at least 99.9999999999% (12 9’s) durability of objects over a given year.
Geographically Redundant Storage (GRS)Provides at least 99.999999999999% (16 9’s) durability of objects over a given year
Read-Access Geographically Redundant Storage (RA-GRS)Sames as above + 99.99% read availability by allowing read access from the second region used in GRS

Full details of the storage account redundancy options can be found from Microsoft Azure documentation.

Blob Storage Pricing

How about the pricing, then? If you’re lucky enough to have geo-redundant, enterprise class storage, you probably know that those are some expensive and complex beasts. The other thing with the on-premise setup is that you’re not just paying for the terabytes given, but the for the whole infrastructure, which also needs to be built and managed by someone.

Direct comparison is made a bit more difficult by the fact that enterprise class storage devices also contain multiple types of technologies, ranging from good old spinning rust to SSDs and then to some seriously fast flash drives. So let’s make an easier comparison and compare cloud storage pricing to consumer devices. With consumer grade SSDs that we all have in our laptops these days, in average we’ve seen prices of $0.20 to $0.50 per GB. However, very recently, the prices for consumer SSD devices has actually dropped to as low as $0.10 per GB. Quite affordable, I think.

Keeping in mind that we’re talking about the kind of devices you stick into your own laptop or desktop, we can safely assume that enterprise class storage costs way beyond that. So, what does Blob storage cost then? The pricing is dependent on two things, the redundancy option and the region. Since I live in North Europe, let’s look at the prices we have here.

First 50TB/month$0.18 per GB$0.022 per GB$0.01 per GB$0.0010 per GB
Next 450TB/month$0.18 per GB$0.0212 per GB$0.01 per GB$0.0010 per GB
Over 500TB/month$0.18 per GB$0.0203 per GB$0.01 per GB$0.0010 per GB

I’d call those prices fairly reasonable, considering that we’re close to consumer SSD prices for per GB, but we’re still getting nicer SLA for our investment.

And then there’s that one thing…

Moreover, when it comes to cloud, there’s one really neat thing about it. Infrastructure there is all managed by someone apart from you, or your IT staff. I, personally, feel that having someone else to do hardware maintenance, patching and resolving critical issues for me is quite a boon!

If I’ve managed to convince you on the benefits of using Azure Storage for your backups, I invite you to read the part 2, setting up Azure Storage for SQL Server backups. I would also suggest that you read the following other posts in this series:

Published by

3 responses to “SQL Server Backups to Azure, Part 1: Introduction”

  1. […] wondering why you’d like to backup data to Azure in the first place, please read the Part 1 of this series that explains some of the benefits of using Azure for […]

  2. […] If you wonder why you’d like to back up data to Azure in the first place, please read the Part 1 of this series that explains some benefits of using Azure for […]

Leave a Reply

%d bloggers like this: