SQL Server managed backups to Azure

Problem

Ive been tasked by management to investigate SQL Server 2014 managed backups to AZURE, so that development teams around the country can backup their own servers without needing a full time DBA to manage that process. We have offices around the world and we are hoping to be able to put database backups in the cloud, so that the different offices don't need to worry about the storage or the backup process.

Solution

SQL Server backups to a blob service were first introduced with SQL 2012 Service Pack 1, CU2. The functionality was termed backup to a URL and allowed DBAs to backup to a SQL Azure blob by specifying credentials and a URL to use. With that solution SQL Server DBAs determine how often to run the backups and log backups much like they are currently doing.

SQL Server 2014 offers that service and also extends the functionality to be a fully managed backup solution for user databases; system databases cannot be backed up with SQL 2014 managed backups. The major difference between backing up to a URL and SQL managed backups is that the SQL Server itself is managing the entire backup process including times of the day and frequency. SQL Managed backups in SQL 2014 offer only 2 configurable settings. The retention period in days and the databases which will be backed up. Microsoft completely manages the rest of the process including the frequency of Full backups and the frequency of transaction log backups. SQL 2016 offers additional settings, but that will not be covered here. There is also a user interface in SQL 2014 Management Studio, but there are a number of restrictions to its use and it will not be covered in this tip.

Caveats

Before diving into the solution it's important to understand the playing field. SQL Server managed backups have a lot of restrictions that may leave most "Hands on" DBA's uncomfortable. This tip covers SQL 2014; changes to SQL 2016 backups have been made that offer more granular control of backups. In no particular order here are a number of the major caveats to be aware of.

Azure backup blob must be the correct type. Azure storage offers more than one type of blob storage but not all will work. You will need to insure the correct blob type is available. System databases cannot be backed up in SQL 2014 nor can databases running in simple recovery model. You should not use maintenance plans or other scripts to take backups. This will create an issue for the SQL managed backup to create and maintain a valid retention period worth of backups. Availability groups can be backed up if the SQL Server is an Azure based host. On premises and hybrids of SQL Azure and on premises solutions are not supported. Preparing the blob storage

The first step in setting up managed backups usually requires working with a storage team to allocate the blob storage. The storage team needs to insure the blob storage is compatible with the backups. An Azure general purpose blob account is required to work with SQL 2014 managed backups. A definition of SQL Azure blob accounts is provided here: About Azure storage accounts .

This tip doesn't discuss Azure storage administration, but the following image may assist you when asking your storage team for assistance. With SQL 2014 you must request a general-purpose storage account which accepts blobs, tables, and other objects as noted in the previous article. SQL 2016 changes this limitation, but that is beyond the scope of this article.

Non-Encrypted backups of a single database

There is a procedure for backups that are not encrypted and another process for encrypted backups. This section will focus on non-encrypted backups, but dont skip ahead to the encrypted section because this material applies there too and is needed when you get there.

Whether running backups of all the databases or just a single database the starting point is to prepare the server with a credential which is used for identification to the storage. Credentials are used by SQL Server when authentication outside of SQL is needed. In this case we will be connecting to AZURE blob storage and need the account information to make that connection. We think of these things in terms of user names and passwords, but the storage administrator should be asked for the identity and the secret. The identity is the name of the storage account and the secret is an access key which allows connecting into the storage. The syntax to create the credential is simple.

create credential sqlblobbackups
with identity = 'sqlblobbackups',
secret = 'AEIF361AbjkADNIilKRRchaKHng72yz4ocEp1zCX00tWOeo5N2w==';

Once the credential is established we can configure backups. The first procedure establishes backups for a single database running in either bulk log mode or full recovery mode. The command to run is:

EXEC smart_admin.sp_set_db_backup
@database_name='Adventure Works 2014'
,@retention_days=1
,@credential_name=sqlblobbackups
,@encryption_algorithm = NO_ENCRYPTION
,@enable_backup=1;

With this command notice that the encryption_algorithm is required to be set to NO_ENCRYPTION if we are not encrypting the backups. After running the command we can check on the configuration of the backups.

SELECT *
FROM smart_admin.fn_backup_db_config ('Adventure Works 2014')

The results of this function demonstrate an interesting point about SQL Server managed backups. At no point do we specify where the backups reside. SQL Server internally understands that we're using Azure storage and interrogates the Azure service to determine what endpoint to use based on the identity of the storage and the secret we passed in. Further in this article we'll discuss verifying that backups have run. At this point let's look at backing up all databases on a server.

Non-Encrypted backups of all databases

Thus far we've created a backup of a single database. Enabling backups of all databases that are running in Full recovery mode or bulk-logged is simple.

EXEC smart_admin.sp_set_instance_backup
@retention_days=7
,@credential_name='sqlblobbackups'
,@encryption_algorithm ='NO_ENCRYPTION'
,@enable_backup=1;

As with single databases, we still need to add 'NO_ENCRYPTION' and can check on the configuration of each individual database by using smart_admin.fn_backup_db_config . In the next section we'll discuss verifying backups have run.

Verifying backups

After configuring backups a period of up to 15 minutes is needed before backups start running. To check on the backup status of our database Microsoft documentation offers one solution -- check the azure storage from within SQL Server Management Studio. That's demonstrated below, but we're going to show you two other methods.

In SQL Server Management Studio connect to the storage providing the identity and the secret we previously used.

Once the SQL Server Management Studio is connected we see the container for the backups and the blob names. These backups have a timestamped value.

While this method shows that backups are occurring it isn't really a workable solution with more than a couple of data