Übersicht über die Geschäftskontinuität mit Azure SQL-Datenbank
Gilt für: 
Azure SQL-Datenbank SQL-Datenbank in Fabric
Dieser Artikel enthält eine Übersicht über die Geschäftskontinuitäts- und Notfallwiederherstellungsfunktionen von Azure SQL-Datenbank, die die Optionen und Empfehlungen zum Wiederherstellen von störenden Ereignissen beschreiben, die zu Datenverlusten führen oder dazu führen können, dass Ihre Datenbank und Anwendung nicht mehr verfügbar sind. Erfahren Sie, was zu tun ist, wenn ein Benutzer- oder Anwendungsfehler die Datenintegrität gefährdet, eine Azure-Region ausfällt oder Wartungsaufgaben für Ihre Anwendung ausgeführt werden müssen.
Übersicht
Geschäftskontinuität in Azure SQL-Datenbank bezieht sich auf die Mechanismen, Richtlinien und Verfahren, die Es Ihrem Unternehmen ermöglichen, mit Unterbrechungen fortzufahren, indem Verfügbarkeit, hohe Verfügbarkeit und Notfallwiederherstellung bereitgestellt werden.
In den meisten Fällen behandelt SQL-Datenbank die Störungen, die in der Cloudumgebung auftreten können, und erhält den Betrieb Ihrer Anwendungen und Geschäftsprozesse aufrecht. Es gibt jedoch einige störende Ereignisse, bei denen die Entschärfung einige Zeit in Anspruch nehmen kann, z. B.:
- Ein Benutzer löscht oder aktualisiert versehentlich eine Zeile in einer Tabelle.
- Ein bösartiger Angreifer konnte erfolgreich Daten oder eine Datenbank löschen.
- Katastrophales Naturkatastrophenereignis nimmt ein Rechenzentrum oder eine Verfügbarkeitszone oder Region herunter.
- Seltenes Rechenzentrum, Verfügbarkeitszone oder regionsweite Ausfall durch Konfigurationsänderungen, Softwarefehler oder Hardwarekomponentenfehler.
Verfügbarkeit
Azure SQL-Datenbank bietet eine wichtige Zusage zur Ausfallsicherheit und Zuverlässigkeit, die sie vor Software- oder Hardwarefehlern schützt. Mit automatisierte Sicherungen können Sie Datenbanken ohne Verwaltungsaufwand vor versehentlicher Beschädigung oder Löschung schützen. Als Platform-as-a-Service (PaaS) bietet der Azure SQL-Datenbank-Dienst Verfügbarkeit als Off-the-Shelf-Feature mit einer branchenführenden Verfügbarkeits-SLA von 99,99 %.
Hochverfügbarkeit
Um eine hohe Verfügbarkeit in der Azure-Cloudumgebung zu erreichen, aktivieren Sie Zonenredundanz, sodass die Datenbank oder der elastische Pool Verfügbarkeitszonen verwendet, um sicherzustellen, dass die Datenbank oder der elastische Pool widerstandsfähig für Zonalfehler sind. Viele Azure-Regionen bieten Verfügbarkeitszonen, die getrennte Gruppen von Rechenzentren in einer Region sind, die über unabhängige Energie-, Kühl- und Netzwerkinfrastrukturen verfügen. Verfügbarkeitszonen sind so konzipiert, dass regionale Dienste, Kapazität und hohe Verfügbarkeit in den Zonen für um Standard bereitgestellt werden, wenn eine Zone einen Ausfall erlebt. Durch die Aktivierung von Zonenredundanz ist die Datenbank oder der elastische Pool robust für Zonal-Hardware- und Softwarefehler, und die Wiederherstellung ist für Anwendungen transparent. Wenn hohe Verfügbarkeit aktiviert ist, kann der Azure SQL-Datenbank Dienst eine SLA mit höherer Verfügbarkeit von 99,995 % bereitstellen.
Notfallwiederherstellung
Um eine höhere Verfügbarkeit und Redundanz in allen Regionen zu erzielen, können Sie Notfallwiederherstellungsfunktionen aktivieren, um die Datenbank schnell aus einem katastrophalen regionalen Ausfall wiederherzustellen. Optionen für die Notfallwiederherstellung mit Azure SQL Database sind:
- Aktive Georeplikation ermöglicht die Erstellung einer kontinuierlich synchronisierten, lesbaren Sekundärdatenbank in einer beliebigen Region für eine Primärdatenbank.
- Failovergruppen ermöglichen ihnen neben der kontinuierlichen Synchronisierung zwischen einer primären und sekundären Datenbank auch die Verwaltung der Replikation und des Failovers einiger oder aller Datenbanken auf einem logischen Server mit einem sekundären logischen Server in einer anderen Region. Failovergruppen stellen Lese-/Schreibzugriff und schreibgeschützte Listenerendpunkte bereit Standard, die unverändert sind, sodass das Aktualisieren von Anwendungs-Verbindungszeichenfolge s nach dem Failover nicht erforderlich ist.
- Geowiederherstellung ermöglicht es Ihnen, aus einem regionalen Ausfall wiederherzustellen, indem Sie aus geo replizierten Sicherungen wiederherstellen, wenn Sie nicht auf Ihre Datenbank in der primären Region zugreifen können, indem Sie eine neue Datenbank auf einem beliebigen vorhandenen Server in einer beliebigen Azure-Region erstellen.
Die folgende Tabelle vergleicht die aktive Georeplikation und Failovergruppen, zwei Notfallwiederherstellungsoptionen für Azure SQL-Datenbank:
| Aktive Georeplikation | Failovergruppen | |
|---|---|---|
| Fortlaufende Datensynchronisierung zwischen primärer und sekundärer Daten | Ja | Ja |
| Gleichzeitiges Failover für mehrere Datenbanken | Nein | Ja |
| Verbinden ion-Zeichenfolge wird nach dem Failover nicht geändert Standard | No | Ja |
| Unterstützung der Leseskalierung | Ja | Ja |
| Mehrere Replikate | Ja | Nein |
| Kann sich in derselben Region wie die primäre Instanz befinden | Ja | No |
Features zum Sicherstellen der Geschäftskontinuität
Aus Datenbankperspektive gibt es vier große potenzielle Störungsszenarien. In der folgenden Tabelle sind die SQL-Datenbankfunktionen für die Geschäftskontinuität aufgeführt, die Sie verwenden können, um ein mögliches Szenario einer Geschäftsunterbrechung abzumildern:
| Szenario für Geschäftsunterbrechungen | Funktionen der Geschäftskontinuität |
|---|---|
| Lokale Hardware- oder Softwarefehler, die Auswirkung auf den Datenbankknoten haben, z. B. Laufwerkfehler. | Um das Risiko lokaler Hardware- und Softwarefehler zu mindern, bietet SQL-Datenbank eine Hochverfügbarkeitsarchitektur, die nach diesen Fehlern eine automatische Wiederherstellung mit einer SLA von bis zu 99,99 % Verfügbarkeit gewährleistet. |
| Beschädigte oder gelöschte Daten – in der Regel durch einen Anwendungs- oder Benutzerfehler verursacht. Derartige Fehler sind anwendungsspezifisch und werden normalerweise nicht vom Datenbankdienst erkannt. | Um Ihr Unternehmen vor Datenverlusten zu schützen, werden von SQL-Datenbank automatisch wöchentlich vollständige Datenbanksicherungen, alle 12 oder 24 Stunden differenzielle Datenbanksicherungen und alle 5 bis 10 Minuten Transaktionsprotokollsicherungen durchgeführt. Sicherungen werden standardmäßig für alle Dienstebenen sieben Tage lang in redundantem Speicher aufbewahrt. Alle Servicestufen außer Basic unterstützen eine konfigurierbare Backup-Aufbewahrungszeit für Point-in-Time-Wiederherstellung (PITR) von bis zu 35 Tagen. Sie können eine gelöschte Datenbank an dem Punkt wiederherstellen, an dem sie gelöscht wurde, wenn der Server nicht gelöscht wurde oder wenn Sie eine Langzeitaufbewahrung (LTR) konfiguriert haben. |
| Seltener Ausfall des Rechenzentrums oder der Verfügbarkeitszone, möglicherweise durch ein Naturkatastrophenereignis, Konfigurationsänderung, Softwarefehler oder Hardwarekomponentenfehler. | Um den Ausfall des Rechenzentrums oder der Verfügbarkeitszone zu verringern, aktivieren Sie Zonenredundanz für die Datenbank oder den elastischen Pool, um Azure Verfügbarkeitszonen zu verwenden und Redundanz über mehrere physische Zonen innerhalb einer Azure-Region hinweg bereitzustellen. Durch aktivieren der Zonenredundanz wird sichergestellt, dass die Datenbank oder der elastische Pool widerstandsfähig für Zonalfehler mit bis zu 99,995 % hoher Verfügbarkeits-SLA ist. |
| Seltene regionale Ausfälle, die sich auf alle Verfügbarkeitszonen und die Rechenzentren auswirken, die sie umfassen, möglicherweise durch katastrophales Naturkatastrophenereignis verursacht. | Um einen regionsweiten Ausfall zu vermeiden, aktivieren Sie die Notfallwiederherstellung mithilfe einer der Optionen: – Kontinuierliche Datensynchronisierungsoptionen wie Failovergruppen (empfohlen) oder aktive Georeplikation, mit denen Sie Replikate in einer sekundären Region für failover erstellen können. – Einstellung der Redundanz des Sicherungsspeichers auf geo-redundanten Sicherungsspeicher zur Verwendung von geo-restore. |
RTO und RPO
Wenn Sie Ihren Plan für die Geschäftskontinuität entwickeln, müssen Sie wissen, wie viel Zeit maximal vergehen darf, bis die Anwendung nach einer Störung vollständig wiederhergestellt ist. Die Zeit, die für die vollständige Wiederherstellung einer Anwendung erforderlich ist, wird als RTO (Recovery Time Objective) bezeichnet. Sie müssen auch herausfinden, über welchen Zeitraum kürzlich durchgeführter Datenupdates (in einem bestimmten Zeitraum) maximal verloren gehen dürfen, wenn die Anwendung nach einer unvorhergesehenen Störung wiederhergestellt wird. Der potenzielle Datenverlust wird als RPO (Recovery Point Objective) bezeichnet.
In der folgenden Tabelle werden die RPO- und RTO-Werte der einzelnen Wiederherstellungsoptionen verglichen:
| Option Geschäftskontinuität | RTO (Ausfallzeit) | RPO (Datenverlust) |
|---|---|---|
| Hohe Verfügbarkeit (mit Zonenredundanz) |
In der Regel weniger als 30 Sekunden | 0 |
| Notfallwiederherstellung (mit Failovergruppen mit kundenverwalteter Failoverrichtlinie oder aktiver Georeplikation) |
In der Regel weniger als 60 Sekunden | Gleich oder größer als 0 (Hängt von Datenänderungen vor dem störenden Ereignis ab, das nicht repliziert wurde) |
| Notfallwiederherstellung (mit geo-restore) |
In der Regel Minuten oder Stunden | In der Regel Minuten oder Stunden |
Checklisten für Geschäftskontinuität
Informationen zu präskriptiven Empfehlungen zur Maximierung der Verfügbarkeit und zur Erreichung höherer Geschäftskontinuität finden Sie unter:
- Checkliste für die Verfügbarkeit
- Checkliste für Hochverfügbarkeit
- Prüfliste zur Notfallwiederherstellung
Vorbereiten einer Regionsverschiebung
Unabhängig davon, welche Geschäftskontinuitätsfeatures Sie verwenden, müssen Sie die sekundäre Datenbank in einer anderen Region vorbereiten. Wenn die Vorbereitung nicht sorgfältig durchgeführt wird, dauert es länger, Anwendungen nach einem Failover oder einer Datenbankwiederherstellung wieder online zu schalten. Zudem werden voraussichtlich weitere Problembehandlungsmaßnahmen zu einem Zeitpunkt erforderlich sein, zu dem Sie bereits unter Stress stehen – eine ungünstige Kombination. Folgen Sie der Checkliste, um sekundäre Daten für einen Regionsausfall vorzubereiten.
Wiederherstellen einer Datenbank innerhalb derselben Azure-Region
Mit automatischen Datenbanksicherungen können Sie eine Datenbank auf einen Zeitpunkt in der Vergangenheit zurücksetzen. Auf diese Weise können Sie Datenbeschädigungen aufgrund von menschlichem Versagen wiederherstellen. Point-in-Time Restore (PITR) ermöglicht es Ihnen, eine neue Datenbank auf demselben Server zu erstellen, die den Zustand der Daten vor dem beschädigenden Ereignis darstellt. Bei den meisten Datenbanken dauern Wiederherstellungsvorgänge weniger als 12 Stunden. Das Wiederherstellen einer sehr großen oder sehr aktiven Datenbank kann länger dauern. Weitere Informationen finden Sie unter Datenbankwiederherstellung.
Wenn der maximal unterstützte Sicherungsaufbewahrungszeitraum für die Zeitpunktwiederherstellung (Point-In-Time Restore, PITR) für Ihre Anwendung nicht ausreicht, können Sie ihn verlängern, indem Sie eine Richtlinie für die Langzeitaufbewahrung (Long-Term Retention, LTR) für die Datenbanken konfigurieren. Weitere Informationen finden Sie unter Langfristiges Aufbewahren von Sicherungen.
Durchführen eines Anwendungsupgrades mit minimalen Ausfallzeiten
Zuweilen muss eine Anwendung aufgrund von Wartungsarbeiten, wie beispielsweise einem Anwendungs-Upgrade, offline genommen werden. Der Artikel Verwalten von Anwendungsupgrades beschreibt, wie Sie mithilfe der aktiven Georeplikation parallele Upgrades Ihrer Cloudanwendung ermöglichen und so Ausfallzeiten während Upgrades minimieren. Gleichzeitig können Sie mit dieser Funktion einen Wiederherstellungspfad bereitstellen, falls etwas schiefgeht.
Kosten sparen mit einem Standby-Replikat
Wenn Ihr sekundäres Replikat nur für Notfallwiederherstellung (DR) verwendet wird und keine Lese- oder Schreib-Workloads enthält, können Sie Lizenzkosten sparen, indem Sie die Datenbank bei der Konfiguration einer neuen aktiven Geo-Replikationsbeziehung als Standby festlegen.
Weitere Informationen finden Sie unter Lizenzfreies Standby-Replikat.
Nächste Schritte
Überlegungen zum Anwendungsentwurf für einzelne Datenbanken und Pools für elastische Datenbanken finden Sie unter Entwerfen einer Anwendung für die cloudbasierte Notfallwiederherstellung und Strategien für die Notfallwiederherstellung mit Pools für elastische Datenbanken.
Lesen Sie Wiederherstellen einer Azure SQL-Datenbank oder Ausführen eines Failovers auf eine sekundäre Datenbank und die Prüfliste für Hochverfügbarkeit und Notfallwiederherstellung in Azure SQL-Datenbank.