Sichern und Wiederherstellen
In Organisationen, ob groß oder klein, können sich immer wieder Missgeschicke und Vorfälle ereignen. Daher müssen Sie immer einen Plan für die Wiederherstellung Ihrer Systeme griffbereit haben, falls es zu Unterbrechungen kommt. Wenn Sie in SQL Server eine Wiederherstellung einer Datenbank bis zu einem bestimmten Zeitpunkt durchführen möchten, ist dies nur bei Verwendung eines vollständigen Wiederherstellungsmodells möglich. Beim massenprotokollierten Wiederherstellungsmodell ist die Wahrscheinlichkeit größer, dass die Datenbank bis zum Ende der Transaktionsprotokollsicherung wiederhergestellt werden muss.
Bei Azure SQL haben Sie den Vorteil, dass sich Azure um das alles kümmert. Da Azure SQL Ihre Sicherungen verwaltet und im vollständigen Wiederherstellungsmodell ausgeführt wird, können Sie jeden beliebigen Zeitpunkt für Ihre Datenbanken wiederherstellen. Sie können auch eine gelöschte Datenbank innerhalb der konfigurierten Aufbewahrungsrichtlinie wiederherstellen. Zudem werden Ihre Sicherungen von Microsoft automatisch verschlüsselt, wenn TDE auf dem logischen Server oder auf der logischen Instanz aktiviert ist.
Standardmäßig wird wöchentlich eine vollständige Datenbanksicherung erstellt. Protokollsicherungen werden alle 5–10 Minuten erstellt, differenzielle Sicherungen alle 12–24 Stunden. Die entsprechenden Sicherungsdateien werden standardmäßig in Azure Storage in einem georedundanten Speicher mit Lesezugriff (Read-Access Geo-Redundant Storage, RA-GRS) gespeichert. Sie können Ihre Backups jedoch alternativ in einem zonenredundanten Speicher (ZRS) oder einem lokal redundanten Speicher (LRS) aufbewahren. Das Azure SQL-Engineeringteam testet fortlaufend und automatisch die Wiederherstellung von automatisierten Datenbanksicherungen von Datenbanken auf logischen Servern und in Pools für elastische Datenbanken. Für die Migration zu Azure SQL Managed Instance ist eine automatische Erstsicherung mit CHECKSUM von Datenbanken erforderlich, die mit dem nativen RESTORE-Befehl oder mit Azure Database Migration Service wiederhergestellt werden. Zudem können Sie in Azure SQL Managed Instance optional eine native copy-only-Sicherung in Azure Blob Storage speichern.
Entwickeln einer Sicherungsstrategie mit Azure SQL Managed Instance und Azure SQL-Datenbank
Azure SQL nimmt Ihnen die schwere Arbeit ab, aber es ist trotzdem wichtig zu verstehen, wie Sicherungen gespeichert und verarbeitet werden und welche Optionen Sie für die Aufbewahrung und Wiederherstellung haben. Letztendlich sind Sie immer noch für die Gesamtstrategie für die Zeitpunktwiederherstellung, die Langzeitaufbewahrung und die geografische Wiederherstellung verantwortlich.
Zeitpunktwiederherstellung (Point in Time Restore, PITR)
In Azure SQL-Datenbank und Azure SQL Managed Instance haben Sie die Möglichkeit, eine Self-Service-Wiederherstellung durchzuführen. Sie können über das Azure-Portal, PowerShell, die Azure CLI oder REST-APIs den exakten Zeitpunkt auswählen, für den der Prozess wiederhergestellt und gestartet werden soll. Die Zeitpunktwiederherstellung (Point-in-Time Restore, PITR) erstellt eine neue Datenbank (mit einem anderen Namen) auf demselben logischen Server. Wenn Sie die ursprüngliche Datenbank durch die PITR-Datenbank ersetzen müssen, müssen Sie sowohl die ursprüngliche als auch die neue Datenbank umbenennen, um wieder eine funktionsfähige Umgebung zu erhalten. Verbindungszeichenfolgen müssen nicht aktualisiert werden.
Zeitpunktwiederherstellungen werden zwischen einem und 35 Tagen aufbewahrt. Der Aufbewahrungszeitraum (für alle Dienstebenen und Bereitstellungsoptionen) beträgt standardmäßig sieben Tage. Bei den meisten Bereitstellungsoptionen und Dienstebenen können Sie die Richtlinie je nach den Anforderungen Ihres Szenarios auf einen Wert von einem bis 35 Tagen konfigurieren. So kann es sein, dass Sie für eine Testdatenbank nur einen Tag benötigen, während Sie für eine unternehmenskritische Datenbank das Maximum von 35 Tagen wählen können.
Langzeitaufbewahrung (Long-Term Retention, LTR)
Wenn 35 Tage für die Anforderungen Ihrer Organisation oder für Complianceanforderungen nicht ausreichen, können Sie die Langzeitaufbewahrung (Long-Term Retention, LTR) verwenden. Mit dieser Option können Sie automatisch vollständige Datenbanksicherungen erstellen, die bis zu 10 Jahre lang im RA-GRS-, ZRS- oder LRS-Speicher aufbewahrt werden. Für Azure SQL-Datenbank ist LTR allgemein verfügbar. Bei Azure SQL Managed Instance steht LTR als eingeschränkte öffentliche Vorschauversion zur Verfügung.
Geowiederherstellung
Bei schwerwiegenden Ereignissen muss Ihre Organisation in der Lage sein, eine Wiederherstellung durchzuführen. Ihre Sicherungen werden automatisch in RA-GRS gespeichert (es sei denn, Sie entscheiden sich für ZRS oder LRS), was bedeutet, dass Ihre Sicherungen in der gekoppelten Region gespeichert werden. Wenn es also zu einem Ausfall einer gesamten Region kommt und sich Ihre Datenbanken oder verwalteten Instanzen in dieser Region befinden, sind Sie geschützt. Sie können die letzte georeplizierte Sicherung in einer anderen Region mittels Geowiederherstellung wiederherstellen. Diese Sicherung kann im Vergleich zum primären Server geringfügig älter sein, da es eine gewisse Zeit dauert, bis das Azure Blob in einer anderen Region repliziert wurde. Sie können problemlos eine Geowiederherstellung mithilfe des Azure-Portals, mit PowerShell, der Azure CLI oder mit REST-APIs durchführen.