This is my tenth post in a series of entry-level posts, as suggested by Tim Ford (b|l|t) in this challenge.
I have not set any scope for the topics of my, at least, twelve (12) posts in this blog category of mine, but I can assure, it’ll be focused on SQL Server stuff. This time it’s going to be about how to backup your VM’s in Azure with the Recovery Services Vaults.

Previous Posts in Entry Level Serie:

• Testing Your #SSAS Cubes w/ Visual Studio
• Creating a Striped Disk on Your Azure VM
• How to Query SSASMD using #DAX
• How to Quickly Remove Snippet Line Numbers in Visual Studio
• SSAS Compare by Red-Gate
• Filtering Tables in #SQLServer Management Studio
• Gemino!
• A Hello World Custom Assembly in SSAS
• Permission Scope in Analysis Services

Introduction

Finding yourself up that creek w/out a paddle, is not something you should strive to achieve. Hence, do your backups so that when that brownish thinghy hits the rotating cooling thingy, you are able to dodge the bullet in style.

Via the Azure Portal this is actually quite an easy setup. We begin by defining a Recovery Services Vault. If the offering is not immediately available, search for it like this:

You can select to toggle it as favorite, you may want to check back regularly to see if your backup job is running as expected.

Clicking the Recovery Services Vaults presents you with the next dialog. Here you can view all the services you may have running. You can also Add new ones which we are going to do by clicking the Add button.

Next dialog lets us set a couple of basics about the service, such as name, resource group and do keep in mind which subscription you are working on, if you have more than one available. Click Create when all attributes are in place.

Once the deployment is complete, you’ll see the notifier alerting you, that deployment has been successful.

Back to the Recovery Services Vaults, where we can Refresh and observe the newly created Recovery Services Vault.

Now it’s time to add some server to be backed up. By clicking the newly created Recovery Services Vault, Test-Recovery-Service in my example, we get to the overview of the service. Here, we select the option/pane Backup:

In this wizard we are presented with three (3) areas of configuration; First we need to decide if it’s in Azure or On-Premises. By selecting Azure, we are left with only Virtual Machine as the only option for the backup. On-Premises has more options, SQL Server, Sharepoint and Hyper-V VM’s among others. This example will be about Azure VM’s, hence we selected accordingly.

Step 2 is about the backup policy, or in other words frequency and retention. I am going with the default settings here, but options are great as you can configure retention range for weekly, monthly and yearly backups in parallel.

When a new backup policy is created, it automatically becomes an option in other Recovery Services Vaults.

In Step 3 we select which VM’s are included in the Vault.

 

Finally we check everything is as we want it to be and click OK.

Going back to the overview, we can now observe that the job has been scheduled according to our backup policy definition. Also observe that the backup usage is right where you want it to be, to track and monitor.

And by clicking the “Azure Virtual Mach…” we get the following overview/status.

But when the job has completed, at the specified time, you will see the time stamps as to when the backups were executed.

In my humble opinion, this is so dead simple and easy it’s almost scary – I fear I am missing something, but I seriously doubt it. You might want to keep an eye on spending though, especially if you set up a high frequent backup schedule with a long retention. It can become pricy, but is very reasonable for small installations like this.

This is my eighth post in a series of entry-level posts, as suggested by Tim Ford (b|l|t) in this challenge.
I have not set any scope for the topics of my, at least, twelve (12) posts in this blog category of mine, but I can assure, it’ll be focused on SQL Server stuff. This time, it’s a little trick on how to make life easier for SQL Server on an Azure Virtual Machine. This tip applies to standard on-premises setups as well, although it’s not always as easy as running a PowerShell script to magically conjure a bunch of disks, on your own servers.

Prerequisites

In order to leverage this tip, you will need an Azure VM (or an on-premises server, where you can add disks) and some administrative permissions.

Things to do in Azure

First of all, you need to add the Data Disks to you Virtual Machine. This can be done in two ways; (1) You can do this through the Portal. Select the VM you want to work with, click All Settings->Disks->Attach New.

This will bring you to the final dialog, where you punch in the specifics for your new disk.

Or you can do it using Powershell, using Add-AzureDataDisk.

Windows Server

Once the disks have been attached to the VM, it’s time to do some magic in Windows. Mind you, a long series of screenshots. First, you’ll have to create a Storage Pool, next configure a Virtual Disk and finally a Volume (Disk).

It all begins with in the Server Manager, where this illustration should take you through the steps to create a Storage Pool:

Once the Storage Pool is created, you head on to create the Virtual Disk:

Finally you need to create a new Volume:

Benefits

The obvious benefit is throughput. The more disks you add to your stripe, the more theoretical throughput you’ll get. As an example, is ran a very quick test, using CrystalDiskMark

Beware: Do not use the installer, as it contains adware. Get the portable edition (.zip).

As displayed in above screen shots, the single Azure Standard Storage VHD gives you (as promised) about 500 IOPS. Striping eight (8) of those, will roughly give you eight (8) times the IOPS, but not same magnitude of [MB/s] apparently. Still, the setup is better off, after, rather than before!

Do mind, that there are three levels of storage performance; P10, P20 and P30. For more information, read this.