SQL Server 2016 – Backup to Azure Cloud

In Vorbereitung auf kommende Aktivitäten möchte ich nun eine Reihe von Blogbeiträgen zum Thema SQL Server 2016 und Azure schreiben. Welche Möglichkeiten bietet der neue SQL Server 2016 in Verbindung mit der Azure Cloud und wie realisiert man diese. Mir persönlich nützt diese Art von Ausprobieren, Dokumentieren und Schreiben sehr, mal abgesehen von der Anhäufung neuen Wissens und vielleicht kann ich auf diese Weise dem einen oder anderen auch noch behilflich sein.

In meinem ersten Beitrag geht es um ein relativ einfaches aber sehr wichtiges Thema – Backups mit dem SQL Server 2016 in Richtung Azure Cloud. Es soll aber nicht um das Thema Backup allgemein gehen, also warum Backups so wichtig sind und wie man diese Backups erstellt. Viel mehr möchte ich die verschiedenen Wege eines SQL Server Backup in die Azure Cloud zu machen erläutern und dies ggf unter zu Hilfenahme von Powershell.

Einen wichtigen Einwand möchte ich nur kurz grundsätzlich machen, da man manchmal vielleicht beim Erstellen einer Solution nicht unbedingt daran denkt…  Also funktionierende Backups sind absolut notwendig und sehr wichtig, es gibt mehrere Möglichkeiten diese Backups sicher zu erstellen und im Notfall auch schnell „griffbereit“ zu haben. Normalerweise ist die schnellste und einfachste Lösung ein lokales „Backup-to-Disc“, was ist aber wenn diese Backup-Platte einmal kaputt geht? Optimaler (bzw Ausfallsicherer) ist das „Backup-to-Share“ oder besser bekannt als Backup-to-NetworkDevice (hierbei sollte das Network-Share natürlich als RAID konfiguriert sein. Aber nicht jede kleine Firma ist in der Lage einen entsprechend großen Fileserver zu unterhalten, damit hier die letzten ~5 Tage des SQL-Servers (zusätzlich?!) abgelegt werden können. Was liegt also näher diese Backups auf einen anderen („günstigen“) redundanten Speicher abzulegen, genau um diese Möglichkeiten geht es in diesem Blogbeitrag.

Möglichkeiten des SQL Servers in Verbindung mit Azure

Seit dem SQL Server 2012 bietet Microsoft mit „SQL Server Backup to URL“ die Möglichkeit, wie gewohnt seine verschiedenen Backups zu erstellen. Allerdings ist hierbei nicht eine lokale Festplatte oder ein Fileserver im eigenen Netz das Ziel sondern eine URL aus der Azure Cloud. Dieses Feature wurde im SQL Server 2016 weiter optimiert. Nun stehen weitere Optionen (BlockBlobs, Shared Access Signatures und Striping) bereit, um schneller und sicherer Backups in die Cloud zu erstellen.

Mit dem SQL Server 2014 führte man dann „SQL Server Managed Backup to Microsoft Azure“ ein. Dieses neue Feature ermöglichte dem DB-Admin eine vereinfachte und schnellere Arbeit, denn der SQL Server entscheidet selber wann er ein Backup erstellt. Der DBA muss sich nicht erst Gedanken über die Backup Strategie und die Backup-Skripte machen. Natürlich ermöglichen die Optionen auch einen Eingriff durch den DBA, einfacher geht es aber mit den Bordmitteln des SQL Servers. Für Azure SQL Server wird dieses Feature zur Nutzung empfohlen.

Neu hinzugekommen im SQL Server 2016 ist das Feature „File-Snapshot Backups for Database Files in Azure„. Diese Feature ermöglicht dem SQL Server 2016, welcher in Azure läuft ein sehr, sehr schnelles Backup der Datenfiles zu erstellen und somit auch einen schnellen Restore.

SQL Server Backup und Restore mit Azure Blob Storage

Was benötigen wir denn alles für die Einrichtung und Anbindung unseres SQL Servers an einen Azure Blob-Speicher?

Da Powershell seit den SQL Server 2012 und 2014 immer mehr an Bedeutung gewinnt, möchte ich auch hier eine kleine Anleitung dazu beisteuern. Heißt es muss erst einmal das Azure-Plugin für Powershell installiert werden. Eine Anleitung und einen Download-Link findet ihr hier => https://azure.microsoft.com/de-de/documentation/articles/powershell-install-configure/
Außerdem benötigt man natürlich einen Account in der Azure-Cloud (170 Euro Test-Zugang), zum Beispiel im Rahmen der Visual Studio Lizenzierung oder als MPN oder BizTalk-Kunde.

Erstellen einer Zugriffs Policy und einer Shared Access Signature

#
# This script uses the Azure Resource model and creates a new ARM storage account.
# Modify this script to use an existing ARM or classic storage account
# using the instructions in comments within this script
#
# Define global variables for the script
$prefixName = '' # used as the prefix for the name for various objects
$subscriptionName='' # the name of subscription name you will use
$locationName = '' # the data center region you will use
$storageAccountName= $prefixName + 'storage' # the storage account name you will create or use
$containerName= $prefixName + 'container' # the storage container name to which you will attach the SAS policy with its SAS token
$policyName = $prefixName + 'policy' # the name of the SAS policy

#
# Using Azure Resource Manager deployment model
# Comment out this entire section and use the classic storage account name to use an existing classic storage account
#

# Set a variable for the name of the resource group you will create or use
$resourceGroupName=$prefixName + 'rg'

# adds an authenticated Azure account for use in the session
Login-AzureRmAccount

# set the tenant, subscription and environment for use in the rest of
Set-AzureRmContext -SubscriptionName $subscriptionName

# create a new resource group - comment out this line to use an existing resource group
New-AzureRmResourceGroup -Name $resourceGroupName -Location $locationName

# Create a new ARM storage account - comment out this line to use an existing ARM storage account
New-AzureRmStorageAccount -Name $storageAccountName -ResourceGroupName $resourceGroupName -Type Standard_RAGRS -Location $locationName

# Get the access keys for the ARM storage account
$accountKeys = Get-AzureRmStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a new storage account context using an ARM storage account
$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].Value

#
# Using the Classic deployment model
# Use the following four lines to use an existing classic storage account
#
#Classic storage account name
#Add-AzureAccount
#Select-AzureSubscription -SubscriptionName $subscriptionName #provide an existing classic storage account
#$accountKeys = Get-AzureStorageKey -StorageAccountName $storageAccountName
#$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys.Primary

# The remainder of this script works with either the ARM or classic sections of code above

# Creates a new container in blob storage
$container = New-AzureStorageContainer -Context $storageContext -Name $containerName
$cbc = $container.CloudBlobContainer

# Sets up a Stored Access Policy and a Shared Access Signature for the new container
$permissions = $cbc.GetPermissions();
$policyName = $policyName
$policy = new-object 'Microsoft.WindowsAzure.Storage.Blob.SharedAccessBlobPolicy'
$policy.SharedAccessStartTime = $(Get-Date).ToUniversalTime().AddMinutes(-5)
$policy.SharedAccessExpiryTime = $(Get-Date).ToUniversalTime().AddYears(10)
$policy.Permissions = "Read,Write,List,Delete"
$permissions.SharedAccessPolicies.Add($policyName, $policy)
$cbc.SetPermissions($permissions);

# Gets the Shared Access Signature for the policy
$policy = new-object 'Microsoft.WindowsAzure.Storage.Blob.SharedAccessBlobPolicy'
$sas = $cbc.GetSharedAccessSignature($policy, $policyName)
Write-Host 'Shared Access Signature= '$($sas.Substring(1))''

# Outputs the Transact SQL to the clipboard and to the screen to create the credential using the Shared Access Signature
Write-Host 'Credential T-SQL'
$tSql = "CREATE CREDENTIAL [{0}] WITH IDENTITY='Shared Access Signature', SECRET='{1}'" -f $cbc.Uri,$sas.Substring(1)
$tSql | clip
Write-Host $tSql

Quelle: https://msdn.microsoft.com/en-us/library/dn466438.aspx

Um dieses Skript nutzen zu können, brauchen wir erst einmal die folgenden Angaben, um sie ins Skript einfügen zu können.

Get-AzureSubscription | Format-Table

Nordeuropa ist die optimale Location für Deutschland, ansonsten

Aber um die Angabe Nordeuropa machen zu können, müssen wir uns erst einmal in unseren Azure-Account einloggen und dann eine Liste der verfügbaren Location ausgeben lassen.

Login-AzureRmAccount
Get-AzureRmLocation | Format-Table Location, DisplayName

Location       DisplayName     
--------       -----------     
[...]
southcentralus South Central US
northeurope    North Europe    
westeurope     West Europe     
japanwest      Japan West      
[...]

Diese Werte in das Skript eingebaut und ausgeführt, sollte zu folgender Meldung führen:

Shared Access Signature=  sv=2015-04-05&sr=c&si=backupdemopolicy&sig=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 
Credential T-SQL
CREATE CREDENTIAL [https://backupdemostorage.blob.core.windows.net/backupdemocontainer] WITH IDENTITY='Shared Access Signature', SECRET='xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'

Dieses TSQL Statement auf dem zusichernden Servern einfach ausführen, mittels

SELECT * from sys.credentials

kann man den Erfolg überprüfen, falls man der Meldung im SQL Management Studio nicht traut.

Jetzt sind wir eigentlich so weit, dass wir direkt ein Backup in unseren erstellten Azure Storage erstellen können. Hierzu einfach ein Backup-to-URL ausführen (natürlich die Werte entsprechend ersetzen) :

BACKUP DATABASE AdventureWorks2014 TO URL = 'https://.blob.core.windows.net//AdventureWorks2014_onprem.bak'

Bei meinen Tests war ich ganz angetan von der Geschwindigkeit mit der die Backups dort abgelegt werden. Natürlich ist die Geschwindigkeit zum Beispiel abhängig von der eigenen Netzwerk-Infrastruktur bzw der Anbindung ans Internet. ( bei mir sind es 100MB down/ 50MB up )
Ergebnis: ein ~43MB TransactionLog-Backup brauchte 12,7 Sekunden

BACKUP LOG successfully processed 13569 pages in 12.696 seconds (8.349 MB/sec).

Zum Vergleich habe ich das gleiche TransactionLog-Backup nochmal auf die lokale Platte erstellt:

BACKUP LOG successfully processed 13569 pages in 1.746 seconds (60.652 MB/sec).

Was natürlich wesentlich schneller ist, aber eben auch einen gewissen Unsicherheitsfaktor beinhaltet. In diesem Beitrag sollte es aber erst einmal nur um einen ersten Einblick zum Thema SQL Server Backup und Azure Cloud gehen. Wie man nun diese Möglichkeiten und ihre Vor-und Nachteile mit einander verbindet, dass muss jeder für sich, sein Unternehmen und seine Applikationen selber definieren.

Nachtrag:

In dem Skript von Microsoft zur Erstellung eines BlobStorages hatte sich ein Fehler eingeschlichen…
In Zeile 38 steht aktuell:

$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys.[0].Value

es muss aber

$storageContext = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $accountKeys[0].Value

heißen.

Anhand der „vorgefertigten“ und korrigierten 😉  Skripte (Danke Microsoft) habe ich für das Aufsetzen dieses Azure Storage Blobs und ein erstes SQL Server Backup-to-URL kaum mehr als 20 Minuten gebraucht.

So und nun viel Spaß beim Ausprobieren und selber Testen. In meinem nächsten Blog gehe ich auf eine der anderen Backup-Möglichkeiten mit dem SQL Server 2016 und Azure ein.