Azure SQL VM – keine Möglichkeit den Plattenplatz zu konfigurieren

Ein Kunde hatte mich die letzten Tage gebeten, ihn bei der Optimierung eines SQL Servers auf einer Azure VM zu unterstützen. Der Kunde hatte immer mal wieder leichte Performance Probleme mit dem SQL Server, der Applikation Hersteller bzw Betreuer wollte oder konnte nicht mehr sagen bzw helfen. Von dort erhielten der Kunde erst einmal nur die Aussage, man empfehle für die DATA-Platten des SQL Servers eine Latenz von 5ms… ok, in Azure lässt sich dies offiziell nur mit ULTRA Disks erreichen. Ich möchte hier in diesem Beitrag nicht unbedingt auf das Wie eingehen, sondern nur auf einen Fehler, der mir im Rahmen der Analysen aufgefallen ist.

Erst einmal zur Erläuterung, ich habe mit dem Kunden gesprochen und ihm vorgerechnet was es kostet den Server mit 2 TB Ultra-Disks auszustatten und ob es nicht vielleicht sinnvoller und zielführender ist, den SQL Server auf “Herz und Nieren” zu prüfen, zu optimieren (auch die Applikation bzw deren T-SQL) und im letzten Schritt notfalls doch auf Ultra-Disks zu gehen.

Der Kunde war einverstanden und gemeinsam haben wir den SQL Server einem Review unterzogen, auch wenn die Marketplace-Images von Microsoft (Danke an das Produktteam!) schon sehr gut konfiguriert sind, lässt sich doch noch das ein oder andere anpassen.

Azure SQL VM und die Data-Disks

Wenn man den Empfehlungen zu Azure SQL in einer virtuellen Maschine folgt, dann kann man dort in den Empfehlungen lesen:

Stripe multiple Azure data disks using Storage Spaces to increase I/O bandwidth up to the target virtual machine’s IOPS and throughput limits.

https://docs.microsoft.com/en-us/azure/azure-sql/virtual-machines/windows/performance-guidelines-best-practices-storage

In einem ersten Anlauf haben wir die 1TB Platte durch mehrere kleine Platten ersetzt, um den maximalen Throughput von 200MB auf 625MB zu erhöhen. Das hat soweit auch ohne Downtime funktioniert, der Kunde ist bisher sehr glücklich. Aber im Zuge dieser Arbeiten bin ich eben auch auf eine Meldung im Azure Portal an dieser virtuellen Maschine bzw der SQL Server Konfigurationsübersicht gestossen, mit der ich im ersten Moment nichts anfangen konnte und Google auch keinerlei Hilfe brachte.

Im Azure Portal gibt es die Möglichkeit für alle SQL Server innerhalb einer Azure VM entsprechend mehrere Extensions auszurollen, die den Administrator dabei unterstützen sollen, die VM bzw den SQL Server über Powershell, Azure CLI oder das Portal zu administrieren und deren Daten in Logs und Metrics darzustellen. Hierzu nutzt Microsoft unter anderem den “SQL Server IaaS Extension Query Service” oder “SQL Server IaaS Agent extension”, beide sammeln Daten aus der virtuellen Maschine und dem SQL Server und stellen diese nutzerfreundlich im Portal dar. Leider war das bei diesem Kunden und dieser VM nicht zu 100% verfügbar, wie der folgende Screenshot zeigt.

Azure SQL VM im Portal leider ohne Anzeige der verfügbaren und belegten Plattenkapazitäten

Auch in der weiteren Übersicht “Configure” waren keine Daten zum Storage ermittelbar, obwohl alle Extensions auf dem Server ausgerollt waren und auch nach einem/mehreren Reboots keinerlei Daten anzeigten. Also bin ich auf die Suche nach der Ursache gegangen…

Extension-Log und fn_trace_gettable

Wie man der Microsoft-Dokumentation entnehmen kann, gibt es unterschiedliche Modis, für unterschiedliche Anforderungen und natürlich kann man hier auch entnehmen, dass es ein lokales Errorlog gibt, welches man unter Umständen zur Fehlersuche nutzen kann. Bei diesem Errorlog handelt es sich um ein XE-File und ein Tracefile, beide nicht mit dem Notepad sondern nur SQL Server Management Studio lesbar… also blieb nichts anderes, als kurzerhand mit einer T-SQL Systemfunktion auf das Tracefile zuzugreifen, um festzustellen, dass der Systemuser anscheinend keinerlei oder zu wenige Berechtigungen hat. Normalerweise befindet sich die Extension direkt auf dem C-Laufwerk im Verzeichnis C:\SQLIaaSExtension, so dass man diesen Pfad in der SQL Abfrage entsprechend nutzen muss.

SELECT * FROM fn_trace_gettable('C:\SQLIaaSExtension\Log\log.trc', default);  
GO  

Durch die Ausführung dieses T-SQL Statements zum Auslesen des Extension-Logfiles, erhielt ich unter anderem die folgende Zeile :

alter server role [sysadmin] add member [NT Service\SQLIaaSExtensionQuery]

Bei der Suche nach dem User musste ich dann feststellen, dass der Kunde diesen User – warum auch immer – gelöscht hat (später stellte ich fest, dass dies anscheinend nicht “per accident” passiert ist, sondern bewusst, denn auf anderen SQL Servern in Azure fehlt der User ebenfalls)

USE [master]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
DROP LOGIN [NT SERVICE\SqlIaaSExtensionQuery]
GO

/****** Object:  Login [NT SERVICE\SqlIaaSExtensionQuery]    Script Date: 5/10/2021 3:35:08 PM ******/
CREATE LOGIN [NT SERVICE\SqlIaaSExtensionQuery] FROM WINDOWS WITH DEFAULT_DATABASE=[master], DEFAULT_LANGUAGE=[us_english]
GO

ALTER SERVER ROLE [sysadmin] ADD MEMBER [NT SERVICE\SqlIaaSExtensionQuery]
GO

Testweise habe ich diesen User erneut angelegt, berechtigt und im Azure Portal überprüft, ob es eine Veränderung in den Ansichten gibt… Ja, die SQL Server IaaS Agent Extension kann nun wieder auf den SQL Server zugreifen und die notwendigen oder relevanten Daten auslesen.

Azure SQL VM im Portal mit Anzeige der verfügbaren und belegten Plattenkapazitäten

SQL Server Failover Cluster on Azure

ich bin heute “gezwungen” gewesen mir “schnell” ein SQL Server 2019 Failover Cluster zu erstellen um etwas zu testen, da der Kunde nur eine produktive Umgebung hat und ich erst einen funktionierenden Fahrplan für die Umsetzung benötige… also schnell eine Anleitung rausgesucht, ich wusste was grobes aber musste mich natürlich erst einmal in die Details einlesen…

Ich habe schon mehrfach gehört, dass Microsoft seit einiger Zeit auch “Shared Disks” für eben Failover Cluster anbietet, aber wie man diese nun deployed und zusätzlich noch richtig in Windows bzw dem Cluster Manager einbindet, diese Informationen fehl(t)en mir. Also Google gefragt, dieser mich auf eine Beitrag in den Microsoft Docs verwiesen und ich einfach mal drauflos gelegt.

Erstellen Sie eine FCI mit gemeinsam genutzten Azure-Festplatten

in diesem Beitrag steht unter Voraussetzungen folgendes:

Bevor Sie die in diesem Artikel aufgeführten Anweisungen ausführen, sollten Sie über Folgendes verfügen:
 - Ein Azure-Abonnement
 - Zwei oder mehr virtuelle Windows Azure-Computer. Verfügbarkeitsgruppen und Näherungsplatzierungsgruppe werden bei SSD Premium und Verfügbarkeitszonen werden   bei für Ultra Disks unterstützt. Wenn Sie eine PPG verwenden, müssen alle Knoten in derselben Gruppe vorhanden sein.
 - Ein Konto mit Berechtigungen zum Erstellen von Objekten auf virtuellen Azure-Computern und in Active Directory
 - Die neueste Version von PowerShell.

Meine Überlegungen dazu… Azure Subscription habe ich, zwei virtuelle Maschinen kann ich schnell deployen, AvailabilityGroups oder ProximityGroups habe ich auch bzw brauche ich hier nicht und eine Domäne mit entsprechendem DomainAdmin-User habe ich auch… also schnell zwei virtuelle Maschinen “SQL Server 2019 Developer auf Windows 2019” deployed und die Anleitung genau befolgt.

  • SharedDiskConfig.json angelegt und gemäß Doku befüllt
  • ResourceGroupDeployment mit SharedDiskConfig.json ausgeführt, also die SharedDisk angelegt
  • SharedDisk der ersten virtuellen Maschine hinzugefügt
  • SharedDisk der zweiten virtuellen Maschine hinzugefügt… HALT STOP, eine Fehlermeldung…
Cannot change network spine of shared disk myDataDisk while it is attached to running VM(s)

die Fehlersuche beginnt…

Da dies meine ersten Versuche mit Shared Disks sind/waren, habe ich natürlich erst einmal alles genauer untersucht bzw versucht, zumal die Shared Disk trotz Fehlermeldung an der zweiten Maschine (zumindest im Portal) zu sehen war. Restart der virtuellen Maschine ging nicht, wegen dem komischen Deployment-Zustand, Abhängen der Platte im ersten Moment auch nicht, als Owner der Platte konnte ich die erste VM ausmachen, aber wie kann ich jetzt die zweite VM zum Owner machen… alles sehr strange…

Aber es gab etwas was mich doch ein wenig irritierte… sowohl in der Anleitung als in den Powershell Snippets gibt es den Hinweis auf die Verwendung von Proximity Placement Groups. Beim Googeln nach der Fehlermeldung stieß ich dann auch einen Beitrag auf Stackoverflow, wo jemand denselben Fehler hatte und die Lösung eben in diesen Proximity Placement Gruppen gefunden hatte. Aber wieso wird in der Dokumentation nicht wirklich daraufhin gewiesen… Na gut, erst einmal selber ausprobieren, ob das dann funktioniert.

Anlegen einer PPG und Maschinen hinzufügen

Ok, also habe ich versucht den kürzesten und einfachsten Weg zu nehmen… Anlegen einer Proximity-Placement-Group und die beiden bereits vorhandenen virtuellen Maschinen dieser hinzufügen. Die Anlage der PPG über das Azure Portal war schnell und einfach (Ressourcengruppe => neue Ressource => PPG suchen und auswählen => Region und Namen eintragen und erstellen), das Hinzufügen der VMs habe ich dann ebenfalls über das Portal gemacht, dazu müssen die Maschinen erst einmal gestoppt werden und die Ressourcen deallokiert werden.

Danach habe ich vorsichtshalber noch einmal die Shared-Disk gelöscht und neu erstellt und konnte diese dann erfolgreich an beide SQL Server VMs anbinden.

$dataDiskConfig = New-AzDiskConfig -Location 'eastus2' -DiskSizeGB 1024 -AccountType Premium_LRS -CreateOption Empty -MaxSharesCount 2

New-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName 'myClusterDisk' -Disk $dataDiskConfig


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl01"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'


$vm = Get-AzVm -ResourceGroupName 'RG-SQLServer' -Name "winsqlcl02"
$dataDisk = Get-AzDisk -ResourceGroupName 'RG-SQLServer' -DiskName "myClusterDisk"
$vm = Add-AzVMDataDisk -VM $vm -Name "myClusterDisk" -CreateOption Attach -ManagedDiskId $dataDisk.Id -Lun 2
update-AzVm -VM $vm -ResourceGroupName 'RG-SQLServer'

Im Nachgang konnte ich auf beiden Servern problemlos erst das Windows Failover Cluster validieren und erstellen, um dann die SQL Server Knoten zu installieren bzw hinzuzufügen.

Ich werde also zeitnah die Beschreibung bei Microsoft anpassen (lassen). Ich hoffe dieser Blogpost hilft euch bei Zeiten weiter, damit ihr nicht so lange braucht 😉

Das Azure Meetup Hamburg im Juli 2019

Im Juli ist es nicht wie gewohnt der dritte Dienstag im Monat, sondern schon der zweite… natürlich mit einer gewissen Rücksicht auf die Ferien 😉 Also sind es nur noch knapp 10 Tage bis zum nächsten Azure Meetup in Hamburg… wir bekommen wieder Besuch von Microsoft Deutschland aus München, Andre Essing (Microsoft TSP) wird bei uns sein. Als ehemaliger MVP und immer noch stetiger Begleiter in der europäischen Data-Platform-Community ein immer wieder gern gesehener Gast, der mit seinem Know-How und seiner Erfahrung viel Wissen weitergeben kann. Daher freue ich mich sehr auf diesen sicherlich spannenden Abend mit euch.

Wir hatten zwar noch kurz inhaltlich diskutiert – hatte ich beim Juni-Meetup auch kurz angedeutet – ob wir noch was zu CosmosDB an diesem Abend machen sollen oder nicht, gemeinsam mit Andre sind wir aber zu dem Schluss gekommen, dass hier die Tiefe und Länge der zur Verfügung stehenden Zeit nicht ausreichen würde, um einer CosmosDB gerecht zu werden. Somit werden wir im Juli erst einmal nicht über CosmosDB reden, sondern “nur” über Modern Datawarehouse und Databricks.

Modern Datawarehouse and Databricks - Andre Essing - Azure Meetup Hamburg
Modern Datawarehouse and Databricks – Andre Essing – Azure Meetup Hamburg

Anmelden könnt ihr euch – wie gewohnt und natürlich kostenfrei über die Meetup-Seite des Azure Meetups in Hamburg
Hier geht es direkt zu unserer Juli Veranstaltung
Zwar gibt es mittlerweile eine Warteliste, aber es lohnt sich bestimmt auch dort einzutragen, da die Erfahrung gezeigt hat, dass der ein oder andere noch kurzfristig absagt, weil ihm/ihr etwas dazwischen gekommen ist. Also “aufpassen”!

Hier kommt der Abstract für das Meetup, damit ihr wisst worum es gehen soll 😉

Es gibt eine Menge Wege und Möglichkeiten Mehrwerte aus seinen Daten zu ziehen. Seit Jahren machen wir das mit den gleichen Techniken in unseren “klassischen” Data Warehouse Umgebungen. Aber die Welt ist im steten Wandel und so auch die Daten.

Wo die Daten vor ein paar Jahren noch ausschließlich strukturiert waren, wächst die Zahl von schemalosen Datentypen ins unermessliche, und eine Ende ist nicht in Sicht. Wir kämpfen mit Daten, bei denen sich ständig das Schemata ändert und versuchen Mehrwerte aus neuen Datentypen wie Soziale Medien, Videos und Bildern zu ziehen.

In dieser Whiteboard Session möchte ich mit euch über moderne Wege sprechen, Ihre Daten zu speichern, zu analysieren und zu visualisieren. Zusammen zeichnen wir ein Modern Data Warehouse, schauen uns an welche Möglichkeiten sich bieten verschiedenste Daten zu analysieren und warum uns die Cloud hier hilft.

Von Datawarehouse, über BI, hin zur modernen Datenanalyse und künstlicher Intelligenz – Azure Databricks, die Eierlegende Wollmilchsau

Hast Du schon von Azure Databricks, dem neuen Mitglied in der Azure Big Data Familie, gehört? Es wäre falsch von mir, Azure Databricks nur als einen verwalteten Apache Spark Dienst zu bezeichnen, da Databricks so viel mehr bietet.

Neben dem Transformieren von Daten kann Databricks nicht nur Deine Daten analysieren und streamen, es kann auch Deine ETL-Prozesse abbilden, Machine Learning Modelle trainieren und zur Exploration von Daten genutzt werden. All das steckt im leistungsstarken Kern von Databricks, gepaart mit einer integrierten Entwicklungsumgebung.

Als “First-Class Citizen” in Azure ist Databricks ein “Platform as a Service”-Angebot, das es jedem ermöglicht, Big Data für sich zu nutzen.

Selbstverständlich, sind die ersten Schritte mit einer neuen Technologie die schwierigsten. Genau deshalb möchte ich mir mit euch in dieser Session ansehen, wie man Azure Databricks bereitstellt. Du lernst wie man Cluster konfiguriert, zeitgesteuerte Jobs einplant, auf Sicherheit achtet und vieles mehr.

https://www.meetup.com/de-DE/Azure-Meetup-Hamburg/events/hhtbxqyzkbvb/

Das Azure Meetup Hamburg im Juni 2019

Bald ist es wieder so weit, wir treffen uns zu einem neuen spannenden Abend ! Diesmal geht es an den Hamburger Rödingsmarkt und nicht wie gewohnt zu WeWork in der Herrmannstraße, denn die Firma Point GmbH hat uns eingeladen. Erneut kommt der Vortrag aus der Community allerdings hat der Sprecher diesmal eine etwas weitere Anfahrt, denn Sebastian Schütze kommt aus der Hauptstadt zu uns 😉

Nachdem uns Martin Gudel im letzten Jahr eine Einführung in das Thema Azure DevOps gegeben hat, wird uns Sebastian nun aus seiner Sicht bzw aus seinem alltäglichen Umgang mit dem Thema DevOps berichten. Hierbei wird er einen Überblick bieten, wie er (mit seinem Team) agiles Projektmanagement bzw agile Software-Entwicklung mit Hilfe des Microsoft (Azure/Tool/Software) Stacks betreibt.

Azure Meetup Hamburg - Azure DevOps - ein Bericht aus der Praxis - Sebastian Schütze
Azure Meetup Hamburg – Azure DevOps – ein Bericht aus der Praxis – Sebastian Schütze

Anmelden könnt ihr euch – wie gewohnt und natürlich kostenfrei über die Meetup-Seite des Azure Meetups in Hamburg
Hier geht es direkt zu unserer Juni Veranstaltung
Zwar gibt es mittlerweile eine Warteliste, aber es lohnt sich bestimmt auch dort einzutragen, da die Erfahrung gezeigt hat, dass der ein oder andere noch kurzfristig absagt, weil ihm/ihr etwas dazwischen gekommen ist. Also “aufpassen”!

Vielen Dank an Sebastian Schütze für seine Bereitschaft für die Hamburger Azure Community extra aus Berlin anzureisen, um uns an seinen Erfahrungen mit DevOps Themen teilhaben zu lassen!

SQL Backup auf einer Azure Virtual Machine

Als Database Administrator kennt man das Thema nur zu gut, wenn man sich nicht gleich zu Anfang voll umfänglich mit der Backup bzw Restore-Strategie beschäftigt, fällt es einem irgendwann vor die Füße… aber wie ist das Ganze jetzt in der Cloud, wie kann man da sein Datenbanken richtig sichern? Darum ging es in meinem Vortrag auf dem Global Azure Bootcamp 2019 in Hamburg mit dem Ziel, die neue Möglichkeit mittels Azure Backup auch direkt SQL Server Datenbanken auf einer virtuellen Maschine in Azure zu sichern.

Serverausfall – was nun?

Man stelle sich vor – in der onprem Welt – ein Server fällt aus, die Datenbanken nicht mehr erreichbar… PANIK (zumindest im ersten Moment)… die Fragen, die man sich dann im ersten Moment stellt:

  • Haben wir eine Sicherung?
  • Wann ist die letzte Sicherung erfolgreich gelaufen?
  • Wie groß ist mein Datenverlust?
  • Wie komme ich an die Daten?
  • Wie lange dauert es, bis das richtige Backup für den Restore gefunden wurde?
  • Wie lange dauert der Restore?
  • Klappt der Restore auf Anhieb?
  • Können dann alle wieder auf die Daten zugreifen?

Gehen wir erst einmal von dem Fall aus, dass der Server neu aufgesetzt wird und die Datenbanken dann aus einer Sicherung wieder hergestellt werden müssen. Nun sucht man (vielleicht) über die GUI der Backup-Software nach einer Filesicherung, dem Tape oder einer Datenbank-Sicherung. Spätestens hier wird es interessant 😉

Wie wurde der Datenbank-Server überhaupt gesichert, in welchem Rhythmus, wieviele Files müssen zurück gespielt werden und so weiter… Im schlimmsten Fall gibt es nur eine tägliche Vollsicherung (Full-Backup) auf die lokale Platte mit nur wöchentlicher Filesystemsicherung… 😮
Backup-Lösungen und -Strategien sind aber nicht das Thema dieses Beitrages, denn hier geht es um die Cloud.

Azure SQL Databases und das Backup

In der Cloud ist vieles einfacher (oder zumindest anders), denn wie auch on-prem sollte man sich zumindest Gedanken über die Backup-Strategie machen. Aber zumindest hat sich Microsoft sehr viele Gedanken zu diesem Thema für uns gemacht, so dass in vielen Datenbank-Services wie zum Beispiel der Azure SQL Database das Backup schon automatisch inkludiert ist.

Also alle Azure SQL Database Services (SingleDB, Elastic Pool und Managed Instance) haben bereits ein Backup inkludiert, so dass man sich hier nicht wirklich mehr Gedanken zu einer Backup-Strategie oder “Welche Software wollen wir einsetzen?” machen muss. Beispielsweise Azure SQL Single-Database hat in den unterschiedlichen Performance-Klassen (Basic, Standard, Premium) unterschiedliche Aufbewahrungszeiten von 7-35 Tagen… was aber wenn man das Backup, aus welchen Gründen auch immer, länger aufbewahren möchte/muss? Dann bleibt einem – für diesen Fall – nur das Hinzufügen eines sogenannten “Log-Time-Retention” Backups, welches das Backup(-File) zusätzlich auf einem weiteren Storage-Account ablegt und erst nach X Tagen/Wochen/Monaten/Jahren löscht, was einem selber überlassen wird über eine entsprechende Policy zu definieren.

Selbst für den Fall, dass mal ein komplettes Microsoft Rechenzentrum oder sogar eine ganze Region ausfallen sollte, hat Microsoft vorgesorgt und verschiebt alle Backups über Geo-Replication auch in andere Regionen, so dass im Fall der Fälle immer ein entsprechendes Backup für einen Point-in-Time-Restore innerhalb der Retention-Period vorhanden ist.

Automatisierte Backups – da war doch schon was

Ja, automatische Sicherungen (Automated Backup) konnte der SQL Server schon seit der Version 2014, wenn man ihn entsprechend konfiguriert hatte, dann wurde alle Datenbanken bereits “damals” auf einen Azure Storage Account gesichert. Auch mit der Version 2016 und 2017 blieb diese Funktion erhalten, wurde aber angepasst bzw optimiert (Automated Backup v2). Alternativ könnte man sich auch ein Backup-to-URL mittels Ola Hallengren Skripten vorstellen, aber das hängt dann wieder mit der gesamten Backup-Strategie zusammen und muss entsprechend geplant werden.

Gemeinsame Nutzung von Azure Backup ?

Viele Kunden haben in Azure so oder so eine Azure Backup Vault oder den Azure Backup Service laufen, so dass sich diese Kunden gefragt haben, warum sie damit nur Virtuelle Maschinen als “Ganzes” sichern können, aber nicht auch ihre SQL Server. Somit wäre eigentlich eine zentrale Lösung für viele Backups in Cloud gefunden. Man könne auch von dieser zentralen Stelle im Portal aus, alle Backups administrieren und überwachen, bräuchte kein weiteres Tool geschweige denn eine neue Backup-Infrastruktur.

Microsoft hat auf die Wünsche und Bitten seiner Kunden gehört und das Azure Backup entsprechend erweitert, so dass man seit Mitte März 2019 auch endlich reine SQL Server Datenbank-Backups damit ziehen kann.

https://azure.microsoft.com/de-de/blog/azure-backup-for-sql-server-in-azure-virtual-machines-now-generally-available/

Jetzt kann man also die Azure Backup Extension sowohl auf fertige SQL Server Marketplace VM-Images ausrollen, als auch auf selbst erstellte SQL Server, um diese dann als native SQL Server Backups gegen Azure Backup zu sichern. Derzeit gibt es folgende Eckpunkte, die für diesen Service sprechen:

  • Zentrale Verwaltung und Überwachung
  • Schutz für verschlüsselte Datenbanken
  • Automatische Erkennung von (neuen) Datenbanken
  • RPO-Wert (Recovery Point Objective) von 15 Minuten
  • Point-in-Time-Wiederherstellungen
  • Langfristige Aufbewahrung
  • Kosteneffektiv

Wenn man nun also das native SQL Server Backup über die neue Extension ausgerollt hat, dann kann man während der Konfiguration im Portal entweder den ganzen Server (Instanz) oder einzelne Datenbanken, ebenso “Autoprotection” auswählen. Und “zusehen” wie nach erfolgreichem Deployment die ersten Sicherungen durchgeführt werden. Das Ergebnis sowie Alarme können dann sehr schön und zentral über das Azure Backup Dashboard im Portal überwacht werden. Zusätzlich dazu bietet Microsoft eine PowerBi Application mit der man auf einen (dann einzurichtenden StorageAccount) zu aktivieren, um noch mehr Details zu seinen Sicherungen zu erhalten.

Ein Restore der Datenbanken ist mit wenigen Klicks über das Portal zu realisieren, hierbei stehen dann auch weitere Optionen zur Verfügung, wie man sie aus dem normalen SQL-Restore kennt (z.B. File-Relocation, Overwrite oder Database-Rename).

Fazit zu Azure Backup für SQL Server VMs

Ich persönlich finde diese neue Extension super, wenn man seine SQL Server in einer Azure VM nativ sichern möchte/muss und eine (!!!) zentrale Anlaufstelle für Backups in Azure mit Monitoring, Alerting und Config-Management haben möchte!!!