Automatisierte Sicherungen in Azure SQL-Datenbank

Gilt für: Azure SQL-Datenbank

• Azure SQL-Datenbank
• Verwaltete Azure SQL-Datenbank-Instanz

In diesem Artikel wird das automatisierte Sicherungsfeature für Azure SQL-Datenbank beschrieben.

Informationen zum Ändern der Sicherungseinstellungen finden Sie unter Einstellungen ändern. Informationen zum Wiederherstellen einer Sicherung finden Sie unter Wiederherstellen mithilfe automatisierter Datenbanksicherungen.

Was ist eine Datenbanksicherung?

Datenbanksicherungen sind ein wesentlicher Bestandteil jeder Strategie für Geschäftskontinuität und Notfallwiederherstellung, da sie dazu beitragen, Ihre Daten vor Beschädigung oder Löschung zu schützen. Diese Sicherungen ermöglichen die Wiederherstellung der Datenbank bis zu einem bestimmten Zeitpunkt innerhalb der konfigurierten Beibehaltungsdauer. Wenn es gemäß Ihren Sicherheitsregeln erforderlich ist, dass Sicherungen über einen längeren Zeitraum verfügbar sind (bis zu 10 Jahre), können Sie sowohl für Einzel- als auch für Pooldatenbanken die Langzeitaufbewahrung (LTR) konfigurieren.

Für andere Dienstebenen als Hyperscale verwendet Azure SQL-Datenbank die SQL Server-Modultechnologie zum Sichern und Wiederherstellen von Daten. Hyperscale-Datenbanken verwenden Sicherung und Wiederherstellung basierend auf Speichermomentaufnahmen. Bei der herkömmlichen Sicherungstechnologie von SQL Server dauern Sicherung und Wiederherstellung größerer Datenbanken länger. Durch die Verwendung von Momentaufnahmen bietet Hyperscale sofortige Sicherungs- und schnelle Wiederherstellungsfunktionen unabhängig von der Datenbankgröße. Weitere Informationen finden Sie unter Hyperscale-Sicherungen.

Sicherungshäufigkeit

Azure SQL-Datenbank erstellt Folgendes:

• Vollständige Sicherungen jede Woche.
• Differenzielle Sicherungen alle 12 oder 24 Stunden.
• Transaktionsprotokollsicherungen etwa alle 10 Minuten.

Die exakte Häufigkeit von Transaktionsprotokollsicherungen basiert auf der Computegröße und dem Umfang der Datenbankaktivität. Wenn Sie eine Datenbank wiederherstellen, bestimmt der Dienst, welche vollständigen und differenziellen Sicherungen bzw. Transaktionsprotokollsicherungen wiederhergestellt werden müssen.

Die Hyperscale-Architektur erfordert keine Voll-, Differenz- oder Protokoll-Backups. Weitere Informationen finden Sie unter Hyperscale-Sicherungen.

Redundanz für Sicherungsspeicher

Der Speicherredundanzmechanismus speichert mehrere Kopien Ihrer Daten, sodass sie bei geplanten und nicht geplanten Ereignissen geschützt sind. Zu diesen Ereignissen können vorübergehende Hardwarefehler, Netzwerk- oder Stromausfälle sowie Naturkatastrophen gehören.

Standardmäßig speichern neue Datenbanken in Azure SQL-Datenbank Sicherungen in georedundanten Speicherblobs, die in einer gepaarten Region repliziert werden. Georedundanz schützt vor Ausfällen, die den Sicherungsspeicher in der primären Region beeinträchtigen. Außerdem können Sie Ihre Datenbanken im Falle eines regionalen Ausfalls in einer anderen Region wiederherstellen.

Das Azure-Portal bietet eine Workload-Umgebungsoption, mit der einige Konfigurationseinstellungen vorab festgelegt werden können. Diese Einstellungen können überschrieben werden. Diese Option gilt nur für die Portalseite SQL-Datenbank erstellen.

• Wenn Sie die Entwicklungsworkloadumgebung auswählen, wird die Option Speicherredundanz sichern auf die Verwendung lokal redundanter Speicher festgelegt. Lokal redundanter Speicher verursacht weniger Kosten und ist für Vorproduktionsumgebungen geeignet, die nicht die Redundanz von zonen- oder georepliziertem Speicher benötigen.
• Wenn Sie die Produktionsworkloadumgebung auswählen, wird die Sicherungsspeicherredundanz auf georedundanten Speicher festgelegt, der Standardwert.
• Die Workload-Umgebungsoption ändert auch die anfängliche Einstellung für die Berechnung, obwohl dies außer Kraft gesetzt werden kann. Andernfalls hat die Workload-Umgebungsoption keine Auswirkungen auf die Lizenzierung oder andere Datenbankkonfigurationseinstellungen.

Damit Ihre Sicherungen in der Region verbleiben, in der Ihre Datenbank bereitgestellt wird, können Sie die Sicherungsspeicherredundanz vom standardmäßigen georedundanten Speicher in andere Speichertypen ändern, die Ihre Daten innerhalb der Region beibehalten. Die konfigurierte Sicherungsspeicherredundanz wird sowohl auf kurzfristige Aufbewahrungssicherungen (STR) als auch auf LTR-Sicherungen angewendet. Weitere Informationen zur Speicherredundanz finden Sie unter Datenredundanz.

Sie können die Sicherungsspeicherredundanz konfigurieren, wenn Sie Ihre Datenbank erstellen, und Sie können sie später aktualisieren. Änderungen, die Sie an einer vorhandenen Datenbank vornehmen, gelten nur für zukünftige Sicherungen. Nachdem Sie Sicherungsspeicherredundanz einer vorhandenen Datenbank aktualisiert haben, kann es bis zu 48 Stunden dauern, bis die Änderungen angewendet werden.

Sie können eine der folgenden Speicherredundanzen für Sicherungen auswählen:

• Lokal redundanter Speicher (LRS): Die Sicherungen werden dreimal synchron innerhalb eines einzelnen physischen Standorts in der primären Region kopiert. LRS ist die am wenigsten kostenintensive Speicheroption, aber wir empfehlen sie nicht für Anwendungen, für die Resilienz bei regionalen Ausfällen oder eine Garantie für hohe Datendauerhaftigkeit erforderlich ist.

  

• Zonenredundanter Speicher (ZRS): Die Sicherungen werden synchron in drei Azure-Verfügbarkeitszonen in der primären Region kopiert. Diese Redundanzart ist derzeit nur in bestimmten Regionen verfügbar.

  

• Georedundanter Speicher (GRS): Die Sicherungen werden synchron dreimal innerhalb eines einzelnen physischen Standorts in der primären Region unter Verwendung von LRS kopiert. Anschließend werden die Daten asynchron dreimal an einen einzelnen physischen Standort in der gekoppelten sekundären Region kopiert.

  Es wird folgendes Ergebnis ausgegeben:

  • Drei synchrone Kopien in der primären Region.
  • Drei synchrone Kopien in der gekoppelten Region, die asynchron von der primären Region in die sekundäre Region kopiert wurden.

  

• Geozonenredundanter Speicher (GZRS): Mit geozonenredundantem Speicher (GZRS) wird die Hochverfügbarkeit durch Redundanz über Verfügbarkeitszonen hinweg (ZRS) mit dem Schutz vor regionalen Ausfällen kombiniert, der durch Georeplikation (GRS) geboten wird. Kopiert Ihre Sicherungen synchron über drei Azure-Verfügbarkeitszonen in der primären Region und asynchron dreimal an einen einzelnen physischen Standort in der gekoppelten sekundären Region.

  Microsoft empfiehlt die Verwendung von GZRS für Anwendungen, die maximale Konsistenz, Dauerhaftigkeit und Verfügbarkeit, hervorragende Leistung und Resilienz bei der Notfallwiederherstellung erfordern.

  Das Ergebnis ist:

  • Drei synchrone Kopien über Verfügbarkeitszonen in der primären Region.

  • Drei synchrone Kopien in der gekoppelten Region, asynchron von der primären Region in die sekundäre Region kopiert.

    Das folgende Diagramm zeigt, wie Ihre Daten mit GZRS oder RA-GZRS repliziert werden:

  

Warnung

• Geowiederherstellung wird deaktiviert, sobald die Datenbank so aktualisiert wurde, dass lokal redundanter oder zonenredundanter Speicher verwendet wird.
• Alle Diagramme mit den Speicherredundanzen zeigen Regionen mit mehreren Verfügbarkeitszonen (multi-az). Es gibt jedoch Regionen, die nur eine einzelne Verfügbarkeitszone bereitstellen und ZRS nicht unterstützen.
• Die Sicherungsspeicherredundanz für Hyperscale-Datenbanken kann nur während der Erstellung festgelegt werden. Sie können diese Einstellung nach der Bereitstellung der Ressource nicht ändern. Verwenden Sie aktive Georeplikation, um Einstellungen für die Sicherungsspeicherredundanz für eine vorhandene Hyperscale-Datenbank mit minimaler Downtime zu aktualisieren. Alternativ können Sie Datenbankkopie verwenden. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Sicherungsverwendung

Sie können automatisch erstellte Sicherungen in den folgenden Szenarien verwenden:

• Wiederherstellen einer vorhandenen Datenbank zu einem bestimmten Zeitpunkt innerhalb des Aufbewahrungszeitraums, indem Sie das Azure-Portal, Azure PowerShell, die Azure CLI oder die REST-API verwenden. Bei diesem Vorgang wird eine neue Datenbank auf demselben Server erstellt, auf dem sich auch die Originaldatenbank befindet, aber es wird ein anderer Name verwendet, damit die Originaldatenbank nicht überschrieben wird.

  Nach Abschluss der Wiederherstellung können Sie optional die ursprüngliche Datenbank löschen und der wiederhergestellten Datenbank wieder den ursprünglichen Datenbanknamen geben. Alternativ dazu können Sie die ursprüngliche Datenbank, anstatt sie zu löschen, umbenennen und dann die wiederhergestellte Datenbank mit dem ursprünglichen Datenbanknamen umbenennen.

• Wiederherstellen einer gelöschten Datenbank zu einem bestimmten Zeitpunkt innerhalb des Aufbewahrungszeitraums, einschließlich des Zeitpunkts der Löschung. Die gelöschte Datenbank kann nur auf dem Server wiederhergestellt werden, auf dem die ursprüngliche Datenbank erstellt wurde. Bevor Sie eine Datenbank löschen, nimmt der Dienst eine abschließende Transaktionsprotokollsicherung vor, um Datenverluste zu vermeiden.

• Wiederherstellen einer Datenbank in einer anderen geografischen Region. Die Geowiederherstellung ermöglicht die Wiederherstellung nach einem regionalen Ausfall, wenn Sie keinen Zugriff mehr auf Ihre Datenbank oder Ihre Sicherungen in der primären Region haben. Dabei wird eine neue Datenbank auf einem beliebigen vorhandenen Server in einer beliebigen Azure-Region erstellt.

  Wichtig

  Die Geowiederherstellung ist nur für Datenbanken verfügbar, die mit georedundantem Sicherungsspeicher konfiguriert wurden. Wenn Sie derzeit keine georeplizierten Sicherungen für eine Datenbank verwenden, können Sie dies durch Konfigurieren der Sicherungsspeicherredundanz ändern.

• Wiederherstellen einer Datenbank aus einer bestimmten langfristigen Sicherung einer Einzel- oder Pooldatenbank, sofern die Datenbank mit einer LTR-Richtlinie konfiguriert wurde. Mit LTR können Sie eine ältere Version der Datenbank wiederherstellen, indem Sie das Azure-Portal, die Azure CLI oder Azure PowerShell verwenden, um eine Konformitätsanforderung zu erfüllen oder eine ältere Version der Anwendung auszuführen. Weitere Informationen finden Sie unter Langfristige Aufbewahrung.

Warnung

Wenn bei der Wiederherstellung einer Datenbank die Redundanz des Quell-Sicherungsspeichers als geozonenredundanter Speicher (Geo-Zone Redundant Storage (GZRS)) konfiguriert ist, wird die Konfiguration des Quell-Sicherungsspeichers von der neuen Datenbank übernommen, wenn die Konfiguration der Redundanz des Sicherungsspeichers für die Zieldatenbank nicht explizit angegeben wird. Dazu gehören alle Wiederherstellungsvorgänge, z. B. Point-in-Time-Wiederherstellung, Datenbankkopie, Geowiederherstellung, Wiederherstellung aus einer langfristigen Sicherung. Wenn die Azure-Zielregion während dieses Vorgangs die spezifische Redundanz des Sicherungsspeichers nicht unterstützt, schlägt der Wiederherstellungsvorgang mit der entsprechenden Fehlermeldung fehl. Dies kann verhindert werden, indem die verfügbaren Speicheroptionen für die Region explizit angegeben werden.

Automatische Sicherungen auf sekundären Replikaten

Automatische Sicherungen werden jetzt auf der Dienstebene Unternehmenskritisch aus einem sekundären Replikat erstellt. Da die Daten zwischen SQL Server-Prozessen auf jedem Knoten repliziert werden, erstellt der Sicherungsdienst die Sicherung aus den nicht lesbaren sekundären Replikaten. Dieses Konzept stellt sicher, dass das primäre Replikat weiter für Ihre Hauptworkload dient und das lesbare sekundäre Replikat für schreibgeschützte Workloads dient. Automatische Sicherungen werden auf der Dienstebene „Unternehmenskritisch“ zumeist aus einem sekundären Replikat erstellt. Wenn eine automatische Sicherung bei einem sekundären Replikat fehlschlägt, erstellt der Sicherungsdienst die Sicherung aus dem primären Replikat.

Automatische Sicherungen auf sekundären Replikaten:

• Sind standardmäßig aktiviert.
• Sind ohne zusätzliche Kosten auf den Preis der Dienstebene inbegriffen.
• Verbessern Sie die Leistung und Vorhersehbarkeit der Dienstebene „Unternehmenskritisch“.

Hinweis

• Erstellen Sie ein Microsoft-Supportticket, um das Feature für Ihre Instanz zu deaktivieren.

Funktionen und Features für die Wiederherstellung

In dieser Tabelle sind die Funktionen und Features der Zeitpunktwiederherstellung (PITR), der Geowiederherstellung und der Langzeitaufbewahrung zusammengefasst.

Sicherungseigenschaft	PITR	Geowiederherstellung	LTR
Typen der SQL-Sicherung	Vollständig, differenzieller, Log.	Aktuelle georeplizierte Kopien von PITR-Sicherungen.	Nur die vollständigen Sicherungen.
Recovery Point Objective (RPO)	10 Minuten, basierend auf der Computegröße und dem Umfang der Datenbankaktivität.	Bis zu 1 Stunde, basierend auf der Georeplikation. 1	Eine Woche (oder Benutzerrichtlinie).
Recovery Time Objective (RTO)	Die Wiederherstellung dauert normalerweise weniger als 12 Stunden, könnte aber je nach Größe und Aktivität auch länger dauern. Siehe Wiederherstellung.	Die Wiederherstellung dauert normalerweise weniger als 12 Stunden, könnte aber je nach Größe und Aktivität auch länger dauern. Siehe Wiederherstellung.	Die Wiederherstellung dauert normalerweise weniger als 12 Stunden, könnte aber je nach Größe und Aktivität auch länger dauern. Siehe Wiederherstellung.
Vermerkdauer	7 Tage standardmäßig, konfigurierbar in zwischen 1 und 35 Tagen (mit Ausnahme von Basic-Datenbanken, die zwischen 1 und 7 Tagen konfigurierbar sind).	Standardmäßig aktiviert, identisch mit der Quelle.2	Standardmäßig nicht aktiviert. Aufbewahrungsdauer bis zu 10 Jahre.
Azure Storage	Standardmäßig zonenredundant. Sie können optional zonenredundanten oder lokal redundanten Speicher konfigurieren.	Verfügbar, wenn die PITR-Sicherungsspeicherredundanz auf „Georedundant“ festgelegt ist. Nicht verfügbar, wenn es sich beim Zeitpunktwiederherstellungs-Sicherungsspeicher um zonenredundanten oder lokal redundanten Speicher handelt.	Standardmäßig zonenredundant. Sie können zonenredundanten oder lokal redundanten Speicher konfigurieren.
Konfigurieren von Sicherungen als unveränderlich	Nicht unterstützt	Nicht unterstützt	Nicht unterstützt
Wiederherstellen einer neuen Datenbank in derselben Region	Unterstützt	Unterstützt	Unterstützt
Wiederherstellen einer neuen Datenbank in einer anderen Region	Nicht unterstützt	In allen Azure-Regionen unterstützt	In allen Azure-Regionen unterstützt
Wiederherstellen einer neuen Datenbank in einem anderen Abonnement	Nicht unterstützt	Nicht unterstützt3	Nicht unterstützt3
Wiederherstellen über das Azure Portal	Ja	Ja	Ja
Wiederherstellen über PowerShell	Ja	Ja	Ja
Wiederherstellen über die Azure CLI	Ja	Ja	Ja

¹ Verwenden Sie für unternehmenskritische Anwendungen, die große Datenbanken erfordern und die Geschäftskontinuität sicherstellen müssen, Failovergruppen.
² Alle Zeitpunktwiederherstellungssicherungen werden standardmäßig in georedundanten Speicher gespeichert. Daher ist die Geowiederherstellung standardmäßig aktiviert.
³ Die Problemumgehung besteht darin, auf einem neuen Server wiederherzustellen und Ressourcenverschiebung zu verwenden, um den Server in eine andere Subscription zu verschieben, oder verwenden Sie eine subscriptionübergreifende Datenbankkopie.

Wiederherstellen einer Datenbank aus einer Sicherung

Informationen zum Durchführen einer Wiederherstellung finden Sie unter Wiederherstellen einer Datenbank aus Sicherungen. Anhand der folgenden Beispiele können Sie sich mit den Vorgängen für Sicherungskonfiguration und Wiederherstellung vertraut machen.

Vorgang	Azure-Portal	Azure CLI	Azure PowerShell
Ändern der Sicherungsaufbewahrung	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance
Ändern der Langzeitaufbewahrung von Sicherungen	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance
Wiederherstellen einer Datenbank bis zu einem Zeitpunkt	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance
Wiederherstellen einer gelöschten Datenbank	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance	SQL-Datenbank SQL Managed Instance

Exportieren einer Datenbank

Automatische Backups, die vom Azure-Dienst erstellt werden, können nicht direkt heruntergeladen oder abgerufen werden. Sie können nur für Wiederherstellungsvorgänge über Azure genutzt werden.

Es gibt Alternativen zum Exportieren einer Azure SQL-Datenbank. Wenn Sie eine Datenbank zur Archivierung oder zum Verschieben auf eine andere Plattform exportieren müssen, können Sie das Datenbankschema und die Daten in eine BACPAC-Datei exportieren. Eine BACPAC-Datei ist eine ZIP-Datei mit der Erweiterung BACPAC. Sie enthält die Metadaten und Daten aus der Datenbank. Eine BACPAC-Datei kann in Azure Blob Storage oder im lokalen Speicher an einem lokalen Standort gespeichert werden und dann zurück in Azure SQL-Datenbank, Azure SQL Managed Instance oder in eine SQL Server-Instanz importiert werden.

Außerdem können Sie eine Azure SQL-Datenbank über eine private Verbindung importieren oder exportieren oder eine Azure SQL-Datenbank importieren oder exportieren, ohne Azure-Diensten Zugriff auf den Server zu erlauben.

Sicherungszeitplanung

Die erste vollständige Sicherung wird unmittelbar nach dem Erstellen oder Wiederherstellen einer neuen Datenbank geplant. Diese Sicherung wird normalerweise innerhalb von 30 Minuten abgeschlossen, kann aber länger dauern, wenn die Datenbank groß ist. Die erste Sicherung kann bei einer wiederhergestellten Datenbank oder einer Datenbankkopie beispielsweise länger dauern, da diese normalerweise größer als eine neue Datenbank ist.

Nach der ersten vollständigen Sicherung werden alle weiteren Sicherungen automatisch geplant und verwaltet. Die genaue Zeitplanung für alle Datenbanksicherungen wird vom SQL-Datenbank-Dienst je nach der gesamten Systemworkload bestimmt. Sie können den Zeitplan der Sicherungsaufträge nicht ändern oder sie deaktivieren.

Wichtig

• Für eine neue, wiederhergestellte oder kopierte Datenbank wird die Funktion für die Zeitpunktwiederherstellung verfügbar, wenn die erste Transaktionsprotokollsicherung, die auf die anfängliche vollständige Sicherung folgt, erstellt wird.
• Hyperscale-Datenbanken sind unmittelbar nach der Erstellung geschützt, im Gegensatz zu anderen Datenbanken, bei denen die anfängliche Sicherung Zeit in Anspruch nimmt. Der Schutz erfolgt unmittelbar, auch wenn die Hyperscale-Datenbank mit einer großen Datenmenge über Kopie oder Wiederherstellung erstellt wurde. Weitere Informationen finden Sie unter Automatisierte Hyperscale-Sicherungen.

Sicherungsspeicherverbrauch

Bei der Sicherungs- und Wiederherstellungstechnologie von SQL Server setzt das Wiederherstellen einer Datenbank zu einem bestimmten Zeitpunkt eine ununterbrochene Sicherungskette voraus. Diese Kette besteht aus einer vollständigen Sicherung, optional einer differenziellen Sicherung und einer oder mehreren Transaktionsprotokollsicherungen.

Bei Azure SQL-Datenbank ist wöchentlich eine vollständige Sicherung geplant. Um die Zeitpunktwiederherstellung innerhalb des gesamten Aufbewahrungszeitraums bereitzustellen, muss das System zusätzlich vollständige, differenzielle und Transaktionsprotokollsicherungen für bis zu eine Woche über den konfigurierten Aufbewahrungszeitraum hinaus speichern.

Anders ausgedrückt: Für jeden Zeitpunkt innerhalb des Aufbewahrungszeitraums muss eine vollständige Sicherung vorhanden sein, die älter ist als der älteste Zeitpunkt des Aufbewahrungszeitraums. Es muss zudem eine ununterbrochene Kette von differenziellen und Transaktionsprotokollsicherungen von dieser vollständigen Sicherung bis zur nächsten vollständigen Sicherung vorhanden sein.

Hyperscale-Datenbanken verwenden einen anderen Sicherungsplanungsmechanismus. Weitere Informationen finden Sie unter Hyperscale-Sicherungsplanung.

Sicherungen, die für die Bereitstellung der PITR-Funktionalität nicht mehr erforderlich sind, werden automatisch gelöscht. Da differenzielle Sicherungen und Protokollsicherungen erst wiederhergestellt werden können, wenn zuvor eine vollständige Sicherung erfolgt ist, werden alle drei Sicherungstypen in wöchentlichen Blöcken gemeinsam bereinigt.

Für alle Datenbanken, einschließlich TDE-verschlüsselter Datenbanken, werden alle vollständigen und differenziellen Sicherungen komprimiert, um die Komprimierung des Sicherungsspeichers und die Kosten zu reduzieren. Das durchschnittliche Sicherungskomprimierungsverhältnis beträgt 3 bis 4 Mal. Dieses kann jedoch je nach Art der Daten und der Verwendung der Datenkomprimierung in der Datenbank niedriger oder höher ausfallen.

Wichtig

Bei TDE-verschlüsselten Datenbanken werden die Protokollsicherungsdateien aus Leistungsgründen nicht komprimiert. Protokollsicherungen für nicht TDE-verschlüsselte Datenbanken werden komprimiert.

Azure SQL-Datenbank berechnet den gesamten Sicherungsspeicher als kumulativen Wert. Dieser Wert wird stündlich an die Azure-Abrechnungspipeline gemeldet. Die Pipeline ist für die Aggregierung dieser stündlichen Nutzung verantwortlich, damit die Nutzung am Ende jedes Monats berechnet werden kann. Nach dem Löschen der Datenbank sinkt der Verbrauch mit zunehmendem Alter (und dem schließlichen Löschen) der Sicherungen. Wenn alle Sicherungen gelöscht wurden und keine Zeitpunktwiederherstellung mehr möglich ist, endet die Abrechnung.

Wichtig

Sicherungen einer Datenbank werden beibehalten, um Point-in-Time-Wiederherstellungen auch dann bereitzustellen, wenn die Datenbank gelöscht wurde. Obwohl das Löschen und erneute Erstellen einer Datenbank Speicher- und Berechnungskosten sparen kann, können dadurch die Kosten für Sicherungsspeicher erhöht werden. Der Grund dafür ist, dass der Dienst Sicherungen für jede gelöschte Datenbank bei jedem Löschvorgang beibehält.

Überwachen des Verbrauchs

Für Datenbanken mit virtuellen Kernen in Azure SQL-Datenbank wird der von jedem Sicherungstyp (vollständig, differenziell und Protokoll) verbrauchte Speicher im Bereich der Datenbanküberwachung als separate Metrik ausgewiesen. Der folgende Screenshot zeigt, wie Sie den Sicherungsspeicherverbrauch für eine Einzeldatenbank überwachen.

Anweisungen zum Überwachen des Verbrauchs in Hyperscale finden Sie unter Überwachen des Hyperscale-Sicherungsverbrauchs.

Optimieren des Sicherungsspeicherverbrauchs

Der Speicherverbrauch für Sicherungen bis zur maximalen Datengröße für eine Datenbank wird nicht in Rechnung gestellt. Der zusätzliche Sicherungsspeicherverbrauch hängt von der Workload und der maximalen Größe der einzelnen Datenbanken ab. Ziehen Sie einige der folgenden Optimierungstechniken in Betracht, um den Sicherungsspeicherverbrauch zu reduzieren:

• Reduzieren Sie den Aufbewahrungszeitraum für Sicherungen auf die Mindestanforderungen für Ihre Zwecke.
• Vermeiden Sie, große Schreibvorgänge, wie etwa die Neuerstellung von Indizes, häufiger als nötig durchzuführen.
• Bei umfangreichen Datenladevorgängen sollten Sie gruppierte Columnstore-Indizes verwenden und die entsprechenden Best Practices befolgen. Erwägen Sie auch, die Anzahl der nicht gruppierten Indizes zu verringern.
• Auf der Dienstebene „Universell“ ist der bereitgestellte Datenspeicher günstiger als die Kosten für den Sicherungsspeicher. Wenn ständig hohe Kosten durch zusätzlichen Sicherungsspeicher anfallen, können Sie eine Vergrößerung des Datenspeichers in Betracht ziehen, um beim Sicherungsspeicher zu sparen.
• Verwenden Sie tempdb anstelle permanenter Tabellen in Ihrer Anwendungslogik zum Speichern temporärer Ergebnisse oder vorübergehender Daten.
• Nutzen Sie nach Möglichkeit lokal redundanten Sicherungsspeicher (etwa Entwicklungs-/Testumgebungen).

Sicherungsaufbewahrung

Azure SQL-Datenbank bietet sowohl eine Kurzzeit- als auch eine Langzeitaufbewahrung von Sicherungen. Kurzfristige Aufbewahrung ermöglicht die Zeitpunktwiederherstellung innerhalb des Aufbewahrungszeitraums für die Datenbank. Langzeitaufbewahrung bietet Sicherungen für verschiedene Complianceanforderungen.

Kurzfristige Aufbewahrung

Für alle neuen, wiederhergestellten und kopierten Datenbanken bewahrt Azure SQL-Datenbank standardmäßig genügend Sicherungen auf, um eine Zeitpunktwiederherstellung innerhalb der letzten 7 Tage zu ermöglichen. Der Dienst führt regelmäßig vollständige, differenzielle und Protokollsicherungen durch, um sicherzustellen, dass Datenbanken zu jedem beliebigen Zeitpunkt innerhalb des für die Datenbank festgelegten Aufbewahrungszeitraums wiederherstellbar sind.

Differenzielle Sicherungen können so konfiguriert werden, dass sie entweder einmal in 12 Stunden oder einmal in 24 Stunden erfolgen. Eine differenzielle Sicherungshäufigkeit von 24 Stunden kann die für die Wiederherstellung der Datenbank erforderliche Zeit im Vergleich zur 12-Stunden-Häufigkeit möglicherweise erhöhen. Im virtuellen Kernmodell liegt die Standardhäufigkeit für differenzielle Sicherungen bei einmal in 12 Stunden. Im DTU-Modell liegt die Standardhäufigkeit bei einmal in 24 Stunden.

Sie können die Redundanzoption für den Sicherungsspeicher für STR angeben, wenn Sie Ihre Datenbank erstellen und diese zu einem späteren Zeitpunkt ändern. Wenn Sie die Sicherungsredundanzoption ändern, nachdem Ihre Datenbank erstellt wurde, verwenden neue Sicherungen die neue Redundanzoption. Sicherungskopien, die mit der vorherigen STR-Redundanzoption erstellt wurden, werden nicht verschoben oder kopiert. Sie verbleiben im ursprünglichen Speicherkonto, bis der Aufbewahrungszeitraum abläuft, was 1 bis 35 Tage betragen kann.

Sie können den Aufbewahrungszeitraum für Sicherungen für jede aktive Datenbank im Bereich von 1 bis 35 Tagen ändern, mit Ausnahme der Basic-Datenbanken, die von 1 bis 7 Tagen konfigurierbar sind. Wie unter Sicherungsspeicherverbrauch beschrieben, liegen Sicherungen, die zum Ermöglichen von Zeitpunktwiederherstellungen gespeichert wurden, möglicherweise zeitlich vor dem Aufbewahrungszeitraum. Wenn Sie Sicherungen länger als den maximalen kurzfristigen Aufbewahrungszeitraum von 35 Tagen aufbewahren müssen, können Sie Langzeitaufbewahrung aktivieren.

Wenn Sie eine Datenbank löschen, bewahrt das System Backups genauso lange auf wie bei einer Onlinedatenbank. Der Aufbewahrungszeitraum für eine gelöschte Datenbank kann nicht geändert werden.

Wichtig

Wenn Sie einen Server löschen, werden auch alle Datenbanken auf dem Server gelöscht und können nicht wiederhergestellt werden. Es ist nicht möglich, einen gelöschten Server wiederherzustellen. Wenn Sie jedoch die Langzeitaufbewahrung für eine Datenbank konfiguriert haben, werden LTR-Sicherungen nicht gelöscht. Sie können diese Sicherungen dann verwenden, um Datenbanken auf einem anderen Server in derselben Subscription zu einem Zeitpunkt wiederherzustellen, an dem eine LTR-Sicherung ausgeführt wurde. Weitere Informationen finden Sie unter Wiederherstellen langfristiger Sicherungen.

Langfristige Aufbewahrung

Für Azure SQL-Datenbank können Sie vollständige LTR-Sicherungen (Long-Term Retention) bis zu 10 Jahre lang in Azure Blob Storage konfigurieren. Nachdem die LTR-Richtlinie konfiguriert wurde, werden vollständige Sicherungen wöchentlich automatisch in einen anderen Speichercontainer kopiert.

Zur Einhaltung verschiedener Complianceanforderungen können Sie verschiedene Aufbewahrungszeiträume für wöchentliche, monatliche oder jährliche vollständige Sicherungen auswählen. Die Häufigkeit hängt von der Richtlinie ab. Beispielsweise würde durch Festlegen von W=0, M=1 monatlich eine LTR-Kopie erstellt werden. Weitere Informationen zu LTR finden Sie unter Langfristige Aufbewahrung.

Das Aktualisieren der Sicherungsspeicherredundanz für eine vorhandene Datenbank wendet die Änderung nur auf nachfolgende Sicherungen an, die in Zukunft ausgeführt werden, und nicht auf vorhandene Sicherungen. Alle vorhandenen LTR-Sicherungen für die Datenbank verbleiben weiterhin im vorhandenen Speicher-Blob. Neue Sicherungen werden basierend auf der konfigurierten Sicherungsspeicherredundanz repliziert.

Der Speicherverbrauch ist abhängig von der ausgewählten Häufigkeit und den Aufbewahrungszeiträumen für LTR-Sicherungen. Sie können den LTR-Preisrechner verwenden, um die Kosten für den LTR-Speicher zu schätzen.

Bei der Wiederherstellung einer Hyperscale-Datenbank mithilfe einer LTR-Sicherung wird die Eigenschaft für die Leseskalierung deaktiviert. Aktualisieren Sie die Datenbank nach ihrer Erstellung, um die Leseskalierung für die wiederhergestellte Datenbank zu aktivieren. Beim Wiederherstellen aus einer LTR-Sicherung müssen Sie das Servicelevelziel angeben.

LTR (Long-Term Retention) kann für Hyperscale-Datenbanken aktiviert werden, die von anderen Dienstebenen erstellt oder migriert werden. Wenn Sie versuchen, LTR für eine Hyperscale-Datenbank zu aktivieren, die noch nicht unterstützt wird, erhalten Sie folgende Fehlermeldung: "Bei der Aktivierung der langfristigen Sicherungsaufbewahrung für diese Datenbank ist ein Fehler aufgetreten. Wenden Sie sich an den Microsoft-Support, um die langfristige Aufbewahrung von Backups zu ermöglichen. Wenden Sie sich in diesem Fall an den Microsoft-Support, und erstellen Sie zur Lösung ein Supportticket.

Kosten von Sicherungsspeicher

Der Preis für Sicherungsspeicher variiert und ist abhängig von Ihrem Kaufmodell (DTU oder virtueller Kern), der ausgewählten Option für die Sicherungsspeicherredundanz und Ihrer Region. Die Kosten für den Sicherungsspeicher werden auf Grundlage der verbrauchten Gigabytes pro Monat mit derselben Rate für alle Sicherungen berechnet.

Die Redundanz für Sicherungsspeicher wirkt sich auf Sicherungskosten folgendermaßen aus:

• Locally redundant price = published price
• Zone-redundant price = published price x 1.25
• Geo-redundant price = published price x 2

Informationen zu Preisen finden Sie auf der Seite Azure SQL-Datenbank – Preise.

Hinweis

Auf der Azure-Rechnung wird nur der zusätzlich verbrauchte, nicht der insgesamt verbrauchte Sicherungsspeicher aufgeführt. Angenommen, Sie haben einen Datenspeicher mit einer Größe 4 TB bereitgestellt. In diesem Fall sind die 4 TB Sicherungsspeicher für Sie kostenlos. Wenn Sie insgesamt 5,8 TB Sicherungsspeicherplatz verwenden, enthält die Azure-Rechnung nur 1,8 TB an, da Ihnen nur der zusätzliche Sicherungsspeicher in Rechnung gestellt wird, den Sie verwendet haben.

DTU-Modell

Im DTU-Modell fallen für Datenbanken und Pools für elastische Datenbanken keine zusätzlichen Gebühren für PITR-Sicherungsspeicher für die Standardaufbewahrung von 7 Tagen und darüber hinaus an. Der Preis für den PITR-Sicherungsspeicher ist im Preis für die Datenbank oder den Pool inbegriffen.

Wichtig

Im DTU-Modell werden Datenbanken und Pools für elastische Datenbanken für den LTR-Sicherungsspeicher basierend auf dem tatsächlich von LTR-Sicherungen belegten Speicher in Rechnung gestellt.

V-Kern-Modell

Azure SQL-Datenbank berechnet den gesamten abrechenbaren Sicherungsspeicher als kumulativen Wert für alle Sicherungsdateien. Dieser Wert wird stündlich an die Azure-Abrechnungspipeline gemeldet. Die Pipeline aggregiert diese stündliche Nutzung, damit der Verbrauch an Sicherungsspeicher am Ende jedes Monats berechnet werden kann.

Wenn eine Datenbank gelöscht wird, nimmt der Speicherverbrauch für die Sicherung allmählich ab, da ältere Sicherungen das maximale Alter erreichen und gelöscht werden. Da differenzielle Sicherungen und Protokollsicherungen erst wiederhergestellt werden können, wenn zuvor eine vollständige Sicherung erfolgt ist, werden alle drei Sicherungstypen in wöchentlichen Blöcken gemeinsam bereinigt. Nachdem alle Sicherungen gelöscht wurden, endet die Abrechnung.

Die Sicherungsspeicherkosten werden für Hyperscale-Datenbanken anders berechnet. Weitere Informationen finden Sie unter Kosten des Hyperscale-Sicherungsspeichers.

Bei Einzeldatenbanken wird ohne Aufpreis Sicherungsspeicherplatz in Höhe von 100 Prozent der maximalen Datenspeichergröße für die Datenbank bereitgestellt. Die folgende Gleichung wird zur Berechnung des gesamten abrechenbaren Sicherungsspeicherverbrauchs verwendet:

Total billable backup storage size = (size of full backups + size of differential backups + size of log backups) – maximum data storage

Für Pools für elastische Datenbanken wird ein Sicherungsspeicher in Höhe von 100 Prozent des maximalen Datenspeichers für die Poolspeichergröße ohne Aufpreis bereitgestellt. Für Pooldatenbanken wird die Gesamtgröße des abrechenbaren Sicherungsspeichers auf Poolebene aggregiert und wie folgt berechnet:

Total billable backup storage size = (total size of all full backups + total size of all differential backups + total size of all log backups) - maximum pool data storage

Der gesamte abrechenbare Sicherungsspeicher wird in Gigabyte pro Monat gemäß der Rate der von Ihnen verwendeten Sicherungsspeicherredundanz in Rechnung gestellt. Der Sicherungsspeicherverbrauch ist von der Workload und der Größe der einzelnen Datenbanken, der Pools für elastische Datenbanken und verwalteten Instanzen abhängig. Datenbanken mit vielen Änderungen weisen größere differenzielle Sicherungen und Protokollsicherungen auf, da die Größe dieser Sicherungen proportional zur Menge der geänderten Daten ist. Daher fallen für solche Datenbanken höhere Backup-Gebühren an.

Nehmen Sie als vereinfachtes Beispiel an, dass eine Datenbank 744 GB Sicherungsspeicher angesammelt hat und diese Menge während eines ganzen Monats konstant bleibt, weil die Datenbank vollkommen inaktiv ist. Um diesen kumulativen Speicherverbrauch in eine stündliche Nutzung umzurechnen, dividieren Sie ihn durch 744,0 (31 Tage pro Monat x 24 Stunden pro Tag). SQL Database meldet der Azure-Abrechnungspipeline, dass die Datenbank stündlich 1 GB PITR-Backup verbraucht hat, und zwar mit einer konstanten Rate. Die Azure-Abrechnung aggregiert dies und zeigt eine Nutzung von 744 GB für den gesamten Monat. Die Kosten basierend auf dem EUR/GB/Monat-Satz in Ihrer Region an. Die Kosten richten sich nach dem Satz für Gigabytes pro Monat in Ihrer Region.

Hier sehen Sie ein weiteres Beispiel. Angenommen, für dieselbe inaktive Datenbank wird der Aufbewahrungszeitraum in der Mitte des Monats von 7 Tagen auf 14 Tage erhöht. Diese Zunahme führt dazu, dass sich der gesamte Sicherungsspeicher auf 1.488 GB verdoppelt. SQL-Datenbank meldet eine Nutzung von 1 GB für die Stunden 1 bis 372 (die erste Monatshälfte). Die Nutzung wird als 2 GB für die Stunden 373 bis 744 (die zweite Monatshälfte) gemeldet. Die monatliche Schlussrechnung basiert dann auf dem aggregierten Wert von 1.116 GB pro Monat.

Die tatsächlichen Abrechnungsszenarien für Sicherungen sind komplexer. Da die Rate von Änderungen in der Datenbank von der Workload abhängig und zeitlich variabel ist, variiert auch die Größe der einzelnen differenziellen und Protokollsicherungen. Der stundenweise Verbrauch des Sicherungsspeichers schwankt entsprechend.

Jede differenzielle Sicherung enthält auch alle Änderungen, die seit der letzten vollständigen Sicherung in der Datenbank vorgenommen wurden. Daher erhöht sich die Gesamtgröße aller differenziellen Sicherungen schrittweise im Laufe einer Woche. Dann sinkt sie rapide, nachdem ein älterer Satz von vollständigen, differenziellen und Protokollsicherungen veraltet ist.

Nehmen Sie zum Beispiel an, dass eine umfangreiche Schreibaktivität, wie eine Indexneuerstellung, unmittelbar nach Abschluss einer vollständigen Sicherung erfolgt. Die Änderungen, die die Indexneuerstellung vornimmt, werden dann im Folgenden berücksichtigt:

• In den Transaktionsprotokollsicherungen, die während der Dauer der Neuerstellung erstellt werden.
• In der nächsten differenziellen Sicherung.
• In jeder differenziellen Sicherung, die bis zur nächsten vollständigen Sicherung durchgeführt wird.

Beim letzten Szenario erstellt eine Optimierung am Dienst für größere Datenbanken eine vollständige anstelle einer differenziellen Sicherung, wenn eine differenzielle Sicherung übermäßig groß wäre. Dadurch wird die Größe aller differenziellen Sicherungen bis zur folgenden vollständigen Sicherung verringert.

Sie können den gesamten Sicherungsspeicherverbrauch für jeden Sicherungstyp (vollständig, differenziell, Transaktionsprotokoll) über einen bestimmten Zeitraum überwachen, wie unter Überwachen des Verbrauchs beschrieben.

Überwachen der Kosten

Um die Kosten für Sicherungsspeicher zu verstehen, wechseln Sie im Azure-Portal zu Kostenverwaltung + Abrechnung. Wählen Sie Kostenverwaltung und dann Kostenanalyse aus. Wählen Sie die gewünschte Subscription für Bereich aus, und filtern Sie dann wie folgt nach dem gewünschten Zeitraum und Dienst:

1. Fügen Sie einen Filter für Dienstname hinzu.

2. Wählen Sie in der Dropdownliste sql database für eine Einzeldatenbank oder einen Pool für elastische Datenbanken aus.

3. Fügen Sie einen weiteren Filter für Unterkategorie der Verbrauchseinheit hinzu.

4. Wählen Sie zum Überwachen der Kosten für Zeitpunktwiederherstellungssicherungen für eine Einzeldatenbank oder einen Pool für elastische Datenbanken in der Dropdownliste PITR-Sicherungsspeicher für eine einzelne Datenbank/einen Pool für elastische Datenbanken aus. „Verbrauchseinheit“ wird nur angezeigt, wenn der Sicherungsspeicherverbrauch vorhanden ist.

   Wählen Sie zum Überwachen der Kosten für LTR-Sicherungen für eine Einzeldatenbank oder einen Pool für elastische Datenbanken in der Dropdownliste LTR-Sicherungsspeicher aus. „Verbrauchseinheit“ wird nur angezeigt, wenn der Sicherungsspeicherverbrauch vorhanden ist.

Die Unterkategorien Speicher und Compute können für Sie auch von Interesse sein, obwohl sie nicht im Zusammenhang mit den Sicherungsspeicherkosten stehen.

Wichtig

Verbrauchseinheiten sind nur für zurzeit verwendete Zähler sichtbar. Wenn ein Zähler nicht zur Verfügung steht, wird die entsprechende Kategorie zurzeit wahrscheinlich nicht verwendet. Beispielsweise sind Speicherzähler für Ressourcen, die keinen Speicher belegen, nicht sichtbar. Wenn der Zeitpunktwiederherstellungs- oder LTR-Sicherungsspeicher nicht genutzt wird, werden diese Verbrauchseinheiten nicht angezeigt.

Weitere Informationen finden Sie unter Kostenverwaltung für die Azure SQL-Datenbank.

Verschlüsselte Sicherungen

Wenn Ihre Datenbank mit TDE verschlüsselt ist, werden Sicherungen im Ruhezustand, einschließlich LTR-Sicherungen, automatisch verschlüsselt. Bei allen neuen Datenbanken in Azure SQL ist TDE standardmäßig aktiviert. Weitere Informationen zu TDE finden Sie unter Transparent Data Encryption mit SQL-Datenbank.

Sicherungsintegrität

Das Azure SQL-Entwicklungsteam testet fortlaufend automatisch die Wiederherstellung von automatischen Datenbanksicherungen. Bei der Point-in-Time-Wiederherstellung werden die Datenbanken außerdem mithilfe von DBCC CHECKDB Integritätsprüfungen unterzogen.

Mögliche Probleme, die bei einer Integritätsprüfung gefunden werden, führen zu einer Warnung des Entwicklungsteams. Weitere Informationen finden Sie unter Datenintegrität in Azure SQL-Datenbank.

Alle Datenbanksicherungen werden mit der Option „CHECKSUM“ erstellt, um eine zusätzliche Sicherungsintegrität zu gewährleisten.

Compliance

Wenn Sie Ihre Datenbank von einer DTU-basierten Dienstebene zu einer Dienstebene auf Basis virtueller Kerne migrieren, wird die PITR-Aufbewahrung beibehalten. So soll sichergestellt werden, dass die Datenwiederherstellungsrichtlinie Ihrer Anwendung nicht kompromittiert wird. Falls die Standardaufbewahrung Ihre Complianceanforderungen nicht erfüllt, können Sie die PITR-Aufbewahrungsdauer ändern. Weitere Informationen finden Sie unter Ändern des PITR-Aufbewahrungszeitraums von Sicherungen.

Hinweis

Der Artikel Ändern automatisierten Sicherungseinstellungen enthält eine ausführliche Vorgehensweise zum Löschen personenbezogener Daten vom Gerät oder aus dem Dienst, die Sie bei Ihren Pflichten gemäß der DSGVO unterstützen kann. Allgemeine Informationen zur DSGVO finden Sie im Abschnitt zur DSGVO im Microsoft Trust Center und im Abschnitt zur DSGVO im Service Trust Portal.

Verwenden von Azure Policy zum Erzwingen der Redundanz für Sicherungsspeicher

Wenn Sie Datenresidenzanforderungen haben, laut denen Sie Ihre Daten alle in einer einzigen Azure-Region speichern müssen, sollten Sie zonenredundante oder lokal redundante Sicherungen für Ihre SQL-Datenbank mithilfe von Azure Policy durchsetzen.

Azure Policy ist ein Dienst, mit dem Sie Richtlinien zum Anwenden von Regeln auf Azure-Ressourcen erstellen, zuweisen und verwalten können. Azure Policy hilft Ihnen, die Konformität dieser Ressourcen mit Ihren Unternehmensstandards und den Vereinbarungen zum Servicelevel sicherzustellen. Weitere Informationen finden Sie in der Übersicht über Azure Policy.

Integrierte Richtlinien für die Redundanz des Sicherungsspeichers

Zum Durchsetzen von Datenresidenzanforderungen auf Organisationsebene können Sie einer Subscription Richtlinien zuweisen, indem Sie das Azure-Portal oder Azure PowerShell verwenden.

Wenn Sie z. B. die Richtlinie „Azure SQL-Datenbank sollte die Verwendung von GRS-Backups vermeiden“ aktivieren, können Datenbanken nicht mit dem Standardspeicher als global redundanten Speicher erstellt werden. Außerdem würden Benutzer*innen mit der Fehlermeldung „Konfigurieren des Sicherungsspeicherkontotyps für ‚Standard_RAGRS‘ beim Erstellen oder Aktualisieren der Datenbank fehlgeschlagen“ an der Verwendung von GRS gehindert.

Eine vollständige Liste der integrierten Richtliniendefinitionen für SQL-Datenbank finden Sie unter Richtlinienreferenz.

Wichtig

Azure-Richtlinien werden nicht durchgesetzt, wenn Datenbanken über T-SQL erstellt werden. Wenn Sie Datenresidenz für das Erstellen einer Datenbank mit T-SQL angeben möchten, verwenden Sie „LOCAL“ oder „ZONE“ als Eingabe für den BACKUP_STORAGE_REDUNDANCY-Parameter der CREATE DATABASE-Anweisung.

Zugehöriger Inhalt

• Informationen zu anderen Geschäftskontinuitätslösungen von SQL-Datenbank finden Sie unter Übersicht über Geschäftskontinuität.
• Informationen zum Ändern der Sicherungseinstellungen finden Sie unter Einstellungen ändern.
• Informationen zum Wiederherstellen einer Sicherung finden Sie unter Wiederherstellen mithilfe von Sicherungen oder Wiederherstellen einer Datenbank zu einem bestimmten Zeitpunkt mithilfe von PowerShell.
• Informationen zum Konfigurieren, Verwalten und Wiederherstellen aus der Langzeitaufbewahrung automatisierter Sicherungen in Azure Blob Storage finden Sie unter Verwalten der Langzeitaufbewahrung von Sicherungen.
• Informationen zu Azure SQL Managed Instance finden Sie unter Automatisierte Sicherungen für SQL Managed Instance.