This is the second part of a 4 part blog post series about backing up SQL Server to Azure. If you’re 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 backups.
In this post we’ll look at how to setup your very own Storage Account and how to use some of the nice security features in it.
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 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 do 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.
The first day of the actual conference was exciting. The Day 1 Keynote by Joseph Siroshi (Microsoft Corporate Vice President, Data Group) was something that I found especially interesting as the examples of data strategy were derived from the healthcare industry, which happens to be the same industry I’m involved with. The funny thing was that we were discussing how technology will shape the future of healthcare industry during the breakfast. And then, less than hour later we’re shown how analytics provided by the Microsoft Data Platform can analyze decoded human genome to provide list of possible health problems. How crazy is that?
In previous post, Part 1: Creating Azure Network and Storage, we set up your Azure account ready for two virtual machines that’ll be the backbone of your own testing environment. One of these servers will run the Active Directory and the other one will host your SQL Server 2012 instance. The Active Directory server is really optional, you can do a test environment without it but I prefer test environments that mimic the production.
Now that you’ve setup your Azure account we can get started on building the test environment. First thing you should do is to create a Virtual Azure Network, this will be used for connectivity between your servers. Creating a Network is quite straightforward business. Choose Networks and then Create A Virtual Network.
Going back a few years (and then some), creating your own test environments used to be difficult requiring both time and hardware resources. Then came the different virtualization solutions, which made it bit more easier but still requiring decent amount of hardware resources and a little bit of time. With the arrival of Azure and other cloud-based solutions, things finally got considerably easier. Now we finally had the ability to set up a test environments quickly and easily.