Automatisierte Sicherungen – Azure SQL-Datenbank und Azure SQL Managed Instance

GILT FÜR: Azure SQL-Datenbank Azure SQL Managed Instance

Hinweis

Dieser Artikel 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.

Was ist eine Datenbanksicherung?

Datenbanksicherungen sind ein wesentlicher Bestandteil jeder Strategie für Geschäftskontinuität und Notfallwiederherstellung, da Ihre Daten vor Beschädigungen und Löschungen geschützt werden. 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 Ihre Sicherungen über einen längeren Zeitraum verfügbar sind (bis zu 10 Jahre), können Sie sowohl für Singletons als auch für Pooldatenbanken die Langzeitaufbewahrung konfigurieren.

Sicherungshäufigkeit

Sowohl SQL-Datenbank als auch SQL Managed Instance nutzen SQL Server-Technologie, um wöchentlich vollständige Sicherungen, alle 12–24 Stunden differenzielle Sicherungen und alle 5 bis 10 Minuten Transaktionsprotokollsicherungen zu erstellen. Die 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.

Redundanz für Sicherungsspeicher

Standardmäßig speichern SQL-Datenbank und SQL Managed Instance Daten in georedundanten Speicherblobs, die in einem Regionspaar repliziert werden. Georedundanz dient zum Schutz vor Ausfällen, die sich auf den Sicherungsspeicher in der primären Region auswirken, und ermöglicht es Ihnen, Ihren Server bei einem Notfall in einer anderen Region wiederherzustellen.

Die Option zum Konfigurieren der Redundanz für Sicherungsspeicher bietet Flexibilität bei der Auswahl zwischen lokal redundanten, zonenredundanten oder georedundanten Speicherblobs. Damit Ihre Daten in der Region bleiben, in der auch Ihre verwaltete Instanz oder SQL-Datenbank bereitgestellt wurde, können Sie den Standardwert für Redundanz (georedundanter Sicherungsspeicher) ändern und entweder lokal redundante oder zonenredundante Speicherblobs für Sicherungen konfigurieren. Mechanismen der Speicherredundanz speichern mehrere Kopien Ihrer Daten, damit sie vor geplanten und ungeplanten Ereignissen geschützt sind – von vorübergehend auftretenden Hardwarefehlern über Netzwerk- oder Stromausfälle bis hin zu schweren Naturkatastrophen. Die konfigurierte Redundanz für Sicherungsspeicher wird sowohl auf die Einstellungen für kurzfristige Sicherungsaufbewahrung angewendet, die für die Zeitpunktwiederherstellung (Point In Time Restore, PITR) verwendet werden, als auch auf die Langzeitaufbewahrung von Sicherungen (Long-Term Retention, LTR), die für langfristige Sicherungen verwendet wird.

Die Sicherungsspeicherredundanz für eine SQL-Datenbank-Instanz kann entweder beim Erstellen der Datenbank konfiguriert oder für vorhandene Datenbanken aktualisiert werden. Die an einer vorhandenen Datenbank vorgenommenen Änderungen gelten jedoch nur für zukünftige Sicherungen. Nachdem die Redundanz für Sicherungsspeicher einer vorhandenen Datenbank aktualisiert wurde, kann es bis zu 48 Stunden dauern, bis die Änderungen angewendet werden. Die Geowiederherstellung wird deaktiviert, sobald die Datenbank so aktualisiert wurde, dass lokaler oder zonenredundanter Speicher verwendet wird.

Wichtig

Eine Sicherungsspeicherredundanz für Hyperscale und SQL Managed Instance kann nur während der Datenbankerstellung festgelegt werden. Diese Einstellung kann nach der Bereitstellung der Ressource nicht mehr geändert werden. Der Datenbankkopiervorgang kann verwendet werden, um die Einstellungen der Sicherungsspeicherredundanz für eine vorhandene Hyperscale-Datenbank zu aktualisieren.

Wichtig

Zonenredundanter Speicher steht zurzeit nur in bestimmten Regionen zur Verfügung.

Hinweis

Die konfigurierbare Sicherungsspeicherredundanz für Azure SQL-Datenbank ist zurzeit in allen Azure-Regionen als Public Preview und nur in der Region „Asien, Südosten“ allgemein verfügbar.

Sicherungsverwendung

Sie können diese Sicherungen für Folgendes verwenden:

  • Zeitpunktwiederherstellung einer vorhandenen Datenbank - Stellen Sie für eine vorhandene Datenbank den Stand zu einem vergangenen Zeitpunkt wieder her, der innerhalb des Aufbewahrungszeitraums liegt. Verwenden Sie dafür das Azure-Portal, Azure PowerShell, die Azure-Befehlszeilenschnittstelle (Azure CLI) oder die REST-API. Bei SQL-Datenbank erstellt dieser Vorgang eine neue Datenbank auf demselben Server wie die ursprüngliche Datenbank, verwendet aber einen anderen Namen, um ein Überschreiben der ursprünglichen Datenbank zu vermeiden. Nach Abschluss der Wiederherstellung können Sie die ursprüngliche Datenbank löschen. Alternativ dazu können Sie die ursprüngliche Datenbank umbenennen und dann die wiederhergestellte Datenbank auf den ursprünglichen Datenbanknamen umbenennen. In ähnlicher Weise erstellt dieser Vorgang bei SQL Managed Instance eine Kopie der Datenbank in derselben oder einer anderen verwalteten Instanz in demselben Abonnement und derselben Region.
  • Zeitpunktwiederherstellung einer gelöschten Datenbank - Stellen Sie bei einer gelöschten Datenbank den Stand zum Zeitpunkt des Löschvorgangs wieder her oder zu einem beliebigen anderen Zeitpunkt innerhalb des Aufbewahrungszeitraums. Die gelöschte Datenbank kann nur auf demselben Server oder in derselben verwalteten Instanz wiederhergestellt werden, auf dem bzw. in der die ursprüngliche Datenbank erstellt wurde. Beim Löschen einer Datenbank nimmt der Dienst zuvor eine abschließende Transaktionsprotokollsicherung vor, um Datenverluste zu vermeiden.
  • Geowiederherstellung - Stellen Sie eine Datenbank in einer anderen geografischen Region wieder her. Die Geowiederherstellung ermöglicht die Wiederherstellung nach dem Ausfall einer geografischen Region, 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 oder in einer verwalteten Instanz in einer beliebigen Azure-Region erstellt.

    Wichtig

    Geowiederherstellung ist nur für SQL-Datenbanken oder verwaltete Instanzen verfügbar, die mit einem georedundanten Sicherungsspeicher konfiguriert wurden.

  • Wiederherstellen aus Langzeitaufbewahrung - Führen Sie die Wiederherstellung einer Datenbank aus einer bestimmten langfristigen Sicherung eines Singletons oder einer Pooldatenbank durch, wenn die Datenbank mit einer Richtlinie zur Langzeitaufbewahrung (Long-Term Retention, LTR) konfiguriert wurde. Mit LTR können Sie eine alte Version der Datenbank wiederherstellen, indem Sie das Azure-Portal oder Azure PowerShell verwenden, um eine Konformitätsanforderung zu erfüllen oder eine alte Version der Anwendung auszuführen. Weitere Informationen finden Sie unter Langfristige Aufbewahrung.

Hinweis

In Azure Storage bezieht sich der Begriff Replikation auf das Kopieren von Blobs von einem Speicherort an einen anderen. In SQL bezieht sich Datenbankreplikation auf verschiedene Technologien, über die mehrere sekundäre Datenbanken mit einer primären Datenbank synchron bleiben.

Wiederherstellungsfunktionen und Features von Azure SQL-Datenbank und Azure SQL Managed Instance

In dieser Tabelle werden die Funktionen und Features der Point-in-Time-Wiederherstellung, der Geowiederherstellungund der Langzeitaufbewahrung von Sicherungen zusammengefasst.

Sicherungseigenschaften Point-in-Time-Wiederherstellung Geowiederherstellung Wiederherstellung langfristiger Sicherungen
Typen der SQL-Sicherung Vollständige, differenzielle und Transaktionsprotokollsicherungen Replizierte Kopien von PITR-Sicherungen Nur die vollständigen Sicherungen
Wiederherstellungspunktziel (Recovery Point Objective, RPO) 5 bis 10 Minuten, basierend auf der Computegröße und dem Umfang der Datenbankaktivität Bis zu 1 Stunde, basierend auf der Georeplikation* Eine Woche (oder Benutzerrichtlinie)
Recovery Time Objective (RTO) Die Wiederherstellung dauert in der Regel mehr als 12 Stunden, kann aber je nach Größe und Aktivität mehr in Zeit in Anspruch nehmen. Siehe Wiederherstellung. Die Wiederherstellung dauert in der Regel mehr als 12 Stunden, kann aber je nach Größe und Aktivität mehr in Zeit in Anspruch nehmen. Siehe Wiederherstellung. Die Wiederherstellung dauert in der Regel mehr als 12 Stunden, kann aber je nach Größe und Aktivität mehr in Zeit in Anspruch nehmen. Siehe Wiederherstellung.
Vermerkdauer Standardmäßig 7 Tage, bis zu 35 Tage Standardmäßig aktiviert, identisch mit der Quelle** Standardmäßig nicht aktiviert, Aufbewahrungsdauer bis zu 10 Jahre
Azure Storage Standardmäßig zonenredundant. Zonen- oder lokal redundanter Speicher kann optional konfiguriert werden. Verfügbar, wenn die PITR-Sicherungsspeicherredundanz auf „Georedundant“ festgelegt ist. Nicht verfügbar, wenn es sich beim PITR-Sicherungsspeicher um zonen- oder lokal redundanten Speicher handelt. Standardmäßig zonenredundant. Zonen- oder lokal redundanter Speicher kann konfiguriert werden.
Verwendung zum Erstellen einer neuen Datenbank in derselben Region Unterstützt Unterstützt Unterstützt
Verwendung zum Erstellen einer neuen Datenbank in einer anderen Region Nicht unterstützt In allen Azure-Regionen unterstützt In allen Azure-Regionen unterstützt
Verwendung zum Erstellen einer neuen Datenbank in einem anderen Abonnement Nicht unterstützt Nicht unterstützt*** Nicht unterstützt***
Wiederherstellung über das Azure-Portal Ja Ja Ja
Wiederherstellung über PowerShell Ja Ja Ja
Wiederherstellung ü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, Autofailover-Gruppen.

** Alle PITR-Sicherungen werden standardmäßig in georedundanten Speicher gespeichert. Daher ist die Geowiederherstellung standardmäßig aktiviert.

*** Die Problemumgehung besteht in der Wiederherstellung auf einem neuen Server und dem Verschieben von Ressourcen, um den Server in ein anderes Abonnement zu verschieben.

Wiederherstellen einer Datenbank aus einer Sicherung

Informationen zum Durchführen einer Wiederherstellung finden Sie unter Wiederherstellen einer Azure SQL-Datenbank mit automatisierten Datenbanksicherungen. Sie können Sicherungs- und Wiederherstellungsvorgänge für Konfigurationen anhand der folgenden Beispiele ausprobieren:

Vorgang Azure-Portal Azure PowerShell
Ändern der Sicherungsaufbewahrung 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
Wiederherstellen einer Datenbank bis zu einem Zeitpunkt 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
Wiederherstellen einer Datenbank aus Azure Blob Storage SQL-Datenbank – nicht verfügbar
SQL Managed Instance – nicht verfügbar
SQL-Datenbank – nicht verfügbar
SQL Managed Instance

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. Der genaue Zeitpunkt für alle Datenbanksicherungen wird vom SQL-Datenbank- oder SQL Managed Instance-Dienst festgelegt, da dort die gesamte Systemworkload verwaltet wird. 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 Point-in-Time-Wiederherstellung ab dem Zeitpunkt der Erstellung der ersten Transaktionsprotokollsicherung verfügbar, die auf die anfängliche vollständige Sicherung folgt.

Sicherungsspeicherverbrauch

Mit der Sicherungs- und Wiederherstellungstechnologie von SQL Server setzt das Wiederherstellen einer Datenbank zu einem bestimmten Zeitpunkt eine ununterbrochene Sicherungskette voraus, die aus einer vollständigen Sicherung, optional einer differenziellen Sicherung und einer oder mehreren Transaktionsprotokollsicherungen besteht. Der Sicherungszeitplan für SQL-Datenbank und SQL Managed Instance umfasst jede Woche eine vollständige Sicherung. Um die Point-in-Time-Wiederherstellung (PITR) innerhalb der gesamten Beibehaltungsdauer bereitzustellen, muss das System daher zusätzlich vollständige, differenzielle und Transaktionsprotokollsicherungen für bis zu eine Woche über die konfigurierte Beibehaltungsdauer hinaus speichern.

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

Hinweis

Zur Bereitstellung der Point-in-Time-Wiederherstellung werden zusätzliche Sicherungen bis zu einer Woche über die konfigurierte Beibehaltungsdauer hinaus gespeichert. Der Sicherungsspeicher wird für alle Sicherungen mit derselben Gebühr abgerechnet.

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 Sicherungen komprimiert, um die Auslastung des Sicherungsspeichers und die Kosten zu verringern. Das durchschnittliche Komprimierungsverhältnis für Sicherungen ist das Drei- bis Vierfache, dies kann jedoch je nach Art der Daten und der Verwendung der Datenkomprimierung in der Datenbank erheblich niedriger oder höher ausfallen.

SQL-Datenbank und SQL Managed Instance berechnen den gesamten genutzten Sicherungsspeicher als kumulativen Wert. Jede Stunde wird dieser Wert an die Azure-Abrechnungspipeline gemeldet, die für die Aggregierung dieser stündlichen Nutzung verantwortlich ist, um die Nutzung am Ende jedes Monats zu berechnen. 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 Point-in-Time-Wiederherstellung 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. Das Löschen und erneute Erstellen einer Datenbank kann möglicherweise Speicher- und Computekosten einsparen. Die Kosten für den Sicherungsspeicher können dadurch jedoch erhöht werden, da der Dienst Sicherungen für jede gelöschte Datenbank bei jedem Löschvorgang beibehält.

Überwachen des Verbrauchs

Für Datenbanken auf virtuellen Kernen wird der verbrauchte Speicher für jeden Sicherungstyp (vollständig, differenziell und Protokoll) im Bereich der Datenbanküberwachung als separate Metrik ausgewiesen. Im folgenden Diagramm wird gezeigt, wie Sie den Sicherungsspeicherverbrauch für eine Einzeldatenbank überwachen. Dieses Feature ist derzeit für verwaltete Instanzen nicht verfügbar.

Überwachen des Sicherungsspeicherverbrauchs von Datenbanken im Azure-Portal

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 es, große Schreibvorgänge, wie z.B. die Neuerstellung von Indizes, öfter als nötig durchzuführen.
  • Bei umfangreichen Datenladevorgängen sollten Sie gruppierte Columnstore-Indizes verwenden und die entsprechenden Best Practices befolgen oder die Anzahl der nicht gruppierten Indizes reduzieren.
  • 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 (z. B. dev/Testumgebungen).

Sicherungsaufbewahrung

Für alle neuen, wiederhergestellten und kopierten Datenbanken behalten Azure SQL-Datenbank und Azure SQL Managed Instance standardmäßig ausreichende Sicherungen für die Point-in-Time-Wiederherstellung in den letzten sieben Tagen bei. Mit Ausnahme von Datenbanken in den Tarifen „Hyperscale“ und „Basic“ können Sie den Aufbewahrungszeitraum von Sicherungen pro aktiver Datenbank im Bereich von 1 bis 35 Tagen ändern. Wie unter Sicherungsspeicherverbrauch beschrieben, liegen Sicherungen, die zum Ermöglichen der Point-in-Time-Wiederherstellung gespeichert wurden, möglicherweise zeitlich vor der Beibehaltungsdauer. Nur für Azure SQL Managed Instance ist es möglich, die PITR-Sicherungsaufbewahrungsrate festzulegen, nachdem eine Datenbank innerhalb des Zeitraums von 0 bis 35 Tagen gelöscht wurde.

Wenn Sie eine Datenbank löschen, behält das System Sicherungen genauso bei, wie dies für eine Onlinedatenbank mit der jeweiligen Beibehaltungsdauer gelten würde. Die Beibehaltungsdauer für eine gelöschte Datenbank kann nicht geändert werden.

Wichtig

Wenn Sie den Server oder die verwaltete Instanz löschen, werden auch alle Datenbanken auf diesem Server oder in dieser verwalteten Instanz gelöscht und können nicht mehr wiederhergestellt werden. Ein gelöschter Server oder eine gelöschte verwaltete Instanz kann nicht wiederhergestellt werden. Wenn Sie jedoch die Langzeitaufbewahrung (Long-Term Retention, LTR) für eine Datenbank oder eine verwaltete Instanz konfiguriert haben, werden Sicherungen für die Langzeitaufbewahrung nicht gelöscht und können zum Wiederherstellen von Datenbanken auf einem anderen Server bzw. einer anderen verwalteten Instanz im selben Abonnement verwendet werden. Dabei wird der Zeitpunkt wiederhergestellt, an dem die Sicherung die Langzeitaufbewahrung durchgeführt wurde.

Die Beibehaltungsdauer der Sicherung für Point-in-Time-Wiederherstellungen innerhalb der letzten 1–35 Tage wird auch als kurzfristige Beibehaltung der Sicherung bezeichnet. Wenn Sie Sicherungen länger als für die maximale kurzfristige Beibehaltungsdauer von 35 Tagen aufbewahren müssen, können Sie die Langzeitaufbewahrung aktivieren.

Langfristige Aufbewahrung

Sowohl für SQL-Datenbank als auch für SQL Managed Instance können Sie eine langfristige Aufbewahrung (Langzeitaufbewahrung, Long-Term Retention, LTR) der vollständigen Sicherung für bis zu 10 Jahre 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. 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.

Wichtig

Wenn die Sicherungsspeicherredundanz für eine vorhandene Azure SQL-Datenbank-Instanz aktualisiert wird, gilt dies nur für zukünftige Sicherungen, die für die Datenbank erstellt werden. Alle vorhandenen LTR-Sicherungen für die Datenbank sind weiterhin im vorhandenen Speicherblob zu finden, und neue Sicherungen werden mit dem angeforderten Speicherblobtyp gespeichert.

Weitere Informationen zu LTR finden Sie unter Langfristiges Aufbewahren von Sicherungen.

Kosten von Sicherungsspeicher

Der Preis für Sicherungsspeicher variiert und ist abhängig von Ihrem Kaufmodell (DTU oder vCore), der ausgewählten Option zur Redundanz für Sicherungsspeicher und auch Ihrer Region. Der Sicherungsspeicher wird pro GB/Verbrauchsmonat in Rechnung gestellt. Die Preise finden Sie auf der Seite Preise für Azure SQL-Datenbank und der Seite Preise für Azure SQL Managed Instance.

Weitere Informationen zu den Kaufmodellen finden Sie unter Auswählen zwischen dem vCore-basierten und dem DTU-basierten Kaufmodell.

Hinweis

In der Azure-Rechnung wird nur der zusätzlich verbrauchte, nicht der insgesamt verbrauchte Sicherungsspeicher aufgeführt. Angenommen, Sie haben beispielsweise einen Datenspeicher mit einer Größe 4 TB bereitgestellt. In diesem Fall sind die 4 TB Sicherungsspeicher für Sie kostenlos. Wenn Sie in diesem Beispielszenario eine Gesamtspeichermenge von 5,8 TB verbrauchen, werden in der Azure-Rechnung nur 1,8 TB berechnet, da nur der zusätzliche Sicherungsspeicher in Rechnung gestellt wird.

DTU-Modell

Im DTU-Modell fallen keine zusätzlichen Kosten für den Sicherungsspeicher für Datenbanken und Pools für elastische Datenbanken an. Der Preis für den Sicherungsspeicher ist im Preis für die Datenbank oder den Pool inbegriffen.

V-Kern-Modell

Bei Singletons in SQL-Datenbank wird eine Sicherungsspeichermenge, die der maximalen Datenspeichergröße für die Datenbank entspricht, ohne zusätzliche Kosten zur Verfügung gestellt. Bei Pools für elastische Datenbanken und verwalteten Instanzen wird eine Sicherungsspeichermenge, die der Gesamtgröße des maximalen Datenspeichers für den Pool bzw. der maximalen Instanzgröße entspricht, ohne zusätzliche Kosten bereitgestellt.

Bei Singletons wird der gesamte in Rechnung gestellte Sicherungsspeicherbedarf wie folgt berechnet:

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

Bei Pooldatenbanken wird die Gesamtgröße des in Rechnung gestellten 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

Bei verwalteten Instanzen wird die Gesamtgröße des in Rechnung gestellten Sicherungsspeichers auf Instanzebene aggregiert und wie folgt berechnet:

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

Sofern Sicherungsspeicher vorhanden ist, für den Kosten anfallen, wird insgesamt in GB/Monat mit der für die Sicherungsspeicherredundanz verwendeten Rate abgerechnet. Der Sicherungsspeicherverbrauch ist von der Workload und der Größe der einzelnen Datenbanken, 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 diese Datenbanken höhere Sicherungsgebühren an.

SQL-Datenbank und SQL Managed Instance berechnen den gesamten in Rechnung gestellten Sicherungsspeicher als kumulativen Wert aller Sicherungsdateien. Dieser Wert wird jede Stunde der Azure-Abrechnungspipeline gemeldet, die diese stündliche Nutzung aggregiert, um den Verbrauch an Sicherungsspeicher am Ende jedes Monats zu berechnen. 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.

Als vereinfachtes Beispiel sei angenommen, eine Datenbank hat 744 GB Sicherungsspeicher angesammelt, und diese Menge bleibt während eines ganzen Monats konstant, da die Datenbank vollkommen inaktiv ist. Um diesen kumulativen Speicherverbrauch in eine stündliche Nutzung umzurechnen, dividieren wir ihn durch 744,0 (31 Tage pro Monat x 24 Stunden pro Tag). SQL-Datenbank meldet an die Azure-Abrechnungspipeline, dass die Datenbank mit konstanter Rate pro Stunde 1 GB an PITR-Sicherungen verbraucht hat. 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 basierend auf den Kosten für die Menge in GB pro Monat in Ihrer Region.

Jetzt folgt ein komplexeres Beispiel. Angenommen, für dieselbe inaktive Datenbank wird der Aufbewahrungszeitraum in der Mitte des Monats von sieben 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.

Die tatsächlichen Abrechnungsszenarien für Sicherungen sind komplexer. Da die Rate von Änderung in der Datenbank von der Workload abhängig und zeitlich variabel ist, variiert auch die Größe der einzelnen differenziellen und Protokollsicherungen, sodass der Speicherverbrauch für stündliche Sicherungen entsprechend schwankt. Darüber hinaus enthält jede differenzielle Sicherung alle Änderungen, die seit der letzten vollständigen Sicherung an der Datenbank vorgenommen wurden. Daher nimmt die Gesamtgröße aller differenziellen Sicherungen im Verlauf einer Woche allmählich zu und fällt dann deutlich ab, wenn ein älterer Satz vollständiger, differenzieller und Protokollsicherungen das Alter zum Löschen erreicht. Wenn beispielsweise eine intensive Schreibaktivität wie etwa eine Indexneuerstellung unmittelbar nach Abschluss einer vollständigen Sicherung ausgeführt wurde, werden die durch die Indexneuerstellung vorgenommenen Änderungen in die Transaktionsprotokollsicherungen während der Neuerstellung, in die nächsten differenziellen Sicherung und in jede differenzielle Sicherung bis zur nächsten vollständigen Sicherung eingeschlossen. Beim letztgenannten Szenario erstellt eine Optimierung am Dienst für größere Datenbanken eine vollständige Sicherung anstelle einer differenziellen Sicherung, wenn eine differenzielle Sicherung andernfalls ü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.

Redundanz für Sicherungsspeicher

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

  • Preis für lokale Redundanz: x
  • Preis für Zonenredundanz: 1,25x
  • Preis für Georedundanz: 2x

Weitere Informationen zu den Preisen für Sicherungsspeicher finden Sie auf der Seite mit der Preisübersicht für Azure SQL-Datenbank und der Seite mit der Preisübersicht für Azure SQL Managed Instance.

Wichtig

Die Sicherungsspeicherredundanz kann für SQL Managed Instance-Instanzen in allen Azure-Regionen konfiguriert werden. Nur die Verfügbarkeit für SQL-Datenbank ist aktuell auf die Azure-Region „Asien, Südosten“ beschränkt. Bei SQL Managed Instance-Instanzen kann die Redundanz nur während des Erstellprozesses der verwalteten Instanz angegeben werden. Nachdem die Ressource bereitgestellt wurde, können Sie die Option für die Redundanz für Sicherungsspeicher nicht mehr ändern.

Ü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 das gewünschte Abonnement als Bereich aus, und filtern Sie dann nach dem gewünschten Zeitraum und Dienst.

Fügen Sie einen Filter für Dienstname hinzu, und wählen Sie dann in der Dropdownliste SQL-Datenbank aus. Verwenden Sie den Filter Unterkategorie der Verbrauchseinheit, um den Abrechnungszähler für Ihren Dienst auszuwählen. Wählen Sie für eine einzelne Datenbank oder einen Pool für elastische Datenbanken den PITR-Sicherungsspeicher für eine einzelne Datenbank/einen Pool für elastische Datenbanken aus. Wählen Sie für eine verwaltete Instanz MI-PITR-Sicherungsspeicher aus. Die Unterkategorien Speicher und Compute können für Sie auch von Interesse sein, obwohl sie nicht im Zusammenhang mit den Sicherungsspeicherkosten stehen.

Analyse der Kosten für Sicherungsspeicher

Hinweis

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 werden für Kunden, die keine verwaltete Instanz bereitgestellt haben, Zähler für verwaltete Instanzen nicht angezeigt. Ebenso sind Speicherzähler für Ressourcen, die keinen Speicher belegen, nicht sichtbar.

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 finden Sie unter Transparent Data Encryption für SQL-Datenbank, SQL Managed Instance und Azure Synapse Analytics.

Sicherungsintegrität

Das Azure SQL-Entwicklungsteam testet fortlaufend automatisch die Wiederherstellung von automatischen Datenbanksicherungen. (Für SQL Managed Instance sind diese Tests derzeit nicht verfügbar. Führen Sie DBCC CHECKDB für Ihre Datenbanken in SQL Managed Instance abhängig von Ihrer Workload durch.)

Bei der Point-in-Time-Wiederherstellung werden die Datenbanken außerdem mithilfe von DBCC CHECKDB Integritätsprüfungen unterzogen.

Mögliche Probleme, die bei der 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

Dieser Artikel 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.

Ändern des PITR-Aufbewahrungszeitraums von Sicherungen

Sie können den Standardzeitraum für die Aufbewahrung von PITR-Sicherungen im Azure-Portal, mit PowerShell oder der REST-API ändern. In den folgenden Beispielen wird veranschaulicht, wie Sie die PITR-Aufbewahrungsdauer in 28 Tage ändern.

Warnung

Wenn Sie die aktuelle Beibehaltungsdauer verringern, verlieren Sie die Möglichkeit, Zeitpunkte wiederherzustellen, die älter als die neue Beibehaltungsdauer sind. Sicherungen, die für die Bereitstellung von Point-in-Time-Wiederherstellungen innerhalb der neuen Beibehaltungsdauer nicht mehr benötigt werden, werden gelöscht. Wenn Sie die aktuelle Beibehaltungsdauer verringern, wird die Möglichkeit, Zeitpunkte innerhalb der neuen Beibehaltungsdauer wiederherzustellen, nicht sofort hergestellt. Sie erhalten diese Möglichkeit im Lauf der Zeit, während das System beginnt, Sicherungen länger aufzubewahren.

Hinweis

Diese APIs wirken sich nur auf die PITR-Aufbewahrungsdauer aus. Falls Sie für Ihre Datenbank LTR konfiguriert haben, ist sie nicht betroffen. Informationen zum Ändern von LTR-Aufbewahrungsdauern finden Sie unter Langfristige Aufbewahrung.

Ändern der PITR-Aufbewahrungsdauer im Azure-Portal

Um die PITR-Aufbewahrungsdauer von Sicherungen für aktive Datenbanken im Azure-Portal zu ändern, navigieren Sie im Portal zum Server oder zur verwalteten Instanz mit den Datenbanken, deren Aufbewahrungsdauer geändert werden soll. Wählen Sie im linken Bereich Sicherungen und dann die Registerkarte Aufbewahrungsrichtlinien aus. Wählen Sie die Datenbank(en) aus, für die Sie die PITR-Sicherungsaufbewahrung ändern möchten. Wählen Sie dann in der Aktionsleiste die Option Aufbewahrung konfigurieren aus.

Ändern der PITR-Aufbewahrungsdauer mit PowerShell

Hinweis

Dieser Artikel wurde mit der Verwendung des Azure Az PowerShell-Moduls aktualisiert. Das Azure Az PowerShell-Modul wird für die Interaktion mit Azure empfohlen. Informationen zu den ersten Schritten mit dem Az PowerShell-Modul finden Sie unter Installieren von Azure PowerShell. Informationen zum Migrieren zum Az PowerShell-Modul finden Sie unter Migrieren von Azure PowerShell von AzureRM zum Az-Modul.

Wichtig

Das PowerShell-Modul AzureRM wird weiterhin von SQL-Datenbank und SQL Managed Instance unterstützt, in Zukunft wird jedoch nur das Modul Az.Sql weiterentwickelt. Weitere Informationen finden Sie unter AzureRM.Sql. Die Argumente für die Befehle im Az-Modul und den AzureRm-Modulen sind im Wesentlichen identisch.

Verwenden Sie das folgende PowerShell-Beispiel, um die PITR-Aufbewahrungsdauer von Sicherungen für aktive Azure SQL-Datenbanken zu ändern.

# SET new PITR backup retention period on an active individual database
# Valid backup retention must be between 1 and 35 days
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28

Ändern der PITR-Aufbewahrungsdauer über die REST-API

Beispiel für eine Anforderung

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

Anforderungstext

{
  "properties":{
    "retentionDays":28
  }
}

Beispiel für eine Antwort

Statuscode: 200

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

Weitere Informationen finden Sie unter REST-API für die Aufbewahrung von Sicherungen.

Beispiel für eine Anforderung

PUT https://management.azure.com/subscriptions/00000000-1111-2222-3333-444444444444/resourceGroups/resourceGroup/providers/Microsoft.Sql/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default?api-version=2017-10-01-preview

Anforderungstext

{
  "properties":{
    "retentionDays":28
  }
}

Beispiel für eine Antwort

Statuscode: 200

{
  "id": "/subscriptions/00000000-1111-2222-3333-444444444444/providers/Microsoft.Sql/resourceGroups/resourceGroup/servers/testserver/databases/testDatabase/backupShortTermRetentionPolicies/default",
  "name": "default",
  "type": "Microsoft.Sql/resourceGroups/servers/databases/backupShortTermRetentionPolicies",
  "properties": {
    "retentionDays": 28
  }
}

Weitere Informationen finden Sie unter REST-API für die Aufbewahrung von Sicherungen.

Konfigurieren der Redundanz für Sicherungsspeicher

Hinweis

Konfigurierbare Speicherredundanz für Sicherungen steht nur für SQL Managed Instance zur Verfügung und kann nur während des Prozesses zum Erstellen einer verwalteten Instanz angegeben werden. Nachdem die Ressource bereitgestellt wurde, können Sie die Option für die Redundanz für Sicherungsspeicher nicht mehr ändern. Für SQL-Datenbank ist die Public Preview dieses Features aktuell in allen Azure-Regionen und die allgemein verfügbare Version in der Azure-Region „Asien, Südosten“ verfügbar.

Eine Redundanz für Sicherungsspeicher für eine verwaltete Instanz kann nur während der Instanzerstellung festgelegt werden. Für eine SQL-Datenbank-Instanz kann sie beim Erstellen der Datenbank festgelegt oder für eine vorhandene Datenbank aktualisiert werden. Standardmäßig wird georedundanter Speicher verwendet. Informationen zu den Preisunterschieden zwischen lokal redundantem, zonenredundantem und georedundantem Sicherungsspeicher finden Sie auf der Seite mit der Preisübersicht für verwaltete Instanzen.

Konfigurieren der Redundanz für Sicherungsspeicher über das Azure-Portal

Im Azure-Portal können Sie die Sicherungsspeicherredundanz im Bereich SQL-Datenbank erstellen konfigurieren. Die Option steht im Abschnitt „Redundanz für Sicherungsspeicher“ zur Verfügung. Öffnen des Bereichs „SQL-Datenbank erstellen“

Konfigurieren der Redundanz für Sicherungsspeicher mithilfe von PowerShell

Zum Konfigurieren der Redundanz für Sicherungsspeicher beim Erstellen einer neuen Datenbank können Sie den Parameter „--BackupStorageRedundancy“ angeben. Mögliche Werte sind Geo, Zone und Local. Standardmäßig verwenden alle SQL-Datenbank-Instanzen georedundanten Speicher für Sicherungen. Die Geowiederherstellung ist deaktiviert, wenn eine Datenbank mit lokalem oder zonenredundanten Sicherungsspeicher erstellt wird.

# Create a new database with geo-redundant backup storage.  
New-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database03" -Edition "GeneralPurpose" -Vcore 2 -ComputeGeneration "Gen5" -BackupStorageRedundancy Geo

Details hierzu finden Sie unter New-AzSqlDatabase.

Zum Aktualisieren der Redundanz für Datenspeicher einer vorhandenen Datenbank können Sie den Parameter „-BackupStorageRedundancy“ verwenden. Mögliche Werte sind Geo, Zone und Local. Es kann bis zu 48 Stunden dauern, bis die Änderungen auf die Datenbank angewendet werden. Durch den Wechsel von georedundantem Sicherungsspeicher zu lokalem oder zonenredundantem Sicherungsspeicher wird die Geowiederherstellung deaktiviert.

# Change the backup storage redundancy for Database01 to zone-redundant. 
Set-AzSqlDatabase -ResourceGroupName "ResourceGroup01" -DatabaseName "Database01" -ServerName "Server01" -BackupStorageRedundancy Zone

Details hierzu finden Sie unter Set-AzSqlDatabase.

Hinweis

Zur Verwendung des -BackupStorageRedundancy-Parameters mit Datenwiederherstellung, Datenbankkopien oder Vorgängen zur Erstellung sekundärer Replikate verwenden Sie die Azure PowerShell-Version Az.Sql 2.11.0.

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

Wenn Sie Data-Residency-Anforderungen haben, laut denen Sie Ihre Daten alle in einer einzelnen Azure-Region speichern müssen, sollten Sie zonenredundante oder lokal redundante Sicherungen für Ihre SQL-Datenbank-Instanz oder SQL Managed Instance-Instanz mithilfe von Azure Policy erzwingen. 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 Vereinbarungen zum Servicelevel sicherzustellen. Weitere Informationen finden Sie in der Übersicht über Azure Policy.

Integrierte Richtlinien für die Redundanz des Sicherungsspeichers

Im Folgenden werden neue integrierte Richtlinien hinzugefügt, die auf Ebene des Abonnements oder der Ressourcengruppe zugewiesen werden können, um das Erstellen neuer Datenbanken oder Instanzen mit georedundantem Sicherungsspeicher zu verhindern.

Verwendung von GRS-Sicherungsredundanz für SQL-Datenbank vermeiden

Verwendung von GRS-Sicherungsredundanz für SQL Managed Instance-Instanzen vermeiden

Eine vollständige Liste integrierter Richtliniendefinitionen für SQL-Datenbank und SQL Managed Instance finden Sie hier.

Wenn Sie Data-Residency-Anforderungen auf Organisationsebene erzwingen möchten, können diese Richtlinien einem Abonnement zugewiesen werden. Nachdem die Richtlinien einer Abonnementebene zugewiesen wurden, können Benutzer im jeweiligem Abonnement keine Datenbank oder verwaltete Instanz mit georedundantem Sicherungsspeicher mehr über das Azure-Portal oder Azure PowerShell erstellen.

Wichtig

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

Unter Schnellstart: Erstellen einer Richtlinienzuweisung zum Identifizieren nicht konformer Ressourcen bzw. Schnellstart: Erstellen einer Richtlinienzuweisung zum Identifizieren nicht konformer Ressourcen mithilfe von Azure PowerShell finden Sie Informationen zum Zuweisen von Richtlinien über das Azure-Portal bzw. über Azure PowerShell.

Nächste Schritte