Sichern von SQL Server Always-On-Verfügbarkeitsgruppen

  • Artikel

Azure Backup bietet eine End-to-End-Unterstützung für die Sicherung von SQL Server Always On-Verfügbarkeitsgruppen (VG), wenn sich alle Knoten in derselben Region und im gleichen Abonnement wie der Recovery Services-Tresor befinden. Wenn die Knoten der VG jedoch auf Regionen/Abonnements/lokal und Azure verteilt sind, sollten Sie einige Überlegungen berücksichtigen.

Hinweis

  • Die Sicherung von Datenbanken der Verfügbarkeitsgruppe „Basic“ wird von Azure Backup nicht unterstützt.
  • Weitere Informationen zu den unterstützten Konfigurationen und Szenarien finden Sie in der Supportmatrix für SQL-Backups.

Die von Azure Backup SQL VG verwendete Sicherungseinstellung unterstützt vollständige und differenzielle Sicherungen nur vom primären Replikat. Daher werden diese Sicherungsaufträge unabhängig von der Sicherungseinstellung immer auf dem primären Knoten ausgeführt. Bei vollständigen Kopiesicherungen und Transaktionsprotokollsicherungen wird bei der Entscheidung über den Knoten, auf dem die Sicherung ausgeführt wird, die Einstellung für die Sicherung der Gruppe berücksichtigt.

VG-Sicherungseinstellung Vollständige und differenzielle Sicherungen werden ausgeführt unter Kopiesicherungen und Protokollsicherungen werden erstellt von
Primär Primäres Replikat Primäres Replikat
Nur sekundär Primäres Replikat Eines der sekundären Replikate
Sekundär bevorzugen Primäres Replikat Sekundäre Replikate werden bevorzugt, Sicherungen können jedoch auch auf dem primären Replikat ausgeführt werden.
Keine Primäres Replikat Beliebiges Replikat

Die Erweiterung zur Sicherung von Workloads wird auf dem Knoten installiert, wenn sie beim Azure Backup-Dienst registriert ist. Wenn eine VG-Datenbank für die Sicherung konfiguriert ist, werden die Sicherungszeitpläne per Push an alle registrierten Knoten der VG übertragen. Die Zeitpläne werden auf allen VG-Knoten und den Workloadsicherungserweiterungen auf diesen Knoten ausgelöst, um festzulegen, welcher Knoten die Sicherung durchführt. Die Knotenauswahl hängt, wie in Abschnitt 1 erläutert, vom Sicherungstyp und der Sicherungseinstellung ab.

Der ausgewählte Knoten fährt mit dem Backup-Job fort, während der Job, der auf den anderen Knoten ausgelöst wird, aussteigt, das heißt, er überspringt den Job.

Hinweis

Azure Backup berücksichtigt bei der Auswahl zwischen den sekundären Replikaten keine Sicherungsprioritäten oder Replikate.

Registrieren von VG-Knoten im Recovery Services-Tresor

Ein Recovery Services-Tresor unterstützt die Sicherung von Datenbanken nur für VMs in derselben Region und demselben Abonnement wie der Tresor.

  • Sie müssen den primären Knoten beim Tresor registrieren (andernfalls können keine vollständigen Sicherungen durchgeführt werden).
  • Wenn die Sicherungseinstellung nur sekundär ist, müssen Sie mindestens einen sekundären Knoten beim Tresor registrieren (andernfalls können keine vollständigen Protokoll-/Kopiesicherungen durchgeführt werden).

Wenn die oben genannten Bedingungen nicht erfüllt sind, tritt bei der Konfiguration von Sicherungen für VG-Datenbanken ein Fehler mit dem Fehlercode FabricSvcBackupPreferenceCheckFailedUserError auf.

Betrachten wir die folgende VG-Bereitstellung als Referenz.

Diagram for AG deployment as reference.

Basierend auf der obigen Beispiel-AG-Bereitstellung sind folgende Überlegungen angestellt:

  • Da sich der primäre Knoten in Region 1 und Abonnement 1 befindet, muss sich der Recovery Services-Tresor (Tresor 1) in Region 1 und Abonnement 1 befinden, um diese VG zu schützen.
  • VM3 kann nicht bei Tresor 1 registriert werden, da er sich in einem anderen Abonnement befindet.
  • VM4 kann nicht bei Tresor 1 registriert werden, da er sich in einer anderen Region befindet.
  • Wenn die Sicherungseinstellung nur sekundär ist, müssen VM1 (primär) und VM2 (sekundär) bei Tresor 1 registriert werden (da vollständige Sicherungen den primären Knoten und Protokolle einen sekundären Knoten erfordern). Für andere Sicherungseinstellungen muss VM1 (primär) bei Tresor 1 registriert sein, VM2 ist optional (da alle Sicherungen auf dem primären Knoten ausgeführt werden können).
  • VM3 könnte zwar in Abonnement 2 bei Tresor 2 registriert werden, und die VG-Datenbanken würden dann für den Schutz in Tresor 2 angezeigt, aber aufgrund des Fehlens des primären Knotens in Tresor 2 würde die Konfiguration von Sicherungen fehlschlagen.
  • VM4 könnte zwar ebenfalls im Tresor 4 in Region 2 registriert werden, allerdings würde das Konfigurieren von Sicherungen fehlschlagen, da der primäre Knoten nicht im Tresor 4 registriert ist.

Failover-Behandlung

Nachdem für die VG ein Failover auf einen der sekundären Knoten erfolgt ist:

  • Die vollständigen und differenziellen Sicherungen werden vom neuen primären Knoten aus fortgesetzt, wenn sie beim Tresor registriert sind.
  • Die vollständigen Protokoll- und Kopiesicherungen werden basierend auf der Sicherungseinstellung vom primären/sekundären Knoten fortgesetzt.

Hinweis

Protokollkettenunterbrechungen werden beim Failover nicht ausgeführt, wenn das Failover nicht mit einer Sicherung übereinstimmt.

Basierend auf der obigen Beispiel-AG-Bereitstellung sind die folgenden Failover-Möglichkeiten:

  • Failover auf VM2
    • Vollständige und differenzielle Sicherungen werden von VM2 durchgeführt.
    • Vollständige Protokoll- oder Kopiesicherungen werden basierend auf der Sicherungseinstellung von VM1 oder VM2 durchgeführt.
  • Failover auf VM3 (anderes Abonnement)
    • Da Sicherungen in Tresor 2 nicht konfiguriert sind, werden keine Sicherungen durchgeführt.
    • Wenn die Sicherungseinstellung nicht auf nur sekundär festgelegt ist, können Sicherungen jetzt in Tresor 2 konfiguriert werden, da der primäre Knoten in diesem Tresor registriert ist. Dies kann jedoch zu Konflikten/Sicherungsfehlern führen. Weitere Informationen hierzu unter Konfigurieren von Sicherungen für eine VG mit mehreren Regionen.
  • Failover auf VM4 (andere Region)
    • Da Sicherungen in Tresor 4 nicht konfiguriert sind, werden keine Sicherungen durchgeführt.
    • Wenn die Sicherungseinstellung nicht nur sekundär ist, können Sicherungen jetzt im Tresor 4 konfiguriert werden, da der primäre Knoten in diesem Tresor registriert ist. Dies kann jedoch zu Konflikten/Sicherungsfehlern führen. Weitere Informationen hierzu unter Konfigurieren von Sicherungen für eine VG mit mehreren Regionen.

Konfigurieren von Sicherungen für eine VG mit mehreren Regionen

Der Recovery Services-Tresor unterstützt keine abonnement- oder regionsübergreifenden Sicherungen. In diesem Abschnitt wird zusammengefasst, wie Sie Sicherungen für VGs aktivieren, die verschiedene Abonnements oder Azure-Regionen umfassen, und die damit verbundenen Überlegungen.

  • Werten Sie aus, ob Sie wirklich Sicherungen von allen Knoten aktivieren müssen. Wenn eine Region/ein Abonnement über die meisten AG-Knoten verfügt und ein Failover auf andere Knoten sehr selten auftritt, kann es ausreichen, das Backup in dieser ersten Region einzurichten. Wenn die Failovers in andere Regionen bzw. Abonnements häufig auftreten und länger andauern, sollten Sie außerdem Sicherungen proaktiv in der anderen Region einrichten.

  • Jeder Tresor, in dem die Sicherung aktiviert wird, verfügt über eigene Wiederherstellungspunktketten. Wiederherstellungen von diesen Wiederherstellungspunkten können nur auf VMs durchgeführt werden, die in diesem Tresor registriert sind.

  • Vollständige/differenzielle Sicherungen werden nur im Tresor erfolgreich ausgeführt, der über den primären Knoten verfügt. Bei Sicherungen in anderen Tresoren treten weiterhin Fehler auf.

  • Protokollsicherungen funktionieren weiterhin im vorherigen Tresor, bis eine Protokollsicherung im neuen Tresor, in dem der neue primäre Knoten vorhanden ist, ausgeführt und die Protokollkette für den alten Tresor dadurch unterbrochen wird.

    Hinweis

    Es gibt eine feste Grenze von 15 Tagen, nach der Protokollsicherungen fehlschlagen.

  • Vollständige Kopiesicherungen funktionieren in allen Tresoren.

  • Der Schutz wird in jedem Tresor als unterschiedliche Datenquelle behandelt und separat abgerechnet.

Es wird empfohlen, die Sicherungseinstellung auf Primär festzulegen, um Protokollsicherungskonflikte zwischen den beiden Tresoren zu vermeiden. Je nachdem, welcher Tresor über den primären Knoten verfügt, werden dann in diesem auch die Protokollsicherungen erstellt.

Basierend auf der obigen Beispiel-AG-Bereitstellung sind hier die Schritte zum Aktivieren der Sicherung von allen Knoten. Es wird davon ausgegangen, dass die Sicherungseinstellung in allen Schritten erfüllt wird.

Schritt 1: Aktivieren von Sicherungen in Region 1, Abonnement 1 (Tresor 1)

Da sich der primäre Knoten in der Region und im Abonnement befindet, funktionieren die üblichen Schritte zum Aktivieren von Sicherungen.

Schritt 2: Aktivieren von Sicherungen in Region 1, Abonnement 2 (Tresor 2)

  1. Failover der VG auf VM3, sodass der primäre Knoten in Tresor 2 vorhanden ist
  2. Konfigurieren Sie Sicherungen für die VG-Datenbanken in Tresor 2.
  3. Zu diesem Zeitpunkt gilt Folgendes:
    1. Die vollständigen/differenziellen Sicherungen schlagen in Tresor 1 fehl, da keiner der registrierten Knoten diese Sicherung erstellen kann.
    2. Die Protokollsicherungen werden in Tresor 1 erfolgreich ausgeführt, bis eine Protokollsicherung in Tresor 2 ausgeführt wird und die Protokollkette für Vault 1 unterbrochen wird.
  4. Failback der VG auf VM1

Schritt 3: Aktivieren von Sicherungen in Region 2, Abonnement 1 (Tresor 4)

Identisch mit Schritt 2

Sichern einer VG, die Azure- und lokale Bereiche umfasst

Azure Backup für SQL Server kann nicht lokal ausgeführt werden. Wenn sich der primäre Knoten in Azure befindet und die Sicherungseinstellung von den Knoten in Azure erfüllt wird, können Sie die obige Anleitung für die VG mit mehreren Regionen befolgen, um Sicherungen für die Replikate in Azure zu aktivieren. Wenn ein Failover auf einen lokalen Knoten erfolgt, treten bei den vollständigen und differenziellen Sicherungen in Azure Fehler auf. Protokollsicherungen können fortgesetzt werden, bis die Protokollkette unterbrochen wird oder 15 Tage vergangen sind.

Drosselung für Sicherungsaufträge in einer VG-Datenbank

Derzeit gelten die Grenzwerte für die Sicherungsdrosselung auf ebene einzelner Computer. Der Standardgrenzwert ist 20. Wenn mehr als 20 Sicherungen gleichzeitig ausgelöst werden, werden die ersten 20 ausgeführt, und die anderen werden in die Warteschlange gestellt. Wenn die ausgeführten Aufträge abgeschlossen sind, wird die Ausführung der Aufträge in der Warteschlange gestartet.

Sie können diesen Wert in einen kleineren Wert ändern, wenn die gleichzeitigen Sicherungen eine Speicher-, E/A- oder CPU-Auslastung auf dem Knoten verursachen. Da die Drosselung auf Knotenebene ausgeführt wird, kann dies zu Problemen bei der Sicherungssynchronisierung führen. Stellen Sie sich dazu eine Verfügbarkeitsgruppe mit 2 Knoten vor.

Beispielsweise verfügt der erste Knoten über 50 eigenständige Datenbanken, die geschützt sind, und beide Knoten verfügen über 5 geschützte VG-Datenbanken. Auf Knoten 1 sind 55 Datenbanksicherungsaufträge geplant, auf Knoten 2 dagegen nur 5. Außerdem sind alle diese Sicherungen so konfiguriert, dass sie stündlich gleichzeitig ausgeführt werden. An einem Punkt werden alle 55 Sicherungen auf Knoten 1 ausgelöst, und 35 dieser Sicherungen werden in die Warteschlange gestellt. Einige davon sind die VG-Datenbanksicherungen. Auf Knoten 2 würden die VG-Datenbanksicherungen jedoch ohne Warteschlangen ausgeführt.

Da die VG-Datenbankaufträge auf einem Knoten in die Warteschlange gestellt und auf einem anderen ausgeführt werden, funktioniert die Sicherungssynchronisierung (wie in Abschnitt 6 erwähnt) nicht ordnungsgemäß. Knoten 2 geht möglicherweise davon aus, dass Knoten 1 ausgefallen ist und Aufträge von dort nicht mehr zur Synchronisierung verwendet werden. Dies kann zu Protokollkettenunterbrechungen oder zusätzlichen Sicherungen führen, da beide Knoten Sicherungen unabhängig voneinander erstellen können.

Ein ähnliches Problem kann auftreten, wenn die Anzahl der geschützten AG-Datenbanken die Drosselungsgrenze überschreitet. In diesem Fall kann die Sicherung für z. B. DB1 auf Knoten 1 in die Warteschlange gestellt werden, während sie auf Knoten 2 ausgeführt wird.

Es wird empfohlen, die folgenden Sicherungseinstellungen zu verwenden, um diese Synchronisierungsprobleme zu vermeiden:

  • Legen Sie für eine VG mit 2 Knoten die Sicherungseinstellung auf Primär oder Nur sekundär fest. Dann kann nur ein Knoten die Sicherungen durchführen, der andere wird immer aussetzen.
  • Legen Sie für eine VG mit mehr als 2 Knoten die Sicherungseinstellung auf Primär fest. Dann kann nur der primäre Knoten die Sicherungen durchführen, andere Knoten setzen aus.

Abrechnung für VG-Sicherungen

Wie bei einer eigenständigen SQL-Instanz wird eine gesicherte VG-Instanz als eine geschützte Instanz betrachtet. Die Gesamtgröße des Front-Ends aller geschützten Datenbanken in einer Instanz wird in Rechnung gestellt. Betrachten Sie die folgende Bereitstellung:

Diagram showing the calculation of protected instances of databases.

Die geschützten Instanzen werden wie folgt berechnet:

Geschützte Instanz/Abrechnungsinstanz Datenbanken, die für die Berechnung der Front-End-Größe berücksichtigt werden
VG1 DB1, DB2
VG2 DB4
VM2 DB3
VM3 DB6
VM4 DB5

Verschieben einer geschützten Datenbank in eine oder aus einer VG

Azure Backup betrachtet SQL instance oder AGName\DatabaseName als eindeutigen Datenbanknamen. Als die eigenständige Datenbank geschützt wurde, war ihr eindeutiger Name StandAloneInstanceName\DBName. Wenn sie unter einer VG bewegt wird, ändert sich der eindeutige Name in AGName\DBName. Bei den Sicherungen für die eigenständige Datenbank tritt ein Fehler mit dem folgenden Fehlercode auf: UserErrorBackupFailedStandaloneDatabaseMovedInToAG.

Die Datenbank muss für den Schutz unter der VG konfiguriert sein. Diese wird als neue Datenquelle mit einer separaten Wiederherstellungspunktkette behandelt. Der ältere Schutz einer eigenständigen Datenbank kann mit Beibehaltung von Daten beendet werden, um zu verhindern, dass zukünftige Sicherungen ausgelöst werden und fehlschlagen. Wenn eine geschützte Ag-Datenbank aus der Ag-Datenbank wechselt und zu einer eigenständigen Datenbank wird, tritt bei den Sicherungen ein Fehler mit dem Fehlercode auf: UserErrorBackupFailedDatabaseMovedOutOfAG.

Die Datenbank muss für den Schutz unter der eigenständigen Instanz konfiguriert sein. Diese wird als neue Datenquelle mit einer separaten Wiederherstellungspunktkette behandelt. Der ältere Schutz der VG-Datenbank kann mit Beibehaltung von Daten beendet werden, um zu verhindern, dass zukünftige Sicherungen ausgelöst werden und fehlschlagen.

Hinzufügen/Entfernen eines Knotens zu einer VG

Wenn einer für Sicherungen konfigurierten VG ein neuer Knoten hinzugefügt wird, erkennen die Workloadsicherungserweiterungen, die auf den bereits registrierten Knoten ausgeführt werden, die Änderung der VG-Topologie und informieren den Azure Backup-Dienst während des nächsten geplanten Datenbankermittlungsauftrags. Wenn dieser neue Knoten für Sicherungen im gleichen Recovery Services-Tresor wie die anderen vorhandenen Knoten registriert wird, löst der Azure Backup-Dienst einen Workflow aus, der diesen neuen Knoten mit den erforderlichen Metadaten für die Durchführung von VG-Sicherungen konfiguriert.

Danach synchronisiert der neue Knoten die Informationen zum VG-Sicherungszeitplan des Azure Backup-Diensts und beginnt mit der Teilnahme am synchronisierten Sicherungsprozess. Wenn der neue Knoten nicht in der Lage ist, die Sicherungszeitpläne zu synchronisieren und an Sicherungen teilzunehmen, wird durch das Auslösen einer erneuten Registrierung für den Knoten die Neukonfiguration des Knotens ebenfalls für VG-Sicherungen erzwungen. Auch in diesem Fall erkennen die Workloaderweiterungen beim Hinzufügen von Knoten die Änderung der VG-Topologie und informieren den Azure Backup Dienst. Der Dienst startet einen Workflow zum Entfernen der Knotenkonfiguration im entfernten Knoten, um die Sicherungszeitpläne für VG-Datenbanken zu löschen und die VG-bezogenen Metadaten zu löschen.

Aufheben einer VG-Knotenregistrierung aus Azure Backup

Wenn ein Knoten Teil einer VG ist, für die mindestens eine Datenbank für die Sicherung konfiguriert ist, lässt Azure Backup die Aufhebung der Registrierung dieses Knotens nicht zu. Dies soll zukünftige Sicherungsfehler verhindern, falls die Sicherungseinstellung ohne diesen Knoten nicht erfüllt werden kann. Sie müssen den Knoten zunächst aus der VG entfernen, um dessen Registrierung aufheben zu können. Wenn der Workflow zum Aufheben der Konfiguration des Knotens abgeschlossen ist, können Sie die Registrierung des Knotens aufheben.

Stellen Sie eine Datenbank aus Azure Backup in einer VG wieder her. SQL-Verfügbarkeitsgruppen unterstützen das direkte Wiederherstellen einer Datenbank in einer VG nicht. Die Datenbank muss in einer eigenständigen SQL-Instanz wiederhergestellt und dann mit einer VG verbunden werden.

Szenarios für die erneute Erstellung von Verfügbarkeitsgruppen für den SQL-Datenbankserver

Erneute Erstellung einer Verfügbarkeitsgruppe (VG), Duplizieren von VGs und Auflisten von Sicherungselementen als schützbare Elemente oder geschützte Elemente in den folgenden Szenarios:

  • Erneut erstellte VGs, die bereits geschützt sind, werden auf der Seite Sicherung konfigurieren und in der Liste Geschützte Elemente als doppelte VGs angezeigt. Wenn Sie die Sicherungsdaten beibehalten möchten, die bereits in der älteren VG vorhanden sind, beenden Sie die Sicherung, indem Sie die Option Schutz beenden und Daten beibehalten verwenden, bevor Sie Sicherungen für die neuen VG-Elemente erneut erstellen und planen.

    Azure Backup listet die doppelten Elemente standardmäßig in der Liste der geschützten Elemente und auf der Seite Sicherung konfigurieren oder in der Liste der schutzfähigen Elemente auf und zeigt diese Elemente an, bis Sie die Sicherungsdaten beibehalten möchten.

  • Wenn Sie die Sicherungsdaten der älteren VG nicht benötigen, beenden Sie den Sicherungsvorgang, indem Sie die Option Schutz beenden und Daten löschen für das ältere Element verwenden, bevor Sie Sicherungen in der neuen VG erneut erstellen und planen.

    Achtung

    Bei der Option „Schutz beenden und Daten löschen“ handelt es sich um einen destruktiven Vorgang.

  • Sie können die VG nach der Durchführung des obigen Prozesses der Option „Schutz beenden“ neu erstellen, um Sicherungsfehler zu vermeiden.

Nächste Schritte

In diesem Artikel werden folgende Themen erläutert: