Automatisierte Sicherungen in Azure SQL Managed Instance

  • Artikel

Gilt für:Azure SQL Managed Instance

In diesem Artikel wird das automatisierte Sicherungsfeature für Azure SQL Managed Instance beschrieben.

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

Was sind automatisierte Datenbanksicherungen?

Datenbanksicherungen sind ein wesentlicher Bestandteil jeder Strategie für Geschäftskontinuität und Notfallwiederherstellung, da sie dazu beitragen, Ihre Daten vor Beschädigung oder Löschung zu schützen. Azure SQL Managed Instance bietet vollständig verwaltete und automatisierte Sicherungen der SQL Server-Datenbank-Engine. Diese Sicherungen ermöglichen die Wiederherstellung der Datenbank zu einem bestimmten Zeitpunkt innerhalb der konfigurierten Aufbewahrungsfrist von bis zu 35 Tagen. Wenn Ihre Datenschutzregeln jedoch erfordern, dass Ihre Sicherungen über einen längeren Zeitraum (bis zu 10 Jahre) verfügbar sein müssen, können Sie Richtlinien zur Langzeitaufbewahrung (LTR) pro Datenbank konfigurieren.

Sicherungshäufigkeit

Azure SQL Managed Instance erstellt Folgendes:

Die Häufigkeit von Transaktionsprotokollsicherungen basiert auf der Computegröße und dem Umfang der Datenbankaktivität. Die Transaktionsprotokolle werden etwa alle 10 Minuten erstellt, können aber variieren. Wenn Sie eine Datenbank wiederherstellen, bestimmt der Dienst, welche vollständigen, differenziellen und Transaktionsprotokollsicherungen in ihrer jeweiligen Reihenfolge wiederhergestellt werden müssen.

Redundanz für Sicherungsspeicher

Standardmäßig speichert Azure SQL Managed Instance Daten in georedundanten Speicherblobs, die in einem Regionspaar repliziert werden. Georedundanz schützt vor Ausfällen, die den Sicherungsspeicher in der primären Region beeinträchtigen. Außerdem können Sie Ihre Instanz im Falle eines Notfalls in einer anderen Region wiederherstellen.

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

Um sicherzustellen, dass Ihre Sicherungen in derselben Region bleiben, in der Ihre Datenbank bereitgestellt wird, können Sie die Sicherungsspeicherrundanz von der standardmäßigen georedundanten Speicherung in andere Speichertypen ändern, die Ihre Daten innerhalb der Region beibehalten. Weitere Informationen zur Speicherredundanz finden Sie unter Datenredundanz.

Sie können die Redundanz des Sicherungsspeichers konfigurieren, wenn Sie Ihre Instanz erstellen, und Sie können sie später auf Instanzebene aktualisieren. Änderungen, die Sie an einer vorhandenen Instanz vornehmen, gelten nur für zukünftige Sicherungen. Nachdem Sie die Redundanz des Sicherungsspeichers einer bestehenden Instanz aktualisiert haben, kann es bis zu 24 Stunden dauern, bis die Änderungen übernommen werden. Änderungen an der Redundanz des Sicherungsspeichers gelten nur für kurzfristige Sicherungen. Richtlinien zur Langzeitaufbewahrung erben die Redundanzoption der kurzfristigen Sicherungen, wenn die Richtlinie erstellt wird. Die Redundanzoption für langfristige Sicherungen bleibt auch dann erhalten, wenn die Redundanzoption für kurzfristige Sicherungen nachträglich geändert wird.

Notiz

Beachten Sie, dass die Änderung der Sicherungsredundanz ein Upgrade auslöst, das ein Failover initiiert.

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

  • Lokal redundanter Speicher (LRS): Die Sicherungen werden synchron innerhalb eines einzelnen physischen Standorts in der primären Region kopiert. LRS ist die kostengünstigste Replikationsoption, aber wir empfehlen sie nicht für Anwendungen, die Hochverfügbarkeit oder Dauerhaftigkeit erfordern.

    Diagram showing the locally redundant storage (LRS) option.

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

    Diagram showing the zone-redundant storage (ZRS) option.

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

    Es wird folgendes Ergebnis ausgegeben:

    • Drei synchrone Kopien in der primären Region innerhalb einer einzelnen Verfügbarkeitszone.
    • Drei synchrone Kopien in der gekoppelten Region innerhalb einer einzigen Verfügbarkeitszone, die asynchron von der primären Region in die sekundäre Region kopiert wurden.

    Diagram showing the geo-redundant storage (GRS) option.

  • Geozonenredundanter Speicher (GZRS): Kombiniert die Hochverfügbarkeit durch Redundanz über Verfügbarkeitszonen hinweg mit dem Schutz vor regionalen Ausfällen, der durch Georeplikation geboten wird. Die Daten in einem GZRS-Konto werden über drei Azure-Verfügbarkeitszonen in der primären Region kopiert. Zum Schutz vor regionalen Notfällen werden die Daten auch in eine zweite geografische Region repliziert. In dieser Region gibt es ebenfalls drei synchrone Kopien in einer einzigen Verfügbarkeitszone, die asynchron von der primären Region in die sekundäre Region kopiert wurden.

    Diagram showing the geo-zone-redundant storage (GZRS) option.

Warnung

  • Geowiederherstellung wird deaktiviert, sobald die Datenbank so aktualisiert wurde, dass lokal redundanter oder zonenredundanter Speicher verwendet wird.
  • Alle Diagramme mit den Speicherredundanzen zeigen Regionen mit mehreren Verfügbarkeitszonen (multi-az). Es gibt jedoch einige Regionen, die nur eine einzige Verfügbarkeitszone bereitstellen und weder ZRS noch GZRS unterstützen.

Sicherungsverwendung

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

  • Stellen Sie für eine vorhandene Datenbank den Stand zu einem vergangenen Zeitpunkt wieder her, der innerhalb des Aufbewahrungszeitraums liegt, indem Sie das Azure-Portal, Azure PowerShell, die Azure CLI oder die REST-API verwenden. Dieser Vorgang erstellt eine neue Datenbank entweder auf derselben Instanz wie die ursprüngliche Datenbank oder auf einer anderen Instanz in derselben Subscription und in derselben Region. Er verwendet einen anderen Namen, um das Überschreiben der Originaldatenbank zu vermeiden. Sie können das Azure-Portal auch verwenden, um Ihre Point-in-Time-Datenbanksicherung in einer Instanz in einer anderen Subscription aus Ihrer Quellinstanz wiederherzustellen.

    Nach Abschluss der Wiederherstellung können Sie die Originaldatenbank löschen. Alternativ dazu können Sie sowohl die ursprüngliche Datenbank umbenennen als auch die wiederhergestellte Datenbank in den ursprünglichen Datenbanknamen umbenennen.

  • Wiederherstellen einer gelöschten Datenbank zu einem bestimmten Zeitpunkt innerhalb des Aufbewahrungszeitraums, einschließlich des Zeitpunkts der Löschung. Sie können die gelöschte Datenbank in derselben verwalteten Instanz, in der die Sicherung erstellt wurde, oder in einer anderen Instanz im selben oder in einer anderen Subscription als der Quellinstanz wiederherstellen. Bevor Sie eine Datenbank löschen, nimmt der Dienst eine abschließende Transaktionsprotokollsicherung vor, um Datenverluste zu vermeiden.

  • 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 einer beliebigen vorhandenen verwalteten Instanz in einer beliebigen Azure-Region erstellt.

    Wichtig

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

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

Funktionen und Features für die Wiederherstellung

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

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

1Für unternehmenskritische Anwendungen, die große Datenbanken erfordern und die Geschäftskontinuität sicherstellen müssen, siehe Failovergruppen.

2 Alle Zeitpunktwiederherstellungssicherungen werden standardmäßig in georedundanten Speicher gespeichert. Daher ist die Geowiederherstellung standardmäßig aktiviert.

3Die Problemumgehung besteht in der Wiederherstellung auf einem neuen Server und dem Verschieben von Ressourcen, um den Server in eine andere Subscription zu verschieben.

Wiederherstellen einer Datenbank aus einer Sicherung

Informationen zum Durchführen einer Wiederherstellung finden Sie unter Wiederherstellen einer Datenbank aus Sicherungen. 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

Planen von automatischen Backups

Azure SQL Managed Instance verwaltet Sicherungen automatisch, indem vollständige, differenzielle und Transaktionsprotokollsicherungen erstellt werden. Dieser Prozess unterliegt einem internen Zeitplan.

Erste Sicherung

  • Neue Datenbanken: Unmittelbar nachdem eine Datenbank erstellt oder wiederhergestellt wurde oder Änderungen an der Backup-Redundanz vorgenommen wurden, wird das erste vollständige Backup gestartet. Diese Sicherung wird in der Regel innerhalb von 30 Minuten abgeschlossen, aber für größere Datenbanken kann es länger dauern.

  • Wiederhergestellte Datenbanken: Die Dauer der ersten Sicherung für wiederhergestellte Datenbanken variiert und hängt von der Datenbankgröße ab. Wiederhergestellte Datenbanken oder Datenbankkopien, die häufig größer sind, erfordern möglicherweise mehr Zeit für die anfängliche Sicherung.

Zeitgesteuerte vollständige Backups

  • Wöchentlicher Zeitplan: Das System legt ein wöchentliches vollständiges Sicherungsfenster für die gesamte Instanz fest.
  • Vollständiges Sicherungsfenster: Dies ist ein festgelegter Zeitraum, in dem vollständige Sicherungen ausgeführt werden. Während das System beabsichtigt, vollständige Sicherungen innerhalb dieses Fensters abzuschließen, kann die Sicherung ggf. über die geplante Zeit hinaus fortgesetzt werden, bis sie abgeschlossen ist.
  • Adaptive Planung: Der Sicherungsalgorithmus wertet die Auswirkungen des Sicherungsfensters ungefähr einmal pro Woche auf die Workload aus, wobei die CPU-Auslastung und der E/A-Durchsatz als Indikatoren verwendet werden. Je nach Arbeitsauslastung der vorherigen Woche kann das vollständige Sicherungsfenster angepasst werden.
  • Benutzerkonfiguration: Es ist wichtig zu beachten, dass Benutzer den Sicherungszeitplan nicht ändern oder deaktivieren können.

Wichtig

Für eine neue, wiederhergestellte oder kopierte Datenbank wird die Funktion für die Zeitpunktwiederherstellung (PITR) verfügbar, wenn die erste Transaktionsprotokollsicherung, die auf die anfängliche vollständige Sicherung folgt, erstellt wird.

Sicherungsspeicherverbrauch

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

Der Sicherungszeitplan für Azure SQL Managed Instance umfasst jede Woche eine vollständige Sicherung. Um die Zeitpunktwiederherstellung innerhalb des gesamten Aufbewahrungszeitraums bereitzustellen, muss das System zusätzlich vollständige, differenzielle und Transaktionsprotokollsicherungen für bis zu eine Woche über den konfigurierten Aufbewahrungszeitraum hinaus speichern.

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

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

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

Wichtig

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

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

Wichtig

Sicherungen für eine gelöschte Datenbank werden für die Zeitpunktwiederherstellung (Point-in-Time Restore, PITR) aufbewahrt, was die Speicherkosten erhöhen kann, da Sicherungen aufbewahrt werden, obwohl die Datenbank gelöscht ist. Um die Kosten zu senken, können Sie den Aufbewahrungszeitraum für Sicherungen auf 0 Tage festlegen, allerdings nur für gelöschte Datenbanken. Für reguläre Datenbanken beträgt die Mindestaufbewahrungszeit 1 Tag.

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. Erwägen Sie auch, die Anzahl der nicht gruppierten Indizes zu verringern.
  • Auf der Dienstebene „Universell“ ist der bereitgestellte Datenspeicher günstiger als die Kosten für den Sicherungsspeicher. Wenn ständig hohe Kosten durch zusätzlichen Sicherungsspeicher anfallen, können Sie eine Vergrößerung des Datenspeichers in Betracht ziehen, um beim Sicherungsspeicher zu sparen.
  • Verwenden Sie tempdb anstelle permanenter Tabellen in Ihrer Anwendungslogik zum Speichern temporärer Ergebnisse oder vorübergehender Daten.
  • Nutzen Sie nach Möglichkeit lokal redundanten Sicherungsspeicher (etwa Entwicklungs-/Testumgebungen).

Sicherungsaufbewahrung

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

Kurzfristige Aufbewahrung

Für alle neuen, wiederhergestellten und kopierten Datenbanken bewahrt Azure SQL Managed Instance genügend Sicherungen auf, um standardmäßig eine Zeitpunktwiederherstellung innerhalb der letzten 7 Tage zu ermöglichen. Diese Konfiguration kann im Bereich von 1 bis 35 Tagen geändert werden. Der Dienst führt regelmäßig vollständige, differenzielle und Protokollsicherungen durch, um sicherzustellen, dass Datenbanken zu jedem beliebigen Zeitpunkt innerhalb des für die Datenbank oder der verwalteten Instanz festgelegten Aufbewahrungszeitraums wiederherstellbar sind.

Sie können die Redundanzoption für den Sicherungsspeicher für STR angeben, wenn Sie Ihre Instanz erstellen und diese zu einem späteren Zeitpunkt ändern. Wenn Sie die Sicherungsredundanzoption ändern, nachdem Ihre Instanz erstellt wurde, verwenden neue Sicherungen die neue Redundanzoption. Sicherungskopien, die mit der vorherigen STR-Redundanzoption erstellt wurden, werden nicht verschoben oder kopiert. Sie verbleiben im ursprünglichen Speicherkonto, bis der Aufbewahrungszeitraum abgelaufen ist. Wie in Sicherungsspeicherverbrauch beschrieben, liegen die zur Aktivierung von Zeitpunktwiederherstellung (Point-in-Time Restore, PITR) gespeicherten Sicherungen möglicherweise zeitlich vor dem Aufbewahrungszeitraum, um eine präzise Datenwiederherstellung zu gewährleisten.

Wenn Sie eine Datenbank löschen, behält das System Sicherungen genauso bei, wie dies für eine Onlinedatenbank mit dem jeweiligen Aufbewahrungszeitraum gelten würde. Für eine gelöschte Datenbank wird der Aufbewahrungszeitraum jedoch von 1 bis 35 Tagen auf 0 bis 35 Tage aktualisiert, sodass es möglich ist, Sicherungen manuell zu löschen. Wenn Sie Sicherungen länger als für die maximale kurzfristige Beibehaltungsdauer von 35 Tagen aufbewahren müssen, können Sie die Langzeitaufbewahrung aktivieren.

Wichtig

Wenn Sie eine verwaltete Instanz löschen, werden alle Datenbanken auf dieser verwalteten Instanz ebenfalls gelöscht und können nicht wiederhergestellt werden. Eine gelöschte verwaltete Instanz kann nicht wiederhergestellt werden. Wenn Sie jedoch die Langzeitaufbewahrung für eine verwaltete Instanz konfiguriert haben, werden LTR-Sicherungen nicht gelöscht. Sie können diese Sicherungen dann verwenden, um Datenbanken auf einer anderen verwalteten Instanz in derselben Subscription wiederherzustellen, zu einem Zeitpunkt, an dem eine LTR-Sicherung ausgeführt wurde. Weitere Informationen finden Sie unter Wiederherstellen langfristiger Sicherungen.

Langzeitaufbewahrung (Long-Term Retention, LTR)

Mit SQL Managed Instance können Sie vollständige LTR-Sicherungen bis zu 10 Jahre lang in Azure Blob Storage konfigurieren. Nachdem die LTR-Richtlinie konfiguriert wurde, werden vollständige Sicherungen wöchentlich automatisch in einen anderen Speichercontainer kopiert.

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

Die Sicherungsspeicherredundanz der Langzeitaufbewahrung in Azure SQL Managed Instance wird von der Sicherungsspeicherredundanz geerbt, die STR zum Zeitpunkt der Definition der LTR-Richtlinie verwendet. Sie können sie nicht ändern, auch wenn sich die STR-Sicherungsspeicherredundanz in Zukunft ändert.

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.

Kosten von Sicherungsspeicher

Azure SQL Managed Instance berechnet den gesamten in Rechnung gestellten Sicherungsspeicher als kumulativen Wert aller Sicherungsdateien. Dieser Wert wird jede Stunde an die Azure-Abrechnungspipeline gemeldet. Die Pipeline aggregiert diese stündliche Nutzung, damit der Verbrauch an Sicherungsspeicher am Ende jedes Monats berechnet werden kann.

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

Der Preis für den Sicherungsspeicher variiert. Er hängt von der von Ihnen gewählten Redundanzoption für die Sicherung und von Ihrer Region ab. Die Kosten für den Sicherungsspeicher werden auf Grundlage der verbrauchten Gigabytes pro Monat mit derselben Rate für alle Sicherungen berechnet.

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

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

Informationen zu den Preisen finden Sie auf der Seite Azure SQL Managed Instance – Preise.

Notiz

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

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

Der gesamte abrechenbare Sicherungsspeicher wird in Gigabyte pro Monat für jede Region gemäß der Rate der von Ihnen verwendeten Sicherungsspeicherredundanz in Rechnung gestellt. Der Sicherungsspeicherverbrauch ist von der Workload und der Größe der einzelnen 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.

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

Hier sehen Sie ein weiteres Beispiel. Angenommen, für dieselbe inaktive Datenbank wird der Aufbewahrungszeitraum in der Mitte des Monats von 7 Tagen auf 14 Tage erhöht. Diese Zunahme führt dazu, dass sich der gesamte Sicherungsspeicher auf 1.488 GB verdoppelt. SQL Managed Instance meldet eine Nutzung von 1 GB für die Stunden 1 bis 372 (die erste Monatshälfte). Die Nutzung wird als 2 GB für die Stunden 373 bis 744 (die zweite Monatshälfte) gemeldet. Die monatliche Schlussrechnung basiert dann auf dem aggregierten Wert von 1.116 GB pro Monat. Aufbewahrungskosten werden nicht sofort erhöht. Sie erhöhen sich allmählich jeden Tag, da die Sicherungen zunehmen, bis sie die maximale Aufbewahrungsdauer von 14 Tagen erreichen.

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

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

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

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

Um die Größe aller differenziellen Sicherungen zu reduzieren, werden übermäßig große differenzielle Sicherungen, die 750 GB überschreiten und eine Größe von 75 % der Datenbankgröße erreichen, zu vollständigen Sicherungen hochgestuft, wenn die letzte vollständige Sicherung vor mehr als 24 Stunden durchgeführt wurde.

Überwachen der Kosten

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

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

  2. Wählen Sie in der Dropdownliste die verwaltete SQL-Instanz für eine verwaltete Instanz aus.

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

  4. Zum Überwachen der PITR-Sicherungskosten wählen Sie in der Dropdownliste PITR-Sicherungsspeicher für verwaltete Instanzen aus. Die Zähler werden nur angezeigt, wenn ein Backup-Speicherverbrauch besteht.

    Zum Überwachen der LTR-Sicherungskosten wählen Sie in der Dropdownliste LTR-Sicherungsspeicher für SQL Managed Instance aus. Die Zähler werden nur angezeigt, wenn ein Backup-Speicherverbrauch besteht.

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

Screenshot that shows an analysis of backup storage costs.

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 Zeitpunktwiederherstellungs- oder LTR-Sicherungsspeicher nicht genutzt wird, werden diese Verbrauchseinheiten nicht angezeigt.

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 mit SQL Managed Instance.

Sicherungsintegrität

Alle Datenbanksicherungen werden mit der Option „CHECKSUM“ erstellt, um eine zusätzliche Sicherungsintegrität zu gewährleisten. Das automatische Testen von automatischen Sicherungen von Datenbanken durch das Azure SQL-Entwicklungsteam ist derzeit nicht für Azure SQL Managed Instance verfügbar. Planen Sie die Wiederherstellungen von Testsicherungen, und führen Sie DBCC CHECKDB für Ihre Datenbanken in SQL Managed Instance rund um Ihre Workload aus.

Obwohl das System die Integrität von Sicherungen nicht überprüft, gibt es einen integrierten Schutz Ihrer Sicherungen, über den Microsoft benachrichtigt wird, wenn ein Problem mit dem Sicherungsdienst vorliegt. Darüber hinaus unterstützt Microsoft Sie, wenn ein Problem mit einer Sicherung auftritt, z. B. wenn eine vollständige Sicherung nicht ausgeführt wird, der Sicherungsdienst hängen bleibt, eine Protokollsicherung nicht der SLA entspricht oder die Sicherungshardware oder -software beschädigt ist.

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

Wenn Sie Datenresidenzanforderungen 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 Managed Instance mithilfe von Azure Policy durchsetzen.

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

Integrierte Richtlinien für die Redundanz des Sicherungsspeichers

Zum Durchsetzen von Datenresidenzanforderungen auf Organisationsebene können Sie einer Subscription Richtlinien zuweisen, indem Sie das Azure-Portal oder Azure PowerShell verwenden. Wenn Sie z. B. die folgende integrierte Richtlinie auf Subscription- oder Ressourcengruppenebene zuweisen, können Benutzer in der Subscription keine verwaltete Instanz mit georedundantem Sicherungsspeicher über das Azure-Portal oder Azure PowerShell erstellen: Verwendung von GRS-Sicherungsredundanz für SQL Managed Instance-Instanzen vermeiden.

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

Wichtig

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

Compliance

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.

Notiz

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

Nächste Schritte