Geschäftskontinuität in Azure SQL-Datenbank

2025-04-18

Gilt für:Azure SQL-Datenbank SQL-Datenbank in Fabric

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.

Ausführliche Empfehlungen zur Maximierung der Verfügbarkeit und zur Erreichung einer höheren Geschäftskontinuität finden Sie unter:

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.
Seltener Ausfall eines Rechenzentrums, einer Verfügbarkeitszone oder einer gesamten Region, verursacht durch Konfigurationsänderungen, Softwarefehler oder Hardwarefehler.

Hochverfügbarkeit

Azure SQL-Datenbank bietet eine wichtige Zusage zur Ausfallsicherheit und Zuverlässigkeit, die sie vor Software- oder Hardwarefehlern schützt. Automatisierte Sicherungen schützen Ihre Datenbanken vor Korruption oder versehentlicher Löschung. 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 %.

Um eine hohe Verfügbarkeit in der Azure-Cloudumgebung zu erzielen, aktivieren Sie Zonenredundanz. Bei Zonenredundanz verwendet die Datenbank oder der elastische Pool Azure-Verfügbarkeitszonen , um Ausfallsicherheit für Zonenfehler sicherzustellen.

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 Verfügbarkeit in den verbleibenden Zonen bereitgestellt werden, falls 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 Listenerendpunkte mit Lese-/Schreibzugriff und reinem Lesezugriff bereit, die unverändert bleiben, sodass Anwendungsverbindungszeichenfolgen nach dem Failover nicht aktualisiert werden müssen.
Geowiederherstellung ermöglicht es Ihnen, sich von einem regionalen Ausfall zu erholen, indem Sie geo-replizierte Sicherungen nutzen. Wenn Sie nicht auf Ihre Datenbank in der primären Region zugreifen können, erstellen Sie eine neue Datenbank auf einem beliebigen vorhandenen Server in einer beliebigen Azure-Region.

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
Simultanes Failover mehrerer Datenbanken	Nein	Ja
Die Verbindungszeichenfolge bleibt nach dem Failover unverändert	Nein	Ja
Unterstützung der Leseskalierung	Ja	Ja
Mehrere Replikate	Ja	Nein
Kann sich in derselben Region wie die primäre Instanz befinden	Ja	Nein

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. Es gibt zwei gängige Methoden zum Quantifizieren von Geschäftsanforderungen im Bereich der Notfallwiederherstellung:

Recovery Time Objective (RTO): Die Zeit, die für eine Anwendung erforderlich ist, um nach einem ungeplanten disruptiven Ereignis vollständig wiederherzustellen.
Recovery Point Objective (RPO): Die Zeitspanne des Datenverlusts, der von einem ungeplanten störenden Ereignis toleriert werden kann.

In der folgenden Tabelle werden die RPO- und RTO-Werte der einzelnen Optionen für Business Continuity verglichen:

Option Geschäftskontinuität	RTO (Ausfallzeit)	RPO (Datenverlust)
Hohe Verfügbarkeit (mit Zonenredundanz)	In der Regel weniger als 30 Sekunden	0
Notfallwiederherstellung (Verwenden von Failovergruppen mit kundenseitig verwalteter 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, abhängig von der Azure-Speicherreplikation	In der Regel Minuten oder Stunden, abhängig von der Größe der Datenbanksicherung

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 Auswirkungen auf den Datenbankknoten haben.	Um lokale Hardware- und Softwarefehler zu vermeiden, enthält Azure SQL-Datenbank eine Verfügbarkeitsarchitektur, die die automatische Wiederherstellung von diesen Fehlern mit bis zu 99,99% Verfügbarkeits-SLA garantiert.
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 Hardwarefehler.	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.
Seltener regionaler Ausfall, der alle Verfügbarkeitszonen und die darin enthaltenen Rechenzentren betrifft, möglicherweise verursacht durch ein katastrophales Naturereignis.	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. – Festlegen der Sicherungsspeicherredundanz auf georedundanten Sicherungsspeicher, um Geowiederherstellungzu verwenden.

Vorbereitung auf den Ausfall einer Region

Unabhängig davon, welche Geschäftskontinuitätsfeatures Sie verwenden, müssen Sie die sekundäre Datenbank in einer anderen Region vorbereiten. Wenn Sie sich nicht ordnungsgemäß vorbereiten, dauert es länger, Ihre Anwendungen nach einem Failover oder einer Wiederherstellung wieder online zu schalten, und es sind wahrscheinlich auch weitere Problembehandlungen erforderlich, was den RTO verzögern kann. Folgen Sie der Checkliste für die Vorbereitung sekundärer Maßnahmen beim Ausfall einer Region.

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 Status der Daten vor dem beschädigten Ereignis darstellt. Wiederherstellungszeiten finden Sie unter RTO und RPO.

Wenn der maximal unterstützte Aufbewahrungszeitraum für die Wiederherstellung zu einem bestimmten Zeitpunkt für Ihre Anwendung nicht ausreicht, haben Sie die Möglichkeit, ihn zu erweitern, indem Sie eine langfristige Aufbewahrungsrichtlinie (LTR) konfigurieren. Weitere Informationen finden Sie unter Langfristige Aufbewahrung.

Durchführen eines Anwendungsupgrades mit minimalen Ausfallzeiten

Zuweilen muss eine Anwendung aufgrund von Wartungsarbeiten, wie beispielsweise einem Anwendungs-Upgrade, offline genommen werden. Sie können rollierende Upgrades von Cloudanwendungen mithilfe der aktiven Georeplikation der SQL-Datenbank verwalten. Die Georeplikation kann auch einen Wiederherstellungspfad bereitstellen, wenn ein Fehler auftritt.

Kostenersparnis mit einem Standbyreplikat

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

Nächster Schritt

Prüfliste für Hochverfügbarkeit und Notfallwiederherstellung