Sicherung und Wiederherstellung in Azure Database for PostgreSQL Flexible Server

Sicherungen sind ein wesentlicher Bestandteil jeder Geschäftskontinuitätsstrategie. Sie tragen zum Schutz von Daten vor versehentlicher Beschädigung oder Löschung bei.

Azure Database for PostgreSQL führt automatisch regelmäßige Sicherungen Ihres Servers durch. Sie können dann eine Zeitpunktwiederherstellung innerhalb eines Aufbewahrungszeitraums durchführen, den Sie festlegen können. Die Gesamtzeit für die Wiederherstellung und Recovery hängt in der Regel von der Datenmenge und dem Umfang der durchzuführenden Wiederherstellung ab.

Übersicht über Azure Backup

Azure Database for PostgreSQL übernimmt Momentaufnahmesicherungen von Datendateien und speichert sie je nach Region sicher in zonenredundanten Speicher oder lokal redundantem Speicher. Der Server sichert auch Transaktionsprotokolle, wenn die WAL-Datei (Write-Ahead Log) für die Archivierung bereit ist. Verwenden Sie diese Sicherungen, um einen Server zu einem beliebigen Zeitpunkt innerhalb des konfigurierten Aufbewahrungszeitraums für die Sicherung wiederherzustellen.

Der standardmäßige Aufbewahrungszeitraum für die Sicherung beträgt sieben Tage, Sie können den Zeitraum jedoch auf maximal 35 Tage verlängern. Alle Sicherungen werden mithilfe der AES 256-Bit-Verschlüsselung für die ruhenden Daten verschlüsselt.

Sie können diese Sicherungsdateien nicht exportieren oder verwenden, um Server außerhalb Ihrer Azure Database for PostgreSQL flexiblen Serverinstanz zu erstellen. Zu diesem Zweck können Sie PostgreSQL-Tools pg_dump und pg_restore/psql verwenden.

Sicherungshäufigkeit

Sicherungen in Azure Database for PostgreSQL – Flexibler Server basieren auf Momentaufnahmen. Die erste Momentaufnahmensicherung ist für unmittelbar nach Erstellung des Servers geplant. Momentaufnahmesicherungen werden derzeit einmal täglich erstellt. Wenn Sie nach der letzten Snapshot-Sicherung keine weiteren Änderungen an Datenbanken auf dem Server vornehmen, setzt das System Snapshot-Sicherungen vorübergehend aus. Sobald Sie eine Datenbank auf dem Server ändern, nimmt das System sofort eine neue Momentaufnahme ein, um die neuesten Änderungen zu erfassen. Die erste Momentaufnahme ist eine vollständige Sicherung und aufeinander folgende Momentaufnahmen sind differenzielle Sicherungen.

Transaktionsprotokollsicherungen erfolgen mit unterschiedlicher Häufigkeit, abhängig von der Workload und dem Zeitpunkt, zu dem die WAL-Datei gefüllt wird und für die Archivierung bereit ist. Im Allgemeinen kann das Verzögerungs-RPO (Wiederherstellungspunktziel) bis zu fünf Minuten betragen.

Optionen für Sicherungsredundanz

Azure Database for PostgreSQL speichert mehrere Kopien Ihrer Sicherungen, um Ihre Daten vor geplanten und ungeplanten Ereignissen zu schützen. Zu diesen Ereignissen können vorübergehende Hardwarefehler, Netzwerk- oder Stromausfälle sowie Naturkatastrophen gehören. Die Sicherungsredundanz stellt sicher, dass Ihre Datenbank ihre Verfügbarkeits- und Dauerhaftigkeitsziele auch bei Ausfällen erfüllt.

Azure Database for PostgreSQL bietet drei Optionen:

  • Zonenredundanter Sicherungsspeicher: Azure Database for PostgreSQL wählt diese Option automatisch für Regionen aus, die Verfügbarkeitszonen unterstützen. Wenn Sie Sicherungen im zonenredundanten Sicherungsspeicher speichern, speichert der Dienst drei Kopien der Daten innerhalb der Verfügbarkeitszone, in der Ihr Server gehostet wird. Darüber hinaus repliziert der Dienst die Daten in eine andere Verfügbarkeitszone zum zusätzlichen Schutz.

    Diese Option stellt die Verfügbarkeit von Sicherungsdaten über Verfügbarkeitszonen hinweg bereit und schränkt die Replikation von Daten in ein Land oder eine Region ein, um die Datenaufbewahrungsanforderungen zu erfüllen. Es bietet über ein Jahr hinweg eine Dauerhaftigkeit von mindestens 99,9999999999 Prozent (12 Neunen) für Backup-Objekte.

  • Lokal redundanter Sicherungsspeicher: Azure Database for PostgreSQL wählt diese Option automatisch für Regionen aus, die noch keine Verfügbarkeitszonen unterstützen. Wenn Sie Sicherungen im lokal redundanten Sicherungsspeicher speichern, speichert der Dienst mehrere Kopien von Sicherungen im selben Rechenzentrum.

    Diese Option trägt zum Schutz Ihrer Daten vor Serverrack- und Laufwerkfehlern bei. Sie bietet eine Dauerhaftigkeit der Sicherungsobjekte von mindestens 99,999999999 Prozent (11 Neunen) für die Dauer eines Jahres.

    Standardmäßig legt der Dienst den Sicherungsspeicher für Server mit Hochverfügbarkeit (HA) in derselben Zone oder ohne Hochverfügbarkeitskonfiguration auf lokal redundanten Speicher fest.

  • Georedundanter Sicherungsspeicher: Sie können diese Option zum Zeitpunkt der Servererstellung auswählen. Wenn Sie Sicherungen im georedundanten Sicherungsspeicher speichern, repliziert der Dienst zusätzlich zu drei Kopien von Daten, die in der Region gespeichert sind, in der Ihr Server gehostet wird, die Daten in eine geo-gekoppelte Region.

    Diese Option ermöglicht in einem Notfall die Wiederherstellung Ihres Servers in einer anderen Region. Sie bietet zudem eine Dauerhaftigkeit der Sicherungsobjekte von mindestens 99,99999999999999 Prozent (16 Neunen) für die Dauer eines Jahres.

    Georedundanz wird für Server unterstützt, die in einer der azure-gekoppelten Regionen gehostet werden.

Umstieg von anderen Sicherungsspeicheroptionen auf georedundanten Sicherungsspeicher

Georedundanter Speicher kann nur während der Erstellung eines Servers für die Sicherung konfiguriert werden. Nach der Bereitstellung eines Servers kann die Redundanzoption für den Sicherungsspeicher nicht mehr geändert werden.

Aufbewahrung der Sicherung

Der Server behält Sicherungen basierend auf dem von Ihnen festgelegten Aufbewahrungszeitraum bei. Sie können einen Aufbewahrungszeitraum von 7 bis 35 Tagen (Standardeinstellung) auswählen. Legen Sie den Aufbewahrungszeitraum während der Servererstellung fest, oder ändern Sie ihn später. Der Server behält Sicherungen auch für beendete Server bei.

Der Aufbewahrungszeitraum von Backups legt den Zeitraum fest, innerhalb dessen eine Point-in-Time-Wiederherstellung (PITR) aus den verfügbaren Backups durchgeführt werden kann. Sie können den Sicherungsaufbewahrungszeitraum auch als Wiederherstellungsfenster im Hinblick auf eine Wiederherstellung betrachten.

Der Sicherungsspeicher behält alle Sicherungen bei, die zum Ausführen eines PITR innerhalb des Sicherungsaufbewahrungszeitraums erforderlich sind. Wenn Sie beispielsweise den Aufbewahrungszeitraum für die Sicherung auf 7 Tage festlegen, ist das Wiederherstellungsfenster die letzten 7 Tage. In diesem Szenario bewahrt der Sicherungsspeicher alle Daten und Protokolle der letzten 7 Tage auf, die erforderlich sind, um den Server wiederherzustellen und wieder in Betrieb zu nehmen.

Kosten für Sicherungsspeicher

Azure Database for PostgreSQL bietet bis zu 100 Prozent Ihres bereitgestellten Serverspeichers als Sicherungsspeicher ohne zusätzliche Kosten. Sie zahlen für zusätzlichen Sicherungsspeicher, den Sie pro Monat in Gigabyte verwenden.

Wenn Sie z. B. einen Server mit 250 gibibytes (GiB) des Speichers bereitstellen, erhalten Sie 250 GiB von Backup-Speicherkapazität ohne zusätzliche Kosten. Wenn die tägliche Sicherungsnutzung 25 GiB beträgt, können Sie bis zu 10 Tage kostenlosen Sicherungsspeicher haben. Sie zahlen für belegten Sicherungsspeicher, der 250 GiB übersteigt, gemäß dem Preismodell.

Wenn Sie Ihren Server mit georedundanter Sicherung konfigurieren, werden die Sicherungsdaten auch in die Azure gekoppelten Region kopiert. Ihre Sicherungsgröße ist also doppelt so groß wie die lokale Sicherungskopie. Die Abrechnung wird als ((2 x lokale Sicherungsgröße) - bereitgestellte Speichergröße) x Preis @ Gigabyte pro Monat berechnet.

Verwenden Sie die Metrik "Backup Storage Used" im Azure-Portal, um den Sicherungsspeicher zu überwachen, den ein Server nutzt. Die Metrik für den verwendeten Sicherungsspeicher stellt den gesamten Speicherplatz dar, der von allen Datenbank- und Protokollsicherungen beansprucht wurde, die auf Grundlage des für den Server festgelegten Aufbewahrungszeitraums für Sicherungen aufbewahrt wurden.

Hinweis

Unabhängig von der Datenbankgröße werden bei einer hohen Transaktionsaktivität auf dem Server mehr WAL-Dateien generiert. Durch die größere Anzahl von Dateien wird wiederum der Sicherungsspeicher vergrößert.

Zeitpunktwiederherstellung

In einer Flexiblen Serverinstanz von Azure Database für PostgreSQL erstellt das Ausführen eines PITR einen neuen Server in derselben Region wie Ihr Quellserver, Sie können jedoch die Verfügbarkeitszone auswählen. Bei der Erstellung wird die Konfiguration für den Tarif, die Computegeneration, Anzahl virtueller Kerne, Speichergröße, den Aufbewahrungszeitraum für Sicherungen und die Option für Sicherungsredundanz des Quellservers verwendet.

Die physischen Datenbankdateien werden zunächst aus den Momentaufnahmensicherungen am Datenspeicherort des Servers wiederhergestellt. Die entsprechende Sicherung, die vor dem gewünschten Zeitpunkt erstellt wurde, wird automatisch ausgewählt und wiederhergestellt. Anschließend wird ein Wiederherstellungsprozess unter Verwendung von WAL-Dateien eingeleitet, um die Datenbank in einen konsistenten Zustand zu bringen.

Angenommen, die Sicherungen werden nachts um 23:00 Uhr durchgeführt. Wenn der Wiederherstellungspunkt der 15. August um 10:00 Uhr ist, wird die tägliche Sicherung vom 14. August wiederhergestellt. Die Datenbank wird bis 10:00 Uhr vom 15. August mithilfe der Transaktionsprotokollsicherung vom 14. August 11:00 Uhr bis zum 15. August 10:00 Uhr wiederhergestellt.

Informationen zum Wiederherstellen des Datenbankservers finden Sie in den folgenden Themen:

Von Bedeutung

Ein Wiederherstellungsvorgang in Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL erstellt immer einen neuen Datenbankserver mit dem Namen, den Sie bereitstellen. Der vorhandene Datenbankserver wird dabei nicht überschrieben.

Die Zeitpunktwiederherstellung ist in Szenarios wie den folgenden nützlich:

  • Ein Benutzer löscht versehentlich Daten, eine Tabelle oder eine Datenbank
  • Eine Anwendung überschreibt aufgrund eines Anwendungsfehlers versehentlich gültige Daten mit ungültigen Daten.
  • Sie möchten Ihren Server zu Testzwecken, für die Entwicklung oder zur Datenüberprüfung klonen.

Mithilfe einer kontinuierlichen Sicherung von Transaktionsprotokollen können Sie die letzte Transaktion wiederherstellen. Es stehen folgende Wiederherstellungsoptionen zur Verfügung:

  • Neuester Wiederherstellungspunkt (jetzt): Dies ist die Standardoption, mit der der Server zum neuesten Zeitpunkt wiederhergestellt wird.

  • Benutzerdefinierter Wiederherstellungspunkt: Mit dieser Option können Sie einen beliebigen Zeitpunkt innerhalb des Aufbewahrungszeitraums auswählen, der für diese Instanz von Azure Database for PostgreSQL – Flexibler Server definiert ist. Standardmäßig wird der späteste Zeitpunkt in UTC automatisch ausgewählt. Die automatische Auswahl ist nützlich, wenn Sie zu Testzwecken die letzte Transaktion wiederherstellen möchten, für die ein Commit durchgeführt wurde. Sie können optional auch andere Tage und Uhrzeiten wählen.

  • Schneller Wiederherstellungspunkt: Mit dieser Option wird der Server innerhalb des für die Azure Database for PostgreSQL flexiblen Serverinstanz definierten Aufbewahrungszeitraums möglichst schnell wiederhergestellt. Die schnellste Wiederherstellung ist möglich, indem Sie direkt den Zeitstempel aus der Liste der Sicherungen auswählen. Dieser Wiederherstellungsvorgang stellt einen Server bereit und stellt lediglich die vollständige Snapshot-Sicherung wieder her. Es ist keine Wiederherstellung von Protokollen erforderlich, wodurch sie schnell wird. Wählen Sie einen Sicherungszeitstempel aus, der nach dem frühesten Wiederherstellungszeitpunkt liegt, um eine erfolgreiche Wiederherstellung durchzuführen.

Die Zeit, die zum Wiederherstellen mithilfe der neuesten und benutzerdefinierten Wiederherstellungspunktoptionen erforderlich ist, variiert je nach Faktoren wie dem Volumen der Zu verarbeitenden Transaktionsprotokolle seit der letzten Sicherung und der Gesamtzahl der Datenbanken, die gleichzeitig in derselben Region wiederhergestellt werden. Die Gesamtwiederherstellungszeit dauert in der Regel von wenigen Minuten bis zu einigen Stunden.

Wenn Sie Ihren Server in einem virtuellen Netzwerk konfigurieren, können Sie ihn im gleichen oder einem anderen virtuellen Netzwerk wiederherstellen. Sie können ihn jedoch nicht für den öffentlichen Zugriff wiederherstellen. Wenn Sie Ihren Server mit öffentlichem Zugriff konfiguriert haben, können Sie ihn nicht für den privaten VNet-Zugriff wiederherstellen.

Von Bedeutung

Sie können gelöschte Server wiederherstellen. Wenn Sie den Server löschen, befolgen Sie die Anweisungen unter "Wiederherstellen eines gelöschten Servers zum Wiederherstellen". Verwenden Sie die Azure-Ressourcensperre, um einer versehentlichen Löschung Ihres Servers vorzubeugen.

Georedundante Sicherung und Wiederherstellung

Informationen zum Aktivieren einer georedundanten Sicherung aus dem Compute + Storage-Bereich im Azure-Portal finden Sie unter Erstellen einer Azure-Datenbank für PostgreSQL.

Von Bedeutung

Sie können georedundante Sicherung nur konfigurieren, wenn Sie den Server erstellen.

Nachdem Sie Ihren Server mit georedundanter Sicherung konfiguriert haben, können Sie ihn in einer geo-gekoppelten Region wiederherstellen. Weitere Informationen finden Sie in den unterstützten Regionen für georedundante Sicherungen.

Wenn Sie den Server mit georedundanter Sicherung konfigurieren, werden die Sicherungsdaten und Transaktionsprotokolle asynchron über die Speicherreplikation in den gekoppelten Bereich kopiert. Warten Sie nach der Servererstellung mindestens eine Stunde, bevor Sie eine Geowiederherstellung initiieren. Dieser Wartezeitzeitraum ermöglicht das Replizieren der ersten Gruppe von Sicherungsdaten in den gekoppelten Bereich.

Später werden die Transaktionsprotokolle und die täglichen Sicherungen asynchron in die gekoppelte Region kopiert. Bei der Datenübertragung kann es zu einer Verzögerung von bis zu einer Stunde kommen. Daher müssen Sie bei der Wiederherstellung mit einem RPO von bis zu einer Stunde rechnen. Wiederherstellungen sind nur für die letzten verfügbaren Sicherungsdaten in der gekoppelten Region möglich. Derzeit ist PITR von georedundanten Sicherungen nicht verfügbar.

Die geschätzte Dauer für das Wiederherstellen des Server-RTO (Recovery Time Objective) hängt von Faktoren wie der Größe der Datenbank, dem Zeitpunkt der letzten Datenbanksicherung und der Menge der zu verarbeitenden WAL-Daten bis zu den zuletzt empfangenen Sicherungsdaten ab. Die gesamte Wiederherstellungsdauer beträgt normalerweise mehrere Minuten bis zu mehrere Stunden.

Während der Geowiederherstellung können Sie die Serverkonfigurationen ändern, einschließlich der Einstellungen für virtuelle Netzwerke, und die georedundante Sicherung vom wiederhergestellten Server entfernen. Das Ändern anderer Serverkonfigurationen -such als Berechnungs-, Speicher- oder Preisebene (Burstable, General Purpose oder Memory Optimized) wird während der Geowiederherstellung nicht unterstützt.

Weitere Informationen finden Sie unter "Wiederherstellung in einer gekoppelten Region (Geowiederherstellung)".

Von Bedeutung

Wenn die primäre Region ausfällt, können Sie keine georedundanten Server in der jeweiligen geografisch gekoppelten Region erstellen, da der Speicher nicht in der primären Region bereitgestellt werden kann. Sie müssen warten, bis die primäre Region verfügbar ist, um georedundante Server in der geografisch gekoppelten Region bereitstellen zu können.

Wenn die primäre Region ausfällt, können Sie für den Quellserver weiterhin Geowiederherstellungen in der geografisch gekoppelten Region ausführen. Weitere Informationen finden Sie unter "Wiederherstellung in einer gekoppelten Region (Geowiederherstellung)". Verwenden Sie Georeplikate als Notfallwiederherstellungsstrategie (DR), wenn Sie DR für eine beliebige Region konfigurieren müssen oder wenn die primäre Region georedundante Sicherungen nicht unterstützt.

Verwenden Sie virtuelle Endpunkte für ihre unternehmenskritischen Workloads, da sie einen stabilen Verbindungspunkt für Anwendungen bereitstellen, um minimale Unterbrechungen sicherzustellen. Wenn Ein virtueller Endpunkt Ihrem primären Server zugeordnet ist, entfernen Sie den virtuellen Endpunkt vom primären Server. Fügen Sie nach dem Entfernen denselben virtuellen Endpunkt zum neu erstellten Server hinzu. Durch diesen Prozess wird sichergestellt, dass die Anwendungskonnektivität konsistent bleibt und Ausfallzeiten minimiert werden. Weitere Informationen finden Sie unter verwendung virtueller Endpunkte für einen konsistenten Hostnamen während PITR.

Wiederherstellung und Netzwerk

Zeitpunktwiederherstellung

Wenn Sie Ihren Quellserver mit einem Öffentlichen Zugriffsnetzwerk konfigurieren, können Sie nur den öffentlichen Zugriff wiederherstellen.

Wenn Sie Ihren Quellserver mit einem virtuellen Netzwerk mit privatem Zugriff konfigurieren, können Sie entweder dasselbe virtuelle Netzwerk oder ein anderes virtuelles Netzwerk wiederherstellen. Sie können keine Zeitpunktwiederherstellung mit öffentlichem und privatem Zugriff gleichzeitig durchführen.

Geowiederherstellung

Wenn Sie Ihren Quellserver mit einem Öffentlichen Zugriffsnetzwerk konfigurieren, können Sie nur den öffentlichen Zugriff wiederherstellen. Außerdem müssen Sie Firewallregeln anwenden, nachdem der Wiederherstellungsvorgang abgeschlossen ist.

Wenn Sie Ihren Quellserver mit einem virtuellen Netzwerk mit privatem Zugriff konfigurieren, können Sie nur ein anderes virtuelles Netzwerk wiederherstellen, da virtuelle Netzwerke keine Regionen umfassen können. Sie können keine Geowiederherstellung mit öffentlichem und privatem Zugriff gleichzeitig durchführen.

Aufgaben nach der Wiederherstellung

Führen Sie nach dem Wiederherstellen des Servers die folgenden Aufgaben aus, um Ihre Benutzer und Anwendungen wieder betriebsbereit zu machen:

  • Wenn der neue Server den ursprünglichen Server ersetzt, leiten Sie Clients und Clientanwendungen an den neuen Server um. Ändern Sie den Servernamen Ihrer Verbindungszeichenfolge, um auf den neuen Server zu verweisen.

  • Die Werte aller Parameter auf dem ursprünglichen Server werden nicht automatisch auf den neuen Server angewendet. Stellen Sie sicher, dass Sie alle Parameter auf dem neuen Server entsprechend den Anforderungen dieses neuen Servers neu konfigurieren.

  • Stellen Sie sicher, dass geeignete Firewallregeln auf Serverebene, private Endpunkte und virtuelle Netzwerkregeln für Benutzerverbindungen eingerichtet sind. Diese Regeln werden nicht vom ursprünglichen Server kopiert.

  • Skalieren Sie die Computeressourcen des wiederhergestellten Servers nach Bedarf hoch oder herunter.

  • Stellen Sie sicher, dass geeignete Anmeldungen und Berechtigungen auf Datenbankebene vorhanden sind.

  • Konfigurieren Sie die erforderlichen Warnungen.

  • Wenn der Quellserver, aus dem Sie wiederhergestellt haben, für Hochverfügbarkeit konfiguriert war und Sie den wiederhergestellten Server für Hochverfügbarkeit konfigurieren möchten, führen Sie diese Schritte aus.

  • Wenn der Quellserver, von dem Sie wiederhergestellt haben, mit Lesereplikaten konfiguriert wurde und Sie Lesereplikate auf dem wiederhergestellten Server konfigurieren möchten, befolgen Sie die Anweisungen unter Erstellen eines Lesereplikats.

Bedarfsgesteuerte Sicherungen

Die flexible Serverinstanz Ihrer Azure-Datenbank für PostgreSQL erstellt automatisch Momentaufnahmen des Speichervolumens Ihrer gesamten Datenbankinstanz, die alle Datenbanken umfassen, im Rahmen der geplanten Backups. Darüber hinaus können Sie bei Bedarf eine On-Demand-Sicherung erstellen. Diese Option eignet sich ideal für Szenarien wie das Vorbereiten eines potenziell riskanten Vorgangs oder das Ausführen regelmäßiger Aktualisierungen außerhalb des üblichen Sicherungszeitplans.

Erstellen Sie Bedarfssicherungen zusätzlich zu geplanten automatischen Sicherungen. Das Sicherungsaufbewahrungsfenster bestimmt, wie lange diese Sicherungen beibehalten werden sollen. Sie können On-Demand-Sicherungen jederzeit löschen, wenn sie nicht mehr benötigt werden. Um eine On-Demand-Sicherung zu initiieren, wählen Sie die Datenbankinstanz aus, die Sie sichern möchten, und geben Sie einen Sicherungsnamen an. Diese Sicherungen werden zusammen mit automatisierten Sicherungen gespeichert, aber nur Benutzer können On-Demand-Sicherungen löschen. Der Dienst verwaltet und bewahrt automatisierte Sicherungen auf, um die Anforderungen an die Aufbewahrung von Sicherungen zu erfüllen.

Weitere Informationen finden Sie unter Ausführen von On-Demand-Sicherungen.

Einschränkungen

  • Die Computeebene des Burstable-Servers unterstützt das On-Demand-Sicherungsfeature nicht.
  • Die SSDv2-Speicherebene unterstützt die On-Demand-Sicherungsfunktion nicht.
  • Sie können bis zu sieben On-Demand-Sicherungen pro flexibler Serverinstanz in Anspruch nehmen. Das Sicherungsaufbewahrungsfenster bestimmt, wie lange diese Sicherungen beibehalten werden sollen.

Langfristige Aufbewahrung

Azure Backup- und Azure Database for PostgreSQL-Dienste bieten eine langfristige Sicherungslösung der Unternehmensklasse für Azure Database for PostgreSQL flexible Serverinstanzen, die Sicherungen für bis zu 10 Jahre aufbewahren. Sie können eine langfristige Aufbewahrung (LONG-Term Retention, LTR) unabhängig oder neben der automatisierten Backup-Lösung verwenden, die von Azure Database for PostgreSQL angeboten wird, die eine Aufbewahrung von bis zu 35 Tagen bietet. Automatisierte Sicherungen sind physische Sicherungen, die für operative Wiederherstellungen geeignet sind – insbesondere, wenn Sie etwas aus den neuesten Sicherungen wiederherstellen möchten. Backups für die langfristige Aufbewahrung helfen Ihnen, Ihre Compliance-Anforderungen zu erfüllen, sind granularer und werden als logische Backups mithilfe des nativen Tools pg_dump erstellt. Neben der Langzeitaufbewahrung bietet die Lösung auch folgende Funktionen:

  • Kundenseitig gesteuerte, geplante und bedarfsorientierte Sicherungen der einzelnen Datenbanken.
  • Zentrale Überwachung aller Vorgänge und Aufträge.
  • Sicherungen werden in separaten Sicherheits- und Fehlerdomänen gespeichert. Wenn der Quellserver oder das Abonnement kompromittiert wird, sind die Sicherungen im Azure Backup-Tresor (in von Azure Backup verwalteten Speicherkonten) weiterhin sicher.
  • Die Verwendung von pg_dump bietet mehr Flexibilität beim Wiederherstellen von Daten in verschiedenen Datenbankversionen.
  • Azure-Sicherungstresore unterstützen Features für Unveränderlichkeit und vorläufiges Löschen (Vorschauversion) und schützen Ihre Daten.
  • LTR-Sicherungsunterstützung für Server mit CMK-Unterstützung.

Einschränkungen und Überlegungen

  • Testen Sie die LTR-Sicherung und -Wiederherstellung unmittelbar nach der Konfiguration, um sicherzustellen, dass sie Ihren Geschäftlichen Anforderungen entsprechen.
  • LTR-Wiederherstellungen sind derzeit nur als Als Dateien wiederherstellen in Speicherkonten verfügbar; die Funktion Als Server wiederherstellen ist für die Zukunft geplant.
  • LTR sichert alle Datenbanken in flexiblen Serverinstanzen, und Sie können keine einzelnen Datenbanken für die LTR-Konfiguration auswählen.
  • Die LTR-Sicherung wird für Replikate nicht unterstützt, sie kann jedoch auf primären Servern durchgeführt werden.
  • Die maximale unterstützte Datenbankgröße für LTR-Sicherungen (Long-Term Retention, Langzeitaufbewahrung) beträgt 1 TiB.
  • Sie können LTR-Sicherungen wöchentlich, monatlich oder jährlich planen. Der tägliche Sicherungszeitplan wird derzeit nicht unterstützt.
  • LTR-Sicherungen unterstützen keine Tabellen, die eine Zeile mit einer BYTEA-Länge von mehr als 500 MB enthalten.
  • Stellen Sie beim Wiederherstellen von Rollen für Microsoft Entra Benutzer sicher, dass Microsoft Entra Authentifizierung aktiviert ist und Sie als Microsoft Entra Administrator angemeldet sind, um zusätzliche Benutzer zu erstellen. Der Versuch, Entra-Rollen als normaler Benutzer zu erstellen, führt zu Fehlern.

Weitere Informationen zum Ausführen einer langfristigen Sicherung finden Sie im Anleitungshandbuch.

Häufig gestellte Fragen

  • Wie behandelt Azure die Sicherung meines Servers?

    Standardmäßig ermöglicht Azure Database for PostgreSQL automatisierte Sicherungen Ihres gesamten Servers (umfasst alle erstellten Datenbanken) mit einem Standardaufbewahrungszeitraum von sieben Tagen. Die automatisierten Sicherungen enthalten eine tägliche inkrementelle Momentaufnahme der Datenbank. Die Protokolldateien (WAL) werden kontinuierlich in Azure Blob Storage archiviert.

  • Kann ich automatisierte Sicherungen so konfigurieren, dass Daten langfristig aufbewahrt werden?

    Nein. Derzeit unterstützt Azure Database for PostgreSQL maximal 35 Tage aufbewahrung. Verwenden Sie manuelle Sicherungen für eine langfristige Aufbewahrungsanforderung mithilfe von Azure Backup.

  • Wie kann ich meine Instanzen von Azure Database for PostgreSQL – Flexibler Server manuell sichern?

    Mit der On-Demand-Backup-Funktion können Sie manuell einen physischen Snapshot erstellen. Sie können auch logische Sicherungen mit dem PostgreSQL-Tool pg_dump erstellen. Beispiele finden Sie unter Migrieren Ihrer Azure-Datenbank für PostgreSQL-Datenbank mithilfe von Dump und Wiederherstellung.

  • Welche Sicherungsfenster gibt es für meinen Server? Kann ich sie anpassen?

    In Azure werden Sicherungsfenster verwaltet, die nicht angepasst werden können. Die erste vollständige Momentaufnahmensicherung wird unmittelbar nach der Erstellung des Servers eingeplant. Nachfolgende Momentaufnahmesicherungen sind inkrementelle Sicherungen, die einmal täglich erfolgen.

  • Sind meine Sicherungen verschlüsselt?

    Ja. Alle Azure Database for PostgreSQL flexible Serverinstanzdaten, Sicherungen und temporäre Dateien, die während der Abfrageausführung erstellt werden, werden über AES (Advanced Encryption Standard) 256-Bit-Verschlüsselung verschlüsselt. Die Speicherverschlüsselung ist immer aktiviert und kann nicht deaktiviert werden.

  • Kann ich eine einzelne Datenbank oder ein paar Datenbanken auf einem Server wiederherstellen?

    Das Wiederherstellen einer einzelnen Datenbank oder einiger Datenbanken oder Tabellen wird nicht direkt unterstützt. Sie können jedoch den gesamten Server auf einem neuen Server wiederherstellen und anschließend Tabellen oder Datenbanken entfernen, die Sie auf dem neuen Server nicht benötigen.

  • Ist mein Server verfügbar, während eine Sicherung ausgeführt wird?

    Ja. Sicherungen sind Onlinevorgänge, bei denen Momentaufnahmen verwendet werden. Der Momentaufnahmevorgang dauert nur wenige Sekunden und beeinträchtigt keine Produktionsworkloads, sodass Hochverfügbarkeit für den Server sichergestellt ist.

  • Beim Einrichten des Wartungsfensters für den Server muss ich das Sicherungsfenster berücksichtigen?

    Nein. Sicherungen werden intern als Teil des verwalteten Diensts ausgelöst und haben keinen Einfluss auf das Wartungsfenster.

  • Wo werden meine automatisierten Sicherungen gespeichert, und wie verwalte ich ihre Aufbewahrung?

    Ihre Azure-Datenbank für PostgreSQL Flexible Server-Instanz erstellt automatisch Server-Sicherungen und speichert sie in:

    • Zonenredundantem Speicher in Regionen, in denen mehrere Zonen unterstützt werden.
    • Lokal redundantem Speicher in Regionen, in denen noch nicht mehrere Zonen unterstützt werden.
    • Die gekoppelte Region, falls Sie eine georedundante Sicherung konfigurieren.

    Sie können diese Sicherungsdateien nicht exportieren, da sie in Microsoft verwalteten Speicherkonten gespeichert sind. Sie haben schreibgeschützten Zugriff, um diese Dateien wiederherzustellen, können sie aber nicht ändern oder löschen. Die Sicherungsdateien werden nach dem Aufbewahrungszeitraum automatisch gelöscht.

    Sie können mithilfe von Sicherungen Ihren Server nur zu einem bestimmten Zeitpunkt wiederherstellen. Die Standardaufbewahrungsdauer für Sicherungen beträgt sieben Tage. Optional können Sie die Aufbewahrungsdauer für Sicherungen auf bis zu 35 Tage festlegen.

  • Wie oft wird das Backup mit georedundantem Backup in die gekoppelte Region kopiert?

    Wenn Sie den Server mit georedundanter Sicherung konfigurieren, werden die Sicherungsdaten in einem georedundanten Speicherkonto gespeichert. Vom Speicherkonto werden Datendateien in die gekoppelte Region kopiert, wenn die tägliche Sicherung auf dem primären Server erfolgt. WAL-Dateien werden gesichert, wenn sie für die Archivierung bereit sind.

    Sicherungsdaten werden asynchron und fortlaufend in die gekoppelte Region kopiert. Sie müssen dabei mit einer Verzögerung von bis zu einer Stunde für den Empfang von Sicherungsdaten rechnen.

  • Kann ich PITR in der entfernten Region durchführen?

    Nein. Die Daten werden zum Datum der letzten verfügbaren Sicherung in der Remoteregion wiederhergestellt.

  • Wie werden Sicherungen auf einem HA-fähigen Server ausgeführt?

    Datenvolumes in einer flexiblen Serverinstanz von Azure Database for PostgreSQL werden mit inkrementellen Momentaufnahmen des primären Servers auf verwalteten Datenträgern gesichert. Die WAL-Sicherung wird entweder vom primären oder Standbyserver ausgeführt.

  • Wie kann ich überprüfen, ob Sicherungen auf meinem Server ausgeführt werden?

    Sicherungen überprüfen Sie am besten, indem Sie regelmäßig Zeitpunktwiederherstellungen durchführen und sich vergewissern, dass Sicherungen gültig und wiederherstellbar sind. Sicherungsvorgänge oder Dateien werden für Endbenutzer nicht verfügbar gemacht.

  • Wo kann ich die Sicherungsverwendung sehen?

    Wählen Sie im Azure-Portal unter "Überwachung" die Option "Metriken" aus. In "Verwendeter Sicherungsspeicher" können Sie die gesamte Sicherungsnutzung überwachen.

  • Was geschieht mit meinen Sicherungen, wenn ich meinen Server lösche?

    Wenn Sie einen Server löschen, werden auch alle Sicherungen gelöscht, die zum Server gehören, und können nicht wiederhergestellt werden. Wenn Serverressourcen nach der Bereitstellung vor versehentlichem Löschen oder unerwarteten Änderungen geschützt werden sollen, können Administratoren Verwaltungssperren nutzen.

  • Wie werden Sicherungen für beendete Server aufbewahrt?

    Für beendete Server werden keine neuen Sicherungen ausgeführt. Der Dienst behält alle älteren Sicherungen (innerhalb des Aufbewahrungsfensters) zum Zeitpunkt des Beendens des Servers auf, bis der Server neu gestartet wird. Danach wird die Aufbewahrung der Sicherungen für den aktiven Server durch dessen Aufbewahrungszeitfenster bestimmt.

  • Wie werden mir meine Sicherungen berechnet und in Rechnung gestellt?

    Azure Database for PostgreSQL bietet bis zu 100 Prozent Ihres bereitgestellten Serverspeichers als Sicherungsspeicher ohne zusätzliche Kosten. Sie zahlen für zusätzlichen Sicherungsspeicher, den Sie verwenden, der in Gigabyte pro Monat berechnet wird, wie im Preismodell definiert.

    Welche Option für die Aufbewahrungsdauer und für die Sicherungsredundanz ausgewählt wird, wirkt sich zusammen mit Transaktionsaktivitäten auf dem Server direkt auf den gesamten Sicherungsspeicher und die Abrechnung aus.

  • Wie wird mir ein gestoppter Server berechnet?

    Während Ihre Serverinstanz beendet wird, werden keine neuen Sicherungen ausgeführt. Sie zahlen für bereitgestellten Speicher und Sicherungsspeicher (Sicherungen, die in Ihrem angegebenen Aufbewahrungsfenster gespeichert sind).

    Der kostenlose Sicherungsspeicher ist auf die Größe Ihrer bereitgestellten Datenbank beschränkt. Sie zahlen für alle überschüssigen Sicherungsdaten gemäß dem Sicherungspreis.

  • Ich habe meinen Server mit zonenredundanter Hochverfügbarkeit konfiguriert. Erstellen Sie zwei Sicherungen, und werden mir zweimal Gebühren in Rechnung gestellt?

    Nein. Unabhängig von HA- oder Nicht-HA-Servern verwaltet der Dienst nur eine Gruppe von Sicherungskopien. Sie zahlen nur einmal.

  • Wie kann ich meinen Server wiederherstellen?

    In Azure wird die Zeitpunktwiederherstellung für alle Server unterstützt. Sie können den neuesten Wiederherstellungspunkt oder einen benutzerdefinierten Wiederherstellungspunkt wiederherstellen, indem Sie das Azure Portal, die Azure CLI und die API verwenden.

    Um Ihren Server mithilfe von Tools wie pg_dump aus manuellen Sicherungen wiederherzustellen, können Sie zunächst eine Instanz von Azure Database for PostgreSQL – Flexible Server erstellen und dann Ihre Datenbanken mithilfe von pg_restore auf dem Server wiederherstellen.

  • Kann ich in einer anderen Verfügbarkeitszone innerhalb derselben Region wiederherstellen?

    Ja. Wenn in der Region mehrere Verfügbarkeitszonen unterstützt werden, wird die Sicherung in einem zonenredundanten Speicherkonto gespeichert und Ihnen die Wiederherstellung in einer anderen Zone ermöglicht.

  • Wie lange dauert eine Zeitpunktwiederherstellung? Warum dauert meine Wiederherstellung so lange?

    Der Vorgang zur Datenwiederherstellung aus einer Momentaufnahme hängt nicht von der Größe der Daten ab. Die Dauer des Wiederherstellungsvorgangs, bei dem die Protokolle angewendet werden (Transaktionsaktivitäten, die erneut abgespielt werden), kann jedoch variieren, abhängig von der vorherigen Sicherung für das angeforderte Datum und die angeforderte Uhrzeit sowie von der Anzahl der zu verarbeitenden Protokolle. Diese Bedingung gilt sowohl für die Wiederherstellung innerhalb derselben Zone als auch für das Wiederherstellen von Daten in einer anderen Zone.

  • Wenn ich meinen HA-fähigen Server wiederherstellen, wird der Wiederherstellungsserver automatisch mit hoher Verfügbarkeit konfiguriert?

    Nein. Der Server wird als Einzelinstanz der Instanz von Azure Database for PostgreSQL – Flexibler Server wiederhergestellt. Nach Abschluss der Wiederherstellung können Sie den Server optional mit Hochverfügbarkeit konfigurieren.

  • Ich habe meinen Server in einem virtuellen Netzwerk konfiguriert. Kann ich ihn in einem anderen virtuellen Netzwerk wiederherstellen?

    Ja. Wählen Sie zum Zeitpunkt der Wiederherstellung ein anderes virtuelles Netzwerk aus, in dem die Wiederherstellung erfolgen soll.

  • Kann ich meinen öffentlichen Zugriffsserver in einem virtuellen Netzwerk wiederherstellen oder umgekehrt?

    Nein. Azure Database for PostgreSQL unterstützt derzeit das Wiederherstellen von Servern über den öffentlichen und privaten Zugriff hinweg nicht.

  • Wie kann ich meinen Wiederherstellungsvorgang nachverfolgen?

    Derzeit gibt es keine Möglichkeit, den Wiederherstellungsvorgang nachzuverfolgen. Sie können das Aktivitätsprotokoll überwachen, um zu prüfen, ob der Vorgang in Bearbeitung oder abgeschlossen ist.