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

  • Artikel
  • 41 Minuten Lesedauer

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.

Grundlegendes zu Sicherung und Wiederherstellung

Datenbanken in Azure SQL Managed Instance und Nicht-Hyperscale-Datenbanken in Azure SQL-Datenbank verwenden die SQL Server-Engine-Technologie zum Sichern und Wiederherstellen von Daten. Hyperscale-Datenbanken besitzen eine eindeutige Architektur und nutzen eine andere Technologie für die Sicherung und Wiederherstellung. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Sicherungshäufigkeit

Sowohl Azure SQL-Datenbank als auch Azure 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.

Hyperscale-Datenbanken verwenden die Momentaufnahmesicherungstechnologie.

Redundanz für Sicherungsspeicher

Standardmäßig speichern Azure SQL-Datenbank und Azure 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 innerhalb derselben Region verbleiben, in der auch Ihre verwaltete Instanz oder Datenbank in Azure 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 Azure 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. Bei Hyperscale-Datenbanken wird die gewählte Speicherredundanzoption während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Wichtig

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

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

    Die Geowiederherstellung steht nur für Datenbanken in Azure SQL-Datenbank oder für verwaltete Instanzen zur Verfügung, die mit einem georedundanten Sicherungsspeicher konfiguriert wurden. Wenn Sie derzeit keine georeplizierten Sicherungen für eine Datenbank verwenden, können Sie dies durch Konfigurieren der Sicherungsspeicherredundanz ändern.

  • 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, Azure CLI 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 weniger 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 weniger 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 weniger 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 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
Wiederherstellen einer Datenbank aus Azure Blob Storage
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. Hyperscale verwendet einen anderen Sicherungsplanungsmechanismus. Weitere Informationen finden Sie unter Hyperscale-Sicherungsplanung.

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 Azure SQL-Datenbank und Azure 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. Hyperscale-Datenbanken verwenden einen anderen Sicherungsplanungsmechanismus. Weitere Informationen finden Sie unter Hyperscale-Sicherungsplanung, und zusätzliche Details zur Überwachung von Speicherkosten finden Sie unter Hyperscale-Sicherungsspeicherkosten.

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.

Azure SQL-Datenbank und Azure SQL Managed Instance berechnen den insgesamt 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 mit virtuellen Kernen in Azure SQL-Datenbank 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.

Monitor database backup consumption in the Azure portal

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

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

Azure SQL Database und Azure SQL Managed Instance bieten sowohl eine kurzfristige als auch eine langfristige Aufbewahrung von Backups. Die kurzfristige Aufbewahrung von Sicherungen ermöglicht eine Zeitpunktwiederherstellung (Point-In-Time-Restore, PITR) innerhalb des Aufbewahrungszeitraums für die Datenbank, während die langfristige Aufbewahrung Sicherungen zur Erfüllung verschiedener Complianceanforderungen bietet.

Kurzfristige Aufbewahrung

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. Es werden regelmäßig Voll-, Differenz- und Protokollsicherungen durchgeführt, um sicherzustellen, dass Datenbanken zu jedem beliebigen Zeitpunkt innerhalb des für die Datenbank oder verwaltete Instanz festgelegten Aufbewahrungszeitraums wiederherstellbar sind. Zusätzlich können für Azure SQL-Datenbanken differenzielle Backups entweder auf eine 12-Stunden- oder eine 24-Stunden-Frequenz konfiguriert werden.

Hinweis

Eine 24-Stunden-Frequenz für differenzielle Backups kann die für die Wiederherstellung der Datenbank erforderliche Zeit erhöhen.

Mit Ausnahme von Datenbanken im Tarif „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.

Hinweis

Die kurzfristige Sicherungsaufbewahrung für 1 bis 35 Tage für Hyperscale-Datenbanken ist ab sofort in der Vorschauversion verfügbar. Weitere Informationen finden Sie unter Verwalten der Aufbewahrung von Sicherungen in Hyperscale.

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.

Formeln, die zum Berechnen von Sicherungsspeicherkosten für Hyperscale-Datenbanken verwendet werden, finden Sie in Hyperscale-Sicherungsspeicherkosten.

Azure SQL-Datenbank und Azure 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

Eine Sicherungsspeicherredundanz für Hyperscale 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. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Ü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 wie folgt nach dem gewünschten Zeitraum und Dienst:

  1. Fügen Sie einen Filter für Dienstname hinzu.
  2. Wählen Sie für eine einzelne Datenbank oder einen Pool für elastische Datenbanken in der Dropdownliste SQL-Datenbank bzw. für eine verwaltete Instanz die Option SQL Managed Instance aus.
  3. Fügen Sie einen weiteren Filter für Unterkategorie der Verbrauchseinheit hinzu.
  4. Wählen Sie zum Überwachen der Kosten für PITR-Sicherungen für eine einzelne Datenbank oder einen Pool für elastische Datenbanken in der Dropdownliste den PITR-Sicherungsspeicher für eine einzelne Datenbank/einen Pool für elastische Datenbanken aus. Wählen Sie für eine verwaltete Instanz den PITR-Sicherungsspeicher für verwaltete Instanzen aus. Verbrauchseinheiten werden nur dann angezeigt, wenn ein Verbrauch vorliegt.
  5. Wählen Sie zum Überwachen der Kosten für LTR-Sicherungen für eine einzelne Datenbank oder einen Pool für elastische Datenbanken in der Dropdownliste den LTR-Sicherungsspeicher aus. Wählen Sie für eine verwaltete Instanz den LTR-Sicherungsspeicher für SQL Managed Instance aus. Verbrauchseinheiten werden nur dann angezeigt, wenn ein Verbrauch vorliegt.

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

Backup storage cost analysis

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 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. Wenn der PITR- oder LTR-Sicherungsspeicher beispielsweise 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 finden Sie unter Transparent Data Encryption für SQL-Datenbank und SQL Managed Instance.

Sicherungsintegrität

Das Azure SQL-Entwicklungsteam testet fortlaufend automatisch die Wiederherstellung von automatischen Datenbanksicherungen. (Diese Tests sind derzeit nicht in SQL Managed Instance verfügbar. Planen Sie DBCC CHECKDB für Ihre Datenbanken in SQL Managed Instance entsprechend der Anforderungen Ihrer Workload.)

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 der kurzfristigen Aufbewahrungsrichtlinie

Sie können die Standardaufbewahrungszeit für PITR-Sicherungen und die Häufigkeit der differenziellen Sicherungen über das Azure-Portal, PowerShell oder die REST-API ändern. Die folgenden Beispiele veranschaulichen, wie Sie die PITR-Aufbewahrung auf 28 Tage und die differenziellen Backups auf ein Intervall von 24 Stunden ä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 kurzfristigen Aufbewahrungsrichtlinie über das Azure-Portal

Um die PITR-Sicherungsaufbewahrungszeit oder die Häufigkeit der differenziellen Sicherung für aktive Datenbanken über das Azure-Portal zu ändern, wechseln Sie zu dem Server oder der verwalteten Instanz mit den Datenbanken, deren Aufbewahrungszeit Sie ändern möchten. 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 kurzfristigen Aufbewahrungsrichtlinie mithilfe von Azure CLI

Bereiten Sie die Umgebung für die Azure CLI vor.

  • Verwenden Sie die Bash-Umgebung in Azure Cloud Shell. Weitere Informationen finden Sie unter Azure Cloud Shell-Schnellstart: Bash.

    Launch Cloud Shell in a new window

  • Wenn Sie CLI-Referenzbefehle lieber lokal ausführen, installieren Sie die Azure CLI. Wenn Sie unter Windows oder macOS arbeiten, sollten Sie die Azure CLI in einem Docker-Container ausführen. Weitere Informationen finden Sie unter Ausführen der Azure CLI in einem Docker-Container.

    • Wenn Sie eine lokale Installation verwenden, melden Sie sich mithilfe des Befehls az login bei der Azure CLI an. Führen Sie die in Ihrem Terminal angezeigten Schritte aus, um den Authentifizierungsprozess abzuschließen. Weitere Anmeldeoptionen finden Sie unter Anmelden mit der Azure CLI.

    • Installieren Sie die Azure CLI-Erweiterungen bei der ersten Verwendung, wenn Sie dazu aufgefordert werden. Weitere Informationen zu Erweiterungen finden Sie unter Verwenden von Erweiterungen mit der Azure CLI.

    • Führen Sie az version aus, um die installierte Version und die abhängigen Bibliotheken zu ermitteln. Führen Sie az upgrade aus, um das Upgrade auf die aktuelle Version durchzuführen.

Ändern Sie die PITR-Sicherungsaufbewahrung und die Häufigkeit der differenziellen Sicherung für aktive Azure SQL-Datenbanken mit Hilfe des folgenden Beispiels.

# Set new PITR differential backup frequency on an active individual database
# Valid backup retention must be between 1 and 35 days
# Valid differential backup frequency must be ether 12 or 24
az sql db str-policy set \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --retention-days 28 \
    --diffbackup-hours 24

Ändern der kurzfristigen Aufbewahrungsrichtlinie mithilfe von PowerShell

Hinweis

In diesem Artikel wird das Azure Az PowerShell-Modul verwendet. Dieses 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-Sicherungsaufbewahrung und die Häufigkeit der differenziellen Sicherung 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

# SET new PITR differential backup frequency on an active individual database
# Valid differential backup frequency must be ether 12 or 24. 
Set-AzSqlDatabaseBackupShortTermRetentionPolicy -ResourceGroupName resourceGroup -ServerName testserver -DatabaseName testDatabase -RetentionDays 28 -DiffBackupIntervalInHours 24

Ändern der kurzfristigen Aufbewahrungsrichtlinie mithilfe der REST-API

Die folgende Anforderung aktualisiert den Aufbewahrungszeitraum auf 28 Tage und setzt die Häufigkeit der differenziellen Sicherung auf 24 Stunden.

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=2021-02-01-preview

Anforderungstext

{ 
    "properties":{
        "retentionDays":28,
        "diffBackupIntervalInHours":24
  }
}

Beispielantwort:

{ 
  "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,
    "diffBackupIntervalInHours":24
  }
}

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

Hyperscale-Sicherungen und Speicherredundanz

Hyperscale-Datenbanken in Azure SQL-Datenbank nutzen eine einzigartige Architektur mit hoch skalierbaren Leistungsebenen für Speicher- und Computeressourcen.

Hyperscale-Sicherungen basieren auf Momentaufnahmen und sind nahezu sofort verfügbar. Das erzeugte Protokoll wird im langfristigen Azure-Speicher für die Dauer der Sicherungsaufbewahrung gespeichert. Die Hyperscale-Architektur verwendet keine vollständigen Datenbanksicherungen oder Protokollsicherungen und deshalb gelten die Sicherungshäufigkeit, Speicherkosten, Planung, der Speicher und die Redundanz sowie die Wiederherstellungsfunktionen nicht, die in den vorigen Abschnitten dieses Artikels beschrieben sind.

Hyperscale-Sicherung und Wiederherstellungsleistung

Durch die Trennung von Speicher- und Computeressourcen kann bei Hyperscale-Datenbanken der Sicherungs-/Wiederherstellungsvorgang auf die Speicherebene verlegt werden, um die Verarbeitungslast für das primäre Computereplikat zu verringern. Dadurch wirkt sich die Datenbanksicherung nicht auf die Leistung des primären Computeknotens aus.

Sicherungs- und Wiederherstellungsvorgänge für Hyperscale-Datenbanken erfolgen dank der Verwendung von Speichermomentaufnahmen unabhängig von der Datengröße sehr schnell. Eine Datenbank kann an jedem beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums der Sicherung wiederhergestellt werden. Bei der Zeitpunktwiederherstellung (Point In Time Recovery, PITR) erfolgt die Wiederherstellung anhand von Dateimomentaufnahmen, deshalb ist dieser Vorgang nicht von der Datengröße abhängig. Die Wiederherstellung einer Hyperscale-Datenbank innerhalb derselben Azure-Region ist ein Vorgang mit konstanter Dauer, und selbst Datenbanken mit mehreren Terabyte können innerhalb von Minuten statt Stunden oder Tagen wiederhergestellt werden. Auch beim Erstellen neuer Datenbanken durch Wiederherstellung einer vorhandenen Sicherung oder durch Kopieren der Datenbank wird von dieser Funktion profitiert: Das Erstellen von Datenbankkopien für Entwicklungs- oder Testzwecke – selbst von Datenbanken mit mehreren Terabyte – ist innerhalb derselben Region in wenigen Minuten möglich, wenn derselbe Speichertyp verwendet wird.

Aufbewahrung von Hyperscale-Sicherungen

Die standardmäßige kurzfristige Sicherungsaufbewahrung (Short-Term Backup Retention, STR) für Hyperscale-Datenbanken beträgt 7 Tage; Richtlinien für die Langzeitaufbewahrung (Long-Term Retention, LTR) werden derzeit nicht unterstützt.

Hinweis

Die kurzfristige Sicherungsaufbewahrung bis zu 35 Tage für Hyperscale-Datenbanken ist jetzt in der Vorschau verfügbar.

Planung der Hyperscale-Sicherung

Für Hyperscale-Datenbanken sind keine herkömmlichen vollständigen, differenziellen und Transaktionsprotokollsicherungen möglich. Stattdessen gibt es reguläre Speichermomentaufnahmen von Datendateien. Das generierte Transaktionsprotokoll wird für den konfigurierten Aufbewahrungszeitraum im unveränderten Zustand gespeichert. Zum Zeitpunkt der Wiederherstellung werden relevante Transaktionsprotokolleinträge auf die wiederhergestellte Speichermomentaufnahme angewendet. Dies führt zu einer transaktionskonsistenten Datenbank ohne Datenverlust ab dem angegebenen Zeitpunkt innerhalb des Aufbewahrungszeitraums.

Kosten der Hyperscale-Sicherungsspeichung

Die Kosten für die Hyperscale-Sicherungsspeicherung hängen von der Wahl der Region und der Redundanz des Sicherungsspeichers ab. Sie sind ebenso vom Workloadtyp abhängig. Bei schreibintensiven Workloads ist es wahrscheinlicher, dass Datenseiten häufig geändert werden, was zu größeren Speichermomentaufnahmen führt. Solche Workloads generieren auch mehr Transaktionsprotokolle, was zu den Gesamtsicherungskosten beiträgt. Der Sicherungsspeicher wird pro verbrauchtem GB/Monat berechnet. Preisdetails finden Sie auf der Seite zu Azure SQL-Datenbank-Preisen.

Für Hyperscale wird der gebührenpflichtige Sicherungsspeicher wie folgt berechnet:

Total billable backup storage size = (Data backup storage size + Log backup storage size)

Die Größe des Datenspeichers ist nicht in der gebührenpflichtigen Sicherung enthalten, da sie bereits als zugewiesener Datenbankspeicher berechnet wird.

Gelöschte Hyperscale-Datenbanken verursachen Sicherungskosten, um die Wiederherstellung zu einem Zeitpunkt vor dem Löschen zu unterstützen. Bei einer gelöschten Hyperscale-Datenbank wird der gebührenpflichtige Sicherungsspeicher wie folgt berechnet:

Total billable backup storage size for deleted Hyperscale database = (Data storage size + Data backup size + Log backup storage size) * (remaining backup retention period after deletion/configured backup retention period)

Die Größe des Datenspeichers ist in der Formel enthalten, da der zugeordnete Datenbankspeicher nicht separat für eine gelöschte Datenbank berechnet wird. Bei einer gelöschten Datenbank werden Daten nach dem Löschen gespeichert, um die Wiederherstellung während des konfigurierten Sicherungsaufbewahrungszeitraums zu ermöglichen. Der gebührenpflichtige Sicherungsspeicher für eine gelöschte Datenbank verringert sich schrittweise nach dem Löschen. Wenn Sicherungen nicht mehr aufbewahrt werden und die Wiederherstellung nicht mehr möglich ist, ruht der Speicher. Wenn es sich jedoch um eine dauerhafte Löschung handelt und Sicherungen nicht mehr benötigt werden, können Sie die Kosten optimieren, um die Aufbewahrung zu verringern, bevor Sie die Datenbank löschen.

Überwachen des Sicherungsspeicherverbrauchs in Hyperscale

In Hyperscale werden die Datensicherungsspeichergröße (Momentaufnahmesicherungsgröße), die Datenspeichergröße (Datenbankgröße) und die Protokollsicherungsgröße (Größe der Transaktionsprotokollsicherung) über Azure Monitor-Metriken gemeldet.

Führen Sie die folgenden Schritte aus, um Sicherungs- und Datenspeichermetriken im Azure-Portal anzuzeigen:

  1. Wechseln Sie zur Hyperscale-Datenbank, für die Sie Sicherungs- und Datenspeichermetriken überwachen möchten.
  2. Wählen Sie die Seite „Metriken“ im Abschnitt Überwachung aus.

Screenshot of the Azure portal showing the Hyperscale Backup storage metrics

  1. Wählen Sie in der Dropdownliste „Metrik“ die Metriken Datensicherungsspeicher und Protokollsicherungsspeicher mit den entsprechenden Aggregationsregeln aus.

Reduzieren des Sicherungsspeicherverbrauchs

Der Sicherungsspeicherverbrauch für eine Hyperscale-Datenbank hängt vom Aufbewahrungszeitraum, der Auswahl der Region, der Sicherungsspeicherredundanz und des Workloadtyps ab. Ziehen Sie einige der folgenden Optimierungstechniken in Betracht, um den Sicherungsspeicherverbrauch für eine Hyperscale-Datenbank zu reduzieren:

  • Reduzieren Sie den Aufbewahrungszeitraum für Sicherungen auf die Mindestanforderungen für Ihre Zwecke.
  • Vermeiden Sie es, häufiger als erforderlich große Schreibvorgänge auszuführen, z. B. die Indexwartung. Weitere Empfehlungen zur Indexpflege finden Sie unter Optimierung der Indexpflege zur Verbesserung der Abfrageleistung und Reduzierung des Ressourcenverbrauchs.
  • Bei großen Datenladevorgängen sollten Sie ggf. die Datenkomprimierung verwenden.
  • Verwenden Sie die tempdb-Datenbank anstelle permanenter Tabellen in Ihrer Anwendungslogik zum Speichern temporärer Ergebnisse oder vorübergehender Daten.
  • Verwenden Sie einen lokal redundanten oder zonenredundanten Sicherungsspeicher, wenn die Geowiederherstellungsfunktion unnötig ist (z. B. Entwicklungs-/Testumgebungen).

Hyperscale-Speicherredundanz gilt sowohl für Datenspeicherung als auch für Sicherungsspeicher

Hyperscale unterstützt das Konfigurieren der Speicherredundanz. Beim Erstellen einer Hyperscale-Datenbank können Sie Ihren bevorzugten Speichertyp auswählen: georedundanten Speicher mit Lesezugriff (RA-GRS), zonenredundanten Speicher (ZRS) oder lokal redundanten Speicher (LRS) Azure-Standardspeicher. Die ausgewählte Speicherredundanzoption wird während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet.

Sorgfältiges Erwägen der Speicherredundanz beim Erstellen einer Hyperscale-Datenbank

Die Sicherungsspeicherredundanz für Hyperscale-Datenbanken kann nur während der Datenbankerstellung festgelegt werden. Diese Einstellung kann nach der Bereitstellung der Ressource nicht mehr geändert werden. Die Geowiederherstellung ist nur verfügbar, wenn georedundanter Speicher (RA-GRS) für die Sicherungsspeicherredundanz ausgewählt wurde. Der Datenbankkopiervorgang kann genutzt werden, um die Speicherredundanzeinstellungen für eine vorhandene Hyperscale-Datenbank zu aktualisieren. Das Kopieren einer Datenbank in einen anderen Speichertyp ist ein von der Größe der Daten abhängiger Vorgang. Beispielcode finden Sie unter Konfigurieren der Sicherungsspeicherredundanz.

Wichtig

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

Wiederherstellen einer Hyperscale-Datenbank in einer anderen Region

Wenn Sie im Rahmen der Wiederherstellung einer Hyperscale-Datenbank in Azure SQL-Datenbank im Notfall oder im Rahmen einer Übung, wegen eines Umzugs oder aus einem sonstigen Grund in einer anderen Region wiederherstellen müssen als der, in der sie gerade gehostet wird, besteht die primäre Methode in einer Geowiederherstellung der Datenbank. Die Schritte sind die gleichen wie beim Wiederherstellen jeder anderen Datenbank in SQL-Datenbank in einer anderen Region:

  1. Erstellen Sie einen Server in der Zielregion, wenn Sie dort noch keinen geeigneten Server haben. Dieser Server muss zu demselben Abonnement wie der ursprüngliche Server (Quelle) gehören.
  2. Befolgen Sie die Anweisungen im Abschnitt Geowiederherstellung des Artikels zum Wiederherstellen einer Datenbank in Azure SQL-Datenbank aus automatischen Sicherungen.

Hinweis

Weil Quelle und Ziel sich in unterschiedlichen Regionen befinden, kann die Datenbank nicht wie in Nicht-Geowiederherstellungen Momentaufnahmenspeicher mit der Quelldatenbank gemeinsam nutzen, was unabhängig von der Datenbankgröße zu einem schnellen Abschluss führt. Bei einer Geowiederherstellung einer Hyperscale-Datenbank werden auch dann Anpassungen des Datenumfangs durchgeführt, wenn das Ziel sich in der gekoppelten Region des georeplizierten Speichers befindet. Darum ist die für eine Geowiederherstellung erforderliche Zeit proportional zur Größe der wiederhergestellten Datenbank. Wenn das Ziel in der gekoppelten Region liegt, findet die Datenübertragung innerhalb einer Region statt, was wesentlich schneller ist als eine regionsübergreifende Datenübertragung, es handelt sich aber immer noch um einen zeitintensiven Vorgang.

Wenn Sie möchten, können Sie die Datenbank auch in eine andere Region kopieren. Weitere Informationen finden Sie unter Datenbankkopie für Azure SQL Hyperscale.

Konfigurieren der Redundanz für Sicherungsspeicher

Die Sicherungsspeicherredundanz für Datenbanken in Azure SQL-Datenbank 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. 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. Die Speicherredundanz für Hyperscale-Datenbanken ist einzigartig: Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Für Azure SQL Managed Instance wird die Sicherungsspeicherredundanz auf Instanzebene festgelegt und auf alle zugehörigen verwalteten Datenbanken angewendet. Sie kann zum Zeitpunkt der Erstellung einer Instanz konfiguriert oder für vorhandene Instanzen aktualisiert werden. Die Änderung der Sicherungsspeicherredundanz löst dann eine neue vollständige Sicherung pro Datenbank aus, und die Änderung gilt für alle zukünftigen Sicherungen. Der Standardtyp für die Speicherredundanz ist Georedundanz (RA-GRS).

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.

Open Create SQL Database pane

Konfigurieren der Redundanz für Sicherungsspeicher über Azure CLI

Zum Konfigurieren der Sicherungsspeicherredundanz beim Erstellen einer neuen Datenbank können Sie den Parameter --backup-storage-redundancy mit dem Befehl az sql db create angeben. Mögliche Werte sind Geo, Zone und Local. Standardmäßig verwenden alle Datenbanken in Azure SQL-Datenbank georedundanten Speicher für Sicherungen. Die Geowiederherstellung ist deaktiviert, wenn eine Datenbank mit lokalem oder zonenredundanten Sicherungsspeicher erstellt oder aktualisiert wird.

In diesem Beispiel wird eine Datenbank der Dienstebene Universell mit lokaler Sicherungsredundanz erstellt:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier GeneralPurpose \
    --backup-storage-redundancy Local

Wählen Sie die Konfigurationsoption für --backup-storage-redundancy sorgfältig aus, wenn Sie eine Hyperscale-Datenbank erstellen. Die Speicherredundanz kann nur während der Erstellung einer Hyperscale-Datenbank angegeben werden. Die ausgewählte Speicherredundanzoption wird während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Vorhandene Hyperscale-Datenbanken können mithilfe einer Datenbankkopie oder einer Zeitpunktwiederherstellung zu einer anderen Speicherredundanz migriert werden. Weiter unten in diesem Abschnitt finden Sie Beispielcode zum Kopieren einer Hyperscale-Datenbank.

In diesem Beispiel wird eine Datenbank auf der Dienstebene Hyperscale mit Zonenredundanz erstellt:

az sql db create \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --tier Hyperscale \
    --backup-storage-redundancy Zone

Weitere Informationen finden Sie unter az sql db create und az sql db update.

Mit Ausnahme von Datenbanken der Tarife „Hyperscale“ und „Basic“ können Sie die Einstellung der Sicherungsspeicherredundanz für eine vorhandene Datenbank mit dem Parameter --backup-storage-redundancy und dem Befehl az sql db update aktualisieren. 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.

Dieser Beispielcode ändert die Sicherungsspeicherredundanz in Local.

az sql db update \
    --resource-group myresourcegroup \
    --server myserver \
    --name mydb \
    --backup-storage-redundancy Local

Sie können die Sicherungsspeicherredundanz einer Hyperscale-Datenbank nicht direkt aktualisieren. Sie können die Einstellung jedoch ändern, indem Sie den Datenbankkopierbefehl mit dem Parameter --backup-storage-redundancy verwenden. In diesem Beispiel wird eine Hyperscale-Datenbank in eine neue Datenbank mit Verwendung von Gen5-Hardware und zwei virtuellen Kernen kopiert. Für die neue Datenbank ist die Sicherungsredundanz auf Zone festgelegt.

az sql db copy \
    --resource-group myresourcegroup \ 
    --server myserver 
    --name myHSdb 
    --dest-resource-group mydestresourcegroup 
    --dest-server destdb 
    --dest-name myHSdb 
    --service-objective HS_Gen5_2 
    --read-replicas 0 
    --backup-storage-redundancy Zone

Details zur Syntax finden Sie unter az sql db copy. Eine Übersicht über das Kopieren von Datenbanken finden Sie unter Kopieren einer transaktionskonsistenten Kopie einer Datenbank in Azure SQL-Datenbank.

Konfigurieren der Redundanz für Sicherungsspeicher mithilfe von PowerShell

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

In diesem Beispiel wird eine Datenbank der Dienstebene Universell mit lokaler Sicherungsredundanz erstellt:

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

Wählen Sie die Konfigurationsoption für --backup-storage-redundancy sorgfältig aus, wenn Sie eine Hyperscale-Datenbank erstellen. Die Speicherredundanz kann nur während der Erstellung einer Hyperscale-Datenbank angegeben werden. Die ausgewählte Speicherredundanzoption wird während der gesamten Lebensdauer der Datenbank sowohl für die Datenspeicherredundanz als auch für die Sicherungsspeicherredundanz verwendet. Weitere Informationen finden Sie unter Hyperscale-Sicherungen und Speicherredundanz.

Vorhandene Datenbanken können mithilfe einer Datenbankkopie oder einer Zeitpunktwiederherstellung zu einer anderen Speicherredundanz migriert werden. Weiter unten in diesem Abschnitt finden Sie Beispielcode zum Kopieren einer Hyperscale-Datenbank.

In diesem Beispiel wird eine Datenbank auf der Dienstebene Hyperscale mit Zonenredundanz erstellt:

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

Details zur Syntax finden Sie unter New-AzSqlDatabase.

Mit Ausnahme von Datenbanken der Tarife „Hyperscale“ und „Basic“ können Sie den Parameter -BackupStorageRedundancy mit dem Cmdlet Set-AzSqlDatabase verwenden, um die Einstellung für die Sicherungsspeicherredundanz für eine vorhandene Datenbank zu aktualisieren. 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.

Dieser Beispielcode ändert die Sicherungsspeicherredundanz in Local.

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

Details hierzu finden Sie unter Set-AzSqlDatabase.

Die Sicherungsspeicherredundanz einer vorhandenen Hyperscale-Datenbank kann nicht aktualisiert werden. Sie können jedoch den Datenbankkopierbefehl verwenden, um eine Kopie der Datenbank zu erstellen, und den Parameter -BackupStorageRedundancy angeben, um die Sicherungsspeicherredundanz zu aktualisieren. In diesem Beispiel wird eine Hyperscale-Datenbank in eine neue Datenbank mit Verwendung von Gen5-Hardware und zwei virtuellen Kernen kopiert. Für die neue Datenbank ist die Sicherungsredundanz auf Zone festgelegt.

# Change the backup storage redundancy for Database01 to zone-redundant. 
New-AzSqlDatabaseCopy -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "HSSourceDB" -CopyResourceGroupName "DestResourceGroup" -CopyServerName "DestServer" -CopyDatabaseName "HSDestDB" -Vcore 2 -ComputeGeneration "Gen5" -ComputeModel Provisioned -BackupStorageRedundancy Zone

Details zur Syntax finden Sie unter New-AzSqlDatabaseCopy.

Eine Übersicht über das Kopieren von Datenbanken finden Sie unter Kopieren einer transaktionskonsistenten Kopie einer Datenbank in Azure SQL-Datenbank.

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