So verwalten Sie das Disaster Recovery für SQL Server

Auf den Notfall vorbereitet sein

SQL Server fundiert wie andere Datenbankprodukte auch – Oracle Database oder IBM Db2 – auf der Programmiersprache Structured Query Language (SQL), die wiederum die Basisi für das Management relationaler Datenbanken und die Abfrage ihrer Daten bildet. SQL Server verwendet eine modifizierte Implementierung von SQL - Transact-SQL genannt -, die der Standardsprache eine Reihe von proprietären Programmerweiterungen hinzufügt.

Anwendungen, die auf SQL Server angewiesen sind, müssen auf die Daten zugreifen können, um die Arbeitslastanforderungen zu erfüllen. Unterbrechungen der Datendienste können aus zahlreichen Gründen auftreten, zum Beispiel aus folgenden:

• ein Benutzer löscht versehentlich wichtige Daten
• ein Malware-Angriff verschlüsselt oder vernichtet Daten
• ein Mitarbeiter verschüttet Kaffee auf dem Speichersystem
• ein Stromausfall führt zu einer Beschädigung der Daten
• ein Erdbeben zerstört die physische Speicherinfrastruktur
• ein Festplattenlaufwerk (HDD) fällt aus und alle Daten auf diesem Laufwerk gehen verloren
• ein Administrator formatiert versehentlich eine Festplatte, die aktive Daten enthält
• eine Softwarebeschädigung führt zu Datenverlust oder mangelnder Verfügbarkeit
• ein unvorsichtiger Mitarbeiter stiehlt ein physisches Speichergerät

Dies sind bei weitem nicht die einzigen Gründe, aus denen Daten nicht mehr verfügbar sein können, aber sie veranschaulichen das breite Spektrum an Krisen, die jedes Unternehmen jederzeit treffen können. Unabhängig von der Ursache besteht die einzige Möglichkeit, sich vor Datenverlusten und Serviceunterbrechungen zu schützen, in der Implementierung einer Disaster-Recovery-Strategie, die die Ausfallzeiten minimiert und die sichere Wiederherstellung der betroffenen Daten gewährleistet. SQL Server verfügt über Funktionen zum Schutz vor Katastrophen, von denen viele Teil der Hochverfügbarkeitsfunktionen der Plattform sind.

SQL Server verfügt über Funktionen zum Schutz vor Katastrophen, von denen viele Teil der Hochverfügbarkeitsfunktionen der Plattform sind.

Das Hauptziel eines Disaster-Recovery-Plans ist die Gewährleistung der Geschäftskontinuität (Business Continuity) im Katastrophenfall. Nicht alle Pläne sind jedoch gleich, und das sollten sie auch nicht sein. Ein DR-Plan sollte auf die spezifischen Data-Protection-Anforderungen eines Unternehmens zugeschnitten sein. Daten, die eine geschäftskritische Finanzanwendung steuern, müssen beispielsweise sofort wiederhergestellt werden, während Daten, die für die Erstellung monatlicher Umsatzberichte verwendet werden, wahrscheinlich eine längere Verzögerung vertragen können. Bei der Planung einer DR-Strategie sollte ein Unternehmen die folgenden drei Metriken festlegen:

• Recovery Time Objective (RTO). Dies ist die maximale Zeitspanne, die eine Anwendung aufgrund nicht verfügbarer Daten offline sein kann. Diese Kennzahl bestimmt, wie schnell die Daten nach einem Vorfall wieder online sein müssen.
• Recovery Point Objective (RPO). Hierbei handelt es sich um das akzeptable Ausmaß an Datenverlusten, das im Falle eines Ereignisses toleriert werden kann. Diese Kennzahl wird oft in Form von Zeit angegeben. Wenn beispielsweise eine Datenbank alle zwei Stunden gesichert wird und kurz vor der nächsten planmäßigen Sicherung eine Katastrophe eintritt, gehen alle seit der letzten Sicherung vorgenommenen Datenänderungen verloren.
• Recovery Level Objective (RLO). Dies ist die Granularitätsebene, auf der die Daten wiederhergestellt werden sollen, zum Beispiel auf Instanz-, Datenbank- oder Tabellenebene.

Ein Unternehmen muss letztlich das Risiko eines Datenverlusts gegen die Kosten für die Implementierung einer DR-Strategie abwägen. Je kürzer die RTO und RPO (in Bezug auf die Zeit) und je feiner die RLO-Granularität, desto höher sind die Kosten.

Eine sinnvolle Disaster-Recovery-Strategie für SQL Server erstellen

Hat das Unternehmen das erforderliche Schutzniveau festgelegt, kann es die folgenden SQL-Server-Funktionen nutzen, um die Auswirkungen unerwarteter Serviceunterbrechungen zu mildern:

• Backup und Recovery. Eine gut getestete Sicherungs- und Wiederherstellungsstrategie kann dazu beitragen, Datenbanken vor einer Vielzahl von Problemen zu schützen, darunter Ransomware, Benutzerfehler, Hardwareausfälle und Naturkatastrophen. Die Sicherung von Daten an einem separaten Speicherort ermöglicht es, eine Datenbank in einem konsistenten Zustand wiederherzustellen und katastrophale Datenverluste zu vermeiden; allerdings kann die Wiederherstellung von Datenbanken ein zeitaufwändiger Prozess sein, und Datenänderungen, die nach der letzten Sicherung vorgenommen wurden, gehen verloren. Dafür stehen dann Funktionen wie inkrementelle Sicherungen zur Verfügung sowie die Option eines Cloud-Backups, mit dem sich der Disaster-Recovery-Plan erweitern lässt. Backups sind angesichts der Zunahme von Ransomware-Angriffen besonders wichtig geworden.
• Always-On-Verfügbarkeitsgruppen. Wie Backups bieten auch Verfügbarkeitsgruppen Schutz auf Datenbankebene. Eine Verfügbarkeitsgruppe besteht aus einer Gruppe von Datenbanken, die gemeinsam auf eine sekundäre Instanz übergehen. SQL Server kann bis zu acht Sätze von entsprechenden sekundären Datenbanken in einer Verfügbarkeitsgruppe unterstützen. Innerhalb der Verfügbarkeitsgruppe werden die Transaktionen einer Datenbank auf eine Replikat-Datenbank auf einer anderen SQL Server-Instanz angewendet. Verfügbarkeitsgruppen dienen als Ersatz für die Datenbankspiegelung, die zwar noch unterstützt wird, aber in SQL Server 2012 veraltet ist. Die Verfügbarkeitsgruppen können auch mit Azure und Kubernetes genutzt werden, was die Sicherunsgoptionen für diese Umgebungen erweitert.
• Always-On-Failover-Cluster-Instanzen. Failover-Cluster verwenden das Windows Server Failover Cluster (WSFC)-Knoten-Framework, um Schutz auf Instanzebene zu bieten, der Datenbanken, verknüpfte Server, SQL-Server-Agent-Aufträge und andere Instanz- und Datenbankobjekte umfasst. Ein Failover-Cluster besteht aus redundanten Knoten, aber nur ein Knoten kann jeweils die WSFC-Ressourcengruppe besitzen. Ein Cluster erfordert auch ein gemeinsames Speichersystem, zum Beispiel ein Storage Area Network. Die Ausfallsicherung erfolgt automatisch und ist für die angeschlossenen Anwendungen transparent. Hier gibt es auch die Möglichkeit, Azure SQL Managed Instances für Disaster Recovery als Failover-Instanz zu verwenden.
• SQL-Server-Replikation. Die Replikation ermöglicht das Kopieren und Verteilen von Daten und Datenbankobjekten von einer Datenbank in eine andere und die anschließende Synchronisierung dieser Datenbanken. SQL Server unterstützt drei Arten der Replikation: Transaktions-, Snapshot- und Merge-Replikation. Unternehmen können die Replikation nutzen, um Daten über lokale Netzwerke, Wide Area Networks, drahtlose Verbindungen und das Internet an verschiedene Standorte zu verteilen. Die SQL-Server-Replikation verwendet den SQL-Server-Agent, um die Datenbanken und ihre Daten zu synchronisieren. 
• Log Shipping (Protokollversand). Mit dem Protokollversand können Administratoren das Transaktionsprotokoll einer Datenbank auf einer SQL-Server-Instanz automatisch auf eine oder mehrere sekundäre Datenbanken auf separaten Instanzen übertragen. Ein Monitor-Server führt Aufzeichnungen über den Verlauf und den Status von Sicherungs- und Wiederherstellungsvorgängen und gibt Warnungen aus, wenn Vorgänge fehlschlagen. Beim Protokollversand werden die Sicherungs- und Wiederherstellungsfunktionen von SQL Server verwendet, um das Transaktionsprotokoll von der primären Instanz auf die sekundären Instanzen zu kopieren. Obwohl der Protokollversand einfach zu implementieren ist, ist das Umschalten auf eine sekundäre Datenbank ein manueller Vorgang, der viel Zeit in Anspruch nehmen kann.

Viele Unternehmen setzen diese Funktionen in Kombination ein, um die Datensicherheit zu maximieren und Ausfallzeiten zu minimieren. Ein Datenbankteam könnte zum Beispiel Log Shipping zusammen mit Verfügbarkeitsgruppen einsetzen, um seine Datenbanken zu sichern. Darüber hinaus führen die meisten Unternehmen unabhängig von anderen Strategien, die sie einsetzen, Backups durch. Viele Unternehmen implementieren Disaster Recovery für SQL Server auch als Teil einer umfassenderen DR-Strategie, die Schutzmaßnahmen auf mehreren Ebenen umfasst, zum Beispiel die Konfiguration von RAID-6-Storage oder die Sicherung virtueller Maschinen, auf denen SQL Server-Instanzen laufen.

Unabhängig von der DR-Strategie, die ein Unternehmen implementiert, ist zunächst eine sorgfältige Planung erforderlich, die RTO-, RPO- und RLO-Anforderungen sowie Faktoren wie Sicherheit und Compliance berücksichtigt. Disaster Recovery geht Hand in Hand mit der Hochverfügbarkeitsstrategie eines Unternehmens, die sich auf viele der gleichen SQL-Server-Tools stützt. Unabhängig von der Art oder Größe eines Unternehmens sollte das DR oberste Priorität haben, und je besser ein Unternehmen auf den Katastrophenfall vorbereitet ist, desto wahrscheinlicher ist es, dass es ihn übersteht.