Automatisierte Sicherungen in Azure SQL-Datenbank

Gilt für:Azure SQL-Datenbank

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

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

Was ist eine Datenbanksicherung?

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

Für andere Dienstebenen als Hyperscale verwendet Azure SQL-Datenbank die SQL Server-Modultechnologie zum Sichern und Wiederherstellen von Daten. Hyperscale-Datenbanken verwenden Sicherung und Wiederherstellung basierend auf Speichermomentaufnahmen. Mit traditioneller SQL Server-Backup-Technologie haben größere Datenbanken lange Backup- und Wiederherstellungszeiten. Durch die Verwendung von Snapshots bietet Hyperscale sofortiges Backup und schnelle Wiederherstellungsmöglichkeiten, unabhängig von der Datenbankgröße. Weitere Informationen finden Sie unter Hyperscale-Sicherungen.

Sicherungshäufigkeit

Azure SQL-Datenbank erstellt Folgendes:

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

Die genaue Häufigkeit der Sicherungen von Transaktionsprotokollen hängt von der Rechengröße und dem Umfang der Datenbankaktivität ab. Wenn Sie eine Datenbank wiederherstellen, bestimmt die Azure SQL-Datenbank, welche vollständigen, differenziellen und Transaktionsprotokoll-Backups wiederhergestellt werden sollen.

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

Redundanz für Sicherungsspeicher

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

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

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

• Wenn Sie die Entwicklungsworkloadumgebung auswählen, wird die Option Speicherredundanz sichern auf die Verwendung lokal redundanter Speicher festgelegt. Lokal redundanter Speicher verursacht weniger Kosten und ist für Vorproduktionsumgebungen geeignet, die nicht die Redundanz von zonen- oder georepliziertem Speicher benötigen.
• Wenn Sie die Produktionsworkloadumgebung auswählen, wird die Sicherungsspeicherredundanz auf georedundanten Speicher festgelegt, der Standardwert.
• Die Option Arbeitslastumgebung ändert ebenfalls die Anfangseinstellung für Compute, wobei man diese Einstellung überschreiben kann. Andernfalls hat die Workload-Umgebungsoption keine Auswirkungen auf die Lizenzierung oder andere Datenbankkonfigurationseinstellungen.

Um sicherzustellen, dass Ihre Backups in derselben Region bleiben, in der Ihre Datenbank bereitgestellt wird, ändern Sie die Redundanz des Backup-Speichers vom standardmäßigen georedundanten Speicher auf andere Speichertypen, die Ihre Daten innerhalb der Region halten. Die konfigurierte Sicherungsspeicherredundanz wird sowohl auf kurzfristige Aufbewahrungssicherungen (STR) als auch auf LTR-Sicherungen angewendet. Weitere Informationen zur Speicherredundanz finden Sie unter Datenredundanz.

Du kannst die Redundanz für Backup-Speicher konfigurieren, wenn du deine Datenbank erstellst, und du kannst sie später aktualisieren. Änderungen, die Sie an einer bestehenden Datenbank vornehmen, gelten nur für zukünftige Backups. Nachdem Sie Sicherungsspeicherredundanz einer vorhandenen Datenbank aktualisiert haben, kann es bis zu 48 Stunden dauern, bis die Änderungen angewendet werden.

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

• Lokal redundanter Speicher (LRS): Die Sicherungen werden dreimal synchron innerhalb eines einzelnen physischen Standorts in der primären Region kopiert. LRS ist die günstigste Speicheroption, wird aber nicht für Anwendungen empfohlen, die Widerstandsfähigkeit gegenüber regionalen Ausfällen oder eine Garantie hoher Datenbeständigkeit benötigen.

  

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

  

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

  Das Ergebnis ist:

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

  

• Geo-Zonenredundanter Speicher (GZRS): Geo-Zonenredundanter Speicher (GZRS) kombiniert die hohe Verfügbarkeit, die durch Redundanz über Verfügbarkeitszonen (ZRS) bereitgestellt wird, mit dem Schutz vor regionalen Ausfällen, der von der Georeplikation (GRS) bereitgestellt wird. In GZRS kopiert Azure Ihre Backups synchron über drei Azure-Verfügbarkeitszonen in der primären Region und asynchron dreimal an einen einzelnen physischen Standort in der gepaarten sekundären Region.

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

  Das Ergebnis ist:

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

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

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

  

Sicherungsverwendung

Verwenden Sie automatisch erstellte Backups in den folgenden Szenarien:

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

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

• Wiederherstellen einer gelöschten Datenbank zu einem bestimmten Zeitpunkt innerhalb des Aufbewahrungszeitraums, einschließlich des Zeitpunkts der Löschung. Du kannst die gelöschte Datenbank nur auf demselben Server wiederherstellen, auf dem du die ursprüngliche Datenbank erstellt hast. Bevor Sie eine Datenbank löschen, macht die Azure SQL-Datenbank ein finales Transaktionsprotokoll-Backup, um Datenverluste zu vermeiden.

• Wiederherstellen einer Datenbank in einer anderen geografischen Region. Geo-Restore hilft Ihnen, sich von einem regionalen Ausfall zu erholen, wenn Sie weder auf Ihre Datenbank noch Backups in der Hauptregion Zugriff haben. Dabei wird eine neue Datenbank auf einem beliebigen vorhandenen Server in einer beliebigen Azure-Region erstellt.

  Wichtig

  Die Geowiederherstellung ist nur für Datenbanken verfügbar, die mit georedundantem Sicherungsspeicher konfiguriert wurden. Wenn Sie derzeit keine geo-replizierten Backups für eine Datenbank verwenden, können Sie diese Einstellung ändern, indem Sie die Redundanz für Backup-Speicher konfigurieren.

• Stellen Sie eine Datenbank aus einem bestimmten Langzeit-Backup einer einzelnen oder Pool-Datenbank wieder her, sofern die Datenbank mit einer LTR-Richtlinie konfiguriert ist. Mit LTR können Sie eine ältere Version der Datenbank wiederherstellen, indem Sie das Azure-Portal, die Azure CLI oder Azure PowerShell verwenden, um eine Konformitätsanforderung zu erfüllen oder eine ältere Version der Anwendung auszuführen. Weitere Informationen finden Sie unter Langfristige Aufbewahrung.

Automatische Sicherungen auf sekundären Replikaten

Die Business Critical-Service-Stufe übernimmt automatische Backups von einer sekundären Replik. Da die Daten zwischen SQL Server-Prozessen auf jedem Knoten repliziert werden, erstellt der Sicherungsdienst die Sicherung aus den nicht lesbaren sekundären Replikaten. Mit diesem Design wird sichergestellt, dass das primäre Replikat Ihrer Hauptworkload zugeordnet bleibt und das lesbare sekundäre Replikat schreibgeschützten Workloads zugeordnet ist. Automatische Sicherungen werden auf der Dienstebene „Unternehmenskritisch“ zumeist aus einem sekundären Replikat erstellt. Wenn ein automatisches Backup bei einer sekundären Replik fehlschlägt, übernimmt der Backup-Service das Backup von der primären Replik.

Automatische Sicherungen auf sekundären Replikaten:

• Sind standardmäßig aktiviert.
• Sie sind ohne zusätzliche Kosten über den Preis der Servicestufe hinaus enthalten.
• Verbessern Sie die Leistung und Vorhersehbarkeit der Dienstebene „Unternehmenskritisch“.

Wiederherstellung von Fähigkeiten und Funktionen

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

Informationen zu Wiederherstellungszeiten finden Sie unter RTO und RPO.

¹ Verwenden Sie für unternehmenskritische Anwendungen, die große Datenbanken erfordern und die Geschäftskontinuität sicherstellen müssen, Failovergruppen.
² Alle PITR-Sicherungen werden standardmäßig in georedundantem Speicher gespeichert, daher ist die Geowiederherstellung standardmäßig aktiviert.
³ Die Problemumgehung besteht darin, auf einem neuen Server wiederherzustellen und Ressourcenverschiebung zu verwenden, um den Server in ein anderes Abonnement zu verschieben, oder Sie verwenden eine abonnementübergreifende Datenbankkopie.

Wiederherstellen einer Datenbank aus einer Sicherung

Für weitere Informationen zur Wiederherstellung einer Datenbank siehe Datenbank wiederherstellen aus Backups. Um Backup-Konfigurationen und Wiederherstellungsoperationen zu erkunden, verwenden Sie die folgenden Beispiele.

Exportieren einer Datenbank

Du kannst keine automatischen Backups, die vom Azure-Dienst gemacht werden, herunterladen oder direkt darauf zugreifen. Azure verwendet diese Backups nur für Wiederherstellungsoperationen.

Um eine Azure SQL-Datenbank zu exportieren, sollten Sie andere Alternativen in Betracht ziehen.

• Wenn Sie eine Datenbank exportieren müssen, um zu archivieren oder auf eine andere Plattform zu wechseln, exportieren Sie das Datenbankschema und die Daten in eine BACPAC-Datei . Eine BACPAC-Datei ist eine ZIP-Datei mit der Erweiterung BACPAC. Sie enthält die Metadaten und Daten aus der Datenbank. Man kann eine BACPAC-Datei im Azure Blob-Speicher oder im lokalen Speicher an einem lokalen Standort speichern. Später kannst du es wieder in Azure SQL-Datenbank, Azure SQL Managed Instance oder eine SQL Server-Instanz importieren.
• Außerdem können Sie eine Azure SQL-Datenbank über eine private Verbindung importieren oder exportieren oder eine Azure SQL-Datenbank importieren oder exportieren, ohne Azure-Diensten Zugriff auf den Server zu erlauben.

Sicherungsplanung

Das erste vollständige Backup wird direkt nach der Erstellung oder Wiederherstellung einer neuen Datenbank geplant. Diese Sicherung wird normalerweise innerhalb von 30 Minuten abgeschlossen, kann aber länger dauern, wenn die Datenbank groß ist. Zum Beispiel kann das erste Backup bei einer wiederhergestellten Datenbank oder einer Datenbankkopie länger dauern.

Nach dem ersten vollständigen Backup plant und verwaltet Azure automatisch alle weiteren Backups. Der SQL-Datenbankdienst bestimmt den genauen Zeitpunkt aller Datenbank-Backups, während er die gesamte Systemlast ausbalanciert. Sie können den Zeitplan der Sicherungsaufträge nicht ändern oder sie deaktivieren.

Sicherungsspeicherverbrauch

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

Bei Azure SQL-Datenbank ist wöchentlich eine vollständige Sicherung geplant. Um PITR innerhalb der gesamten Aufbewahrungszeit bereitzustellen, muss Azure zusätzliche vollständige, differenzielle und Transaktionsprotokoll-Backups bis zu einer Woche länger als die konfigurierte Aufbewahrungszeit speichern.

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

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

Azure löscht automatisch Backups, die nicht mehr benötigt werden, um PITR-Funktionalität bereitzustellen. Da unterschiedliche Backups und Log-Backups ein früheres vollständiges Backup erfordern, um wiederherstellbar zu sein, löscht Azure alle drei Backup-Typen zusammen in wöchentlichen Sätzen.

Für alle Datenbanken, einschließlich TDE-verschlüsselter Datenbanken, komprimiert Azure alle vollständigen und differenziellen Backups, um die Kompression und Kosten des Backup-Speichers zu reduzieren. Das durchschnittliche Backup-Kompressionsverhältnis beträgt drei- bis vierfach. Dieses kann jedoch je nach Art der Daten und der Verwendung der Datenkomprimierung in der Datenbank niedriger oder höher ausfallen.

Azure SQL-Datenbank berechnet den gesamten Sicherungsspeicher als kumulativen Wert. Jede Stunde meldet Azure diesen Wert an die Abrechnungspipeline. Die Pipeline ist dafür verantwortlich, diese stündliche Nutzung zu aggregieren, um Ihren Verbrauch am Ende jedes Monats zu berechnen. Nachdem du eine Datenbank gelöscht hast, nimmt der Verbrauch ab, da die Backups altern und gelöscht werden. Wenn alle Sicherungen gelöscht wurden und keine Zeitpunktwiederherstellung mehr möglich ist, endet die Abrechnung.

Überwachen des Verbrauchs

Für vCore-Datenbanken in Azure SQL-Datenbank meldet der Datenbanküberwachungsbereich den Speicher, den jede Art von Backup (vollständig, differentiell und logistisch) als separate Metrik verbraucht. Der folgende Screenshot zeigt, wie Sie den Sicherungsspeicherverbrauch für eine Einzeldatenbank überwachen.

Anweisungen, wie Sie den Verbrauch in Hyperscale überwachen, finden Sie unter Überwachen des Hyperscale-Sicherungsverbrauchs.

Optimieren des Sicherungsspeicherverbrauchs

Ihnen werden für die Backupspeichernutzung bis zur maximalen Datenmenge einer Datenbank keine Kosten berechnet. Um Ihren Speicherverbrauch für Backups zu reduzieren, können Sie einige der folgenden Optimierungstechniken in Betracht ziehen:

• Reduzieren Sie den Aufbewahrungszeitraum für Sicherungen auf die Mindestanforderungen für Ihre Zwecke.
• Vermeiden Sie, große Schreibvorgänge, wie etwa die Neuerstellung von Indizes, häufiger als nötig durchzuführen.
• Bei umfangreichen Datenladevorgängen sollten Sie gruppierte Columnstore-Indizes verwenden und die entsprechenden Best Practices befolgen. Erwägen Sie auch, die Anzahl der nicht gruppierten Indizes zu verringern.
• Auf der Dienstebene „Universell“ ist der bereitgestellte Datenspeicher günstiger als die Kosten für den Sicherungsspeicher. Wenn Sie dauerhaft hohe zusätzliche Backup-Speicherkosten haben, sollten Sie in Erwägung ziehen, die Datenspeicherkapazität zu erhöhen, um Backup-Speicherkosten zu senken.
• 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).

Aufbewahrung der Sicherung

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

Kurzfristige Aufbewahrung

Für alle neuen, wiederhergestellten und kopierten Datenbanken speichert die Azure SQL-Datenbank standardmäßig genügend Backups, um PITR innerhalb der letzten sieben Tage zu ermöglichen. Azure SQL-Datenbank macht regelmäßige vollständige, differentielle und Log-Backups, um sicherzustellen, dass Datenbanken zu jedem Zeitpunkt innerhalb der Aufbewahrungszeit wiederherstellbar sind.

Du kannst unterschiedliche Backups so konfigurieren, dass sie entweder alle 12 Stunden oder einmal alle 24 Stunden stattfinden. Eine differenzielle Sicherungshäufigkeit von 24 Stunden kann die für die Wiederherstellung der Datenbank erforderliche Zeit im Vergleich zur 12-Stunden-Häufigkeit möglicherweise erhöhen. Im virtuellen Kernmodell liegt die Standardhäufigkeit für differenzielle Sicherungen bei einmal in 12 Stunden. Im DTU-Modell liegt die Standardhäufigkeit bei einmal in 24 Stunden.

Du kannst deine Redundanzoption für Backup-Speicher für STR angeben, wenn du deine Datenbank erstellst, und sie später ändern. Wenn Sie Ihre Backup-Redundanz-Option in einer bestehenden Datenbank ändern, verwenden neue Backups die neue Redundanz-Option. Azure bewegt oder kopiert keine Sicherungskopien, die mit der vorherigen kurzfristigen Redundanzoption erstellt wurden. Azure lässt sie im ursprünglichen Speicherkonto, bis die Aufbewahrungsfrist abläuft, was 1 bis 35 Tage betragen kann.

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

Wenn Sie eine Datenbank löschen, bewahrt Azure Backups auf die gleiche Weise für eine Online-Datenbank mit ihrer spezifischen Aufbewahrungsfrist auf. Der Aufbewahrungszeitraum für eine gelöschte Datenbank kann nicht geändert werden.

Langfristige Aufbewahrung

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

Um verschiedene Compliance-Anforderungen zu erfüllen, wählen Sie verschiedene Aufbewahrungsperioden für wöchentliche, monatliche und jährliche vollständige Backups aus. Die Häufigkeit hängt von der Richtlinie ab. Beispielsweise wird durch Festlegen von W=0, M=1 monatlich eine LTR-Kopie erstellt. Weitere Informationen zu LTR finden Sie unter Langfristige Aufbewahrung.

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

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

Bei der Wiederherstellung einer Hyperscale-Datenbank aus einem LTR-Backup wird die Leseskalierungseigenschaft deaktiviert. Um die Leseskalierung auf der wiederhergestellten Datenbank zu aktivieren, aktualisieren Sie die Datenbank, nachdem sie erstellt wurde. Sie müssen das Ziel der Dienstebene angeben, wenn Sie eine LTR-Sicherung wiederherstellen.

Sie können die langfristige Aufbewahrung für Hyperscale-Datenbanken aktivieren, die von anderen Service-Stufen erstellt oder migriert wurden. Wenn Sie versuchen, LTR für eine Hyperscale-Datenbank zu aktivieren, die noch nicht unterstützt wird, erhalten Sie folgende Fehlermeldung: "Bei der Aktivierung der langfristigen Sicherungsaufbewahrung für diese Datenbank ist ein Fehler aufgetreten. Bitte wenden Sie sich an den Microsoft-Support, um eine langfristige Backup-Retention zu ermöglichen." In diesem Fall wenden Sie sich an den Microsoft-Support und erstellen Sie ein Support-Ticket, um das zu klären.

Kosten von Sicherungsspeicher

Der Preis für Sicherungsspeicher variiert und ist abhängig von Ihrem Kaufmodell (DTU oder virtueller Kern), der ausgewählten Option für die Sicherungsspeicherredundanz und Ihrer Region. Du zahlst für Backup-Speicher basierend auf den monatlich verbrauchten Gigabytes, zum gleichen Preis für alle Backups.

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

DTU-Modell

Im DTU-Modell gibt es für Datenbanken und elastische Pools keine zusätzliche Gebühr für PITR-Backup-Speicher bei einer Standardaufbewahrung von sieben Tagen und mehr. Der Preis für PITR-Backup-Speicher ist Teil des Preises der Datenbank oder des Pools.

Im DTU-Modell zahlt man für den LTR-Backup-Speicher für Datenbanken und elastische Pools, basierend auf dem tatsächlichen Speicher, den LTR-Backups verbrauchen.

vCore-Modell

Azure SQL-Datenbank berechnet Ihren gesamten abrechenbaren Sicherungsspeicher als kumulierten Wert über alle Sicherungsdateien hinweg. Jede Stunde sendet Azure diesen Wert an die Abrechnungspipeline. Die Pipeline aggregiert diesen stündlichen Verbrauch, um Ihren Backup-Speicherverbrauch am Ende jedes Monats zu bestimmen.

Wenn du eine Datenbank löschst, nimmt der Speicherverbrauch der Backups allmählich ab, da ältere Backups altern und gelöscht werden. Da unterschiedliche Backups und Log-Backups ein früheres vollständiges Backup erfordern, um wiederherstellbar zu sein, löscht Azure alle drei Backup-Typen zusammen in wöchentlichen Sätzen. Nachdem alle Sicherungen gelöscht wurden, endet die Abrechnung.

Hyperscale-Datenbanken verwenden eine andere Methode zur Berechnung der Backup-Speicherkosten. Weitere Informationen finden Sie unter Kosten des Hyperscale-Sicherungsspeichers.

Für einzelne Datenbanken erhält man eine Backup-Speichermenge in Höhe der maximalen Speichergröße der Datenbank ohne zusätzliche Kosten. Die folgende Gleichung berechnet den gesamten abrechenbaren Backup-Speicherverbrauch:

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

Bei elastischen Pools erhält man eine Backup-Speichermenge in Höhe des maximalen Datenspeichers für die Speichergröße des Pools, ohne zusätzliche Kosten. Für gepoolte Datenbanken wird die Gesamtgröße des abrechenbaren Sicherungsspeichers auf Poolebene aggregiert und wie folgt berechnet:

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

Sie zahlen gegebenenfalls für die gesamte abgerechnete Sicherungsspeicherkapazität in Gigabyte pro Monat gemäß der Redundanz des Sicherungsspeichers. Der Sicherungsspeicherverbrauch ist von der Workload und der Größe der einzelnen Datenbanken, der Pools für elastische Datenbanken und verwalteten Instanzen abhängig. Datenbanken mit vielen Änderungen weisen größere differenzielle Sicherungen und Protokollsicherungen auf, da die Größe dieser Sicherungen proportional zur Menge der geänderten Daten ist. Daher fallen für solche Datenbanken höhere Backup-Gebühren an.

Als vereinfachtes Beispiel nehmen wir an, dass eine Datenbank 744 GB Backup-Speicher ansammelt und diese Menge einen ganzen Monat lang konstant bleibt, weil die Datenbank völlig ungenutzt ist. Um diesen kumulativen Speicherverbrauch in eine stündliche Nutzung umzurechnen, dividieren Sie ihn durch 744,0 (31 Tage pro Monat x 24 Stunden pro Tag). SQL Database meldet der Azure-Abrechnungspipeline, dass die Datenbank stündlich 1 GB PITR-Backup verbraucht hat, und zwar mit einer konstanten Rate. Azure-Abrechnung aggregiert diesen Verbrauch und zeigt eine Nutzung von 744 GB für den gesamten Monat 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 Database meldet 1 GB Nutzung für die Stunden 1 bis 372 (die erste Hälfte des Monats). Es gibt die Nutzung für die Stunden 373 bis 744 (zweite Monatshälfte) mit 2 GB an. Dieser Verbrauch summiert sich auf eine Endabrechnung von 1.116 GB pro Monat.

Die tatsächlichen Abrechnungsszenarien für Sicherungen sind komplexer. Da die Änderungsrate in der Datenbank von der Arbeitslast abhängt und zeitlich variabel ist, variiert auch die Größe jedes Differential- und Log-Backups. 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 Modifikationen, die der Index-Rebuild vornimmt, sind enthalten:

• 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.

Für das letzte Szenario in größeren Datenbanken erstellt eine Optimierung in Azure ein vollständiges Backup statt eines differenziellen Backups, falls ein differenziertes Backup sonst zu groß wäre. Diese Optimierung reduziert die Größe aller differenziellen Backups bis zum folgenden vollständigen Backup.

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

Überwachen der Kosten

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

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

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

3. Fügen Sie einen weiteren Filter für Zählerunterkategorie hinzu.

4. Zur Überwachung der Kosten von PITR-Sicherungen wählen Sie in der Dropdown-Liste PITR-Sicherungsspeicher für eine einzelne Datenbank oder einen elastischen Datenbankpool aus. Verbrauchseinheiten werden nur angezeigt, wenn der Sicherungsspeicherverbrauch vorhanden ist.

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

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

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

Verschlüsselte Sicherungen

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

Sicherungsintegrität

Die Azure SQL-Datenbank behandelt bestimmte Arten von Datenkorruption automatisch, indem sie bei Bedarf integrierte Techniken verwendet, ohne Datenverlust. In Azure SQL-Datenbank führt die SQL Datenbank-Engine während der Service-Managed Backups und bei jeder Wiederherstellungsoperation Seitenverifikationen durch. Mögliche Probleme, die bei einer Integritätsprüfung gefunden werden, führen zu einer Warnung des Entwicklungsteams.

Als zusätzliche Schutzebene können Sie die Wiederherstellung von Backups testen und Integritätsprüfungen durchführen. Weitere Informationen finden Sie unter Data Integrity in Azure SQL-Datenbank.

Alle Datenbank-Backups nutzen die CHECKSUM Option, zusätzliche Backup-Integrität zu gewährleisten.

Backup-Schutz

Microsoft-eigene Azure-Abonnements verwalten Azure SQL-Datenbank-Backups mithilfe sicherer, interner Azure Storage-Konten. Man kann diese Backups nicht extern nutzen, daher bieten sie eine starke Datenisolation und einen starken Schutz. Innerhalb von Microsoft können nur Backend-Dienste auf diese Backups zugreifen, diese erstellen, kopieren oder wiederherstellen. Microsoft-Techniker, einschließlich Entwicklern, haben keinen ständigen Zugriff. Um die Gefährdung zu minimieren und die Sicherheit zu maximieren, kann Microsoft nur just-In-Time (JIT)-Zugriff unter strengen Überwachungskontrollen erhalten, wenn dies für die Behandlung bestimmter Kundenprobleme unbedingt erforderlich ist.

Backups werden automatisch gelöscht, sobald die Aufbewahrungsfrist abgelaufen ist.

Einhaltung durch Aufbewahrung von Sicherungskopien

Wenn die Standard-Aufbewahrung nicht Ihren Compliance-Anforderungen entspricht, ändern Sie die PITR-Aufbewahrungsfrist. Weitere Informationen finden Sie unter Ändern des PITR-Sicherungsaufbewahrungszeitraums.

Wenn Sie Ihre Datenbank von einem DTU-basierten Diensttarif in einen vCore-basierten Diensttarif migrieren, bleibt die PITR-Aufbewahrungsdauer erhalten, damit die Datenwiederherstellungsrichtlinie Ihrer Anwendung nicht beeinträchtigt wird.

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

Wenn Sie Datenresidenzanforderungen haben, die erfordern, dass Sie alle Ihre Daten in einer einzigen Azure-Region speichern, können Sie zonenredundante oder lokal redundante Backups für Ihre SQL-Datenbank mit 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, diese Ressourcen konform mit Ihren Unternehmensstandards und Service-Level-Vereinbarungen zu halten. Weitere Informationen finden Sie in der Übersicht über Azure Policy.

Integrierte Richtlinien zur Redundanz von Backup-Speichern

Um Datenresidenzanforderungen auf Organisationsebene durchzusetzen, weisen Sie Richtlinien einem Abonnement zu, indem Sie das Azure-Portal oder Azure PowerShell verwenden.

Wenn Sie beispielsweise die Richtlinie "Azure SQL DB should avoid using GRS backup" aktivieren, können Benutzer keine Datenbanken erstellen, deren Standardspeicher auf global redundanten Speicher festgelegt ist. Die Richtlinie verhindert, dass Benutzer GRS verwenden, und gibt die Fehlermeldung zurück: "Konfiguration des Backup-Speicherkontotyps auf 'Standard_RAGRS' während Datenbankerstellung oder -aktualisierung fehlgeschlagen."

Eine vollständige Liste der integrierten Richtliniendefinitionen für SQL Database finden Sie in der Richtlinienreferenz.

Zugehöriger Inhalt

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