Share via

  • Artikel

Planen der Wiederherstellung im Notfall

Beim Verwalten einer SQL Server-Datenbank stellt die Vorbereitung für die Wiederherstellung nach potenziellen Notfällen einen wichtigen Aspekt dar. Für die Wiederherstellung der Datenbanken nach einem Notfall ist ein sorgfältig konzipierter und geprüfter Sicherungs- und Wiederherstellungsplan für Ihre SQL Server-Sicherungen erforderlich. Weitere Informationen finden Sie unter Einführung zu Sicherungs- und Wiederherstellungsstrategien in SQL Server. Damit sichergestellt werden kann, dass im Falle einer Naturkatastrophe alle Systeme und Daten schnell für den Normalbetrieb wiederhergestellt werden können, müssen Sie einen Plan für die Wiederherstellung im Notfall erstellen. Beim Erstellen des Plans sollten Sie verschiedene Arten von Notfallszenarien in Erwägung ziehen, die Auswirkung auf Ihr Unternehmen haben können. Dazu gehören natürliche Katastrophen (z. B. ein Brand) sowie technische Notfälle (z. B. der Ausfall zweier Datenträger in einem RAID-5-Array). Wenn Sie einen Plan zur Wiederherstellung im Notfall erstellen, müssen Sie alle für die einzelnen Notfallarten notwendigen Schritte ermitteln und vorbereiten. Die für die einzelnen Wiederherstellungsszenarien notwendigen Schritte sollten auf jeden Fall getestet werden. Es wird empfohlen, dass Sie den Plan für die Wiederherstellung im Notfall durch die Simulation einer Naturkatastrophe überprüfen.

Die Planung für die Sicherung und Wiederherstellung im Notfall sollte unter Berücksichtigung der speziellen Umgebung und den Unternehmensanforderungen erfolgen. Angenommen, bei einem Brand wird Ihr Datenzentrum, das rund um die Uhr betrieben wird, zerstört. Sind Sie sicher, dass alle Daten wiederhergestellt werden können? Wie lange brauchen Sie für das Wiederherstellen, bis das System wieder verfügbar ist? Welcher Datenverlust ist für die Benutzer vertretbar?

Im Idealfall gibt der Plan für die Wiederherstellung im Notfall an, wie lange die Wiederherstellung dauert und welchen Status der Datenbanken die Benutzer am Ende der Wiederherstellung erwarten dürfen. Sie können z. B. angeben, dass nach dem Erwerb bestimmter Hardware die Wiederherstellung in 48 Stunden abgeschlossen sein wird und dass die Wiederherstellung der Daten nur bis zum Ende der vorhergehenden Woche sichergestellt wird.

Ein Plan für die Wiederherstellung im Notfall kann auf sehr unterschiedliche Weise strukturiert sein und vielfältige Informationen enthalten. Zu den Planarten für die Wiederherstellung im Notfall gehören:

  • Ein Plan für den Erwerb von Hardware.

  • Ein Kommunikationsplan.

  • Eine Liste der Kontaktpersonen bei einem schwerwiegenden Zwischenfall.

  • Anweisungen zum Kontaktieren der Verantwortlichen als Reaktion auf einen schwerwiegenden Zwischenfall.

  • Informationen zu den Verantwortlichen für die Verwaltung des Plans.

  • Eine Checkliste der für die einzelnen Wiederherstellungsszenarien erforderlichen Aufgaben. Damit Sie den Überblick über den Status der Wiederherstellung behalten, zeichnen Sie jede Aufgabe nach Abschluss ab, und geben Sie in der Checkliste die Zeit des Abschlusses an.

SQL Server-Wiederherstellungsmodelle

In SQL Server werden drei alternative Wiederherstellungsmodelle bereitgestellt: einfach, vollständig und massenprotokolliert. Bei einem Wiederherstellungsmodell handelt es sich um eine Datenbankeigenschaft, mit der das grundlegende Verhalten einer Datenbank bei Sicherungs- und Wiederherstellungsvorgängen gesteuert wird. Die Auswahl des optimalen Wiederherstellungsmodells für jede Ihrer Datenbanken ist beim Planen der jeweiligen Sicherungs- und Wiederherstellungsstrategie von zentraler Bedeutung. Die Auswahl eines Wiederherstellungsmodells für eine bestimmte Datenbank hängt zu einem gewissen Grad von Ihren Anforderungen hinsichtlich Verfügbarkeit und Wiederherstellung ab. Die Auswahl des Wiederherstellungsmodells hat wiederum Auswirkungen darauf, welche Möglichkeiten für eine Datenbank bei der Wiederherstellung im Notfall bestehen.

Eine Einführung zu Wiederherstellungsmodellen finden Sie unter Übersicht über Wiederherstellungsmodelle.

Verwalten von Sicherungsmedien

Es wird empfohlen, dass im Sicherungsplan folgende Maßnahmen zur Verwaltung von Sicherungsmedien enthalten sind:

  • Einen Nachverfolgungs- und Verwaltungsplan zum Speichern und Wiederverwerten von Sicherungssätzen.

  • Einen Zeitplan für das Überschreiben von Sicherungsmedien.

  • In einer Multiserverumgebung die Entscheidung, ob zentrale oder verteilte Sicherungen verwendet werden sollen.

  • Ein Mittel zum Nachverfolgen der Lebensdauer von Medien.

  • Ein Verfahren, um die Auswirkungen bei Verlust eines Sicherungssatzes oder bei Verlust von Sicherungsmedien (z. B. Verlust eines Bands) zu minimieren.

  • Die Entscheidung darüber, ob Sicherungssätze vor Ort oder außerhalb des Standorts gespeichert werden sollen, und eine Analyse der Auswirkungen auf die Wiederherstellungszeit.

Weitere Informationen zum Verwenden von Sicherungsgeräten und -medien in SQL Server finden Sie unter Arbeiten mit Sicherungsmedien in SQL Server.

Ausführen von Basisfunktionalitätsskripts

Für gewöhnlich binden Sie ein Basisfunktionalitätsskript in den Plan zur Wiederherstellung im Notfall ein, um die Funktionsfähigkeit zu bestätigen. Ein Basisfunktionalitätsskript stellt ein zuverlässiges Tool für System- und Datenbankadministratoren bereit, die damit überprüfen können, ob die Datenbank wieder einen verlässlichen Status erreicht hat, und nicht erst auf eine Bestätigung vonseiten der Endbenutzer warten müssen.

Basisfunktionalitätsskripts sind anwendungsspezifisch und können sehr unterschiedliche Formen aufweisen. So kann das Skript bei einem Entscheidungsunterstützungs- oder Berichtsystem lediglich eine Kopie einiger der wichtigsten Berichtsabfragen sein. Bei einer OLTP-Anwendung (Online Transaction Processing, Onlinetransaktionsverarbeitung) kann das Skript hingegen einen Batch gespeicherter Prozeduren für INSERT-, UPDATE- und DELETE-Anweisungen ausführen. Ein Basisfunktionalitätsskript kann beispielsweise so einfach wie eine SQL-Datei sein, die SQL-Anweisungsbatches vom Dienstprogramm sqlcmd an den Server sendet. Ein weiteres Beispiel ist das Verwenden von BAT-Dateien, in denen sowohl bcp- als auch osql-Befehle enthalten sind.

Sicherstellen der Notfallbereitschaft

Damit Sie sicherstellen können, ob Sie für Notfälle vorbereitet sind, empfiehlt es sich, in regelmäßigen Abständen folgende Vorgänge auszuführen:

  • Testen Sie Ihre Sicherungs- und Wiederherstellungsprozeduren gründlich und rechtzeitig, bevor ein Betriebsausfall auftritt. Mithilfe dieser Tests stellen Sie sicher, dass Sie die für unterschiedliche Betriebsstörungen erforderlichen Sicherungen zur Wiederherstellung besitzen, dass die Prozeduren eindeutig definiert und dokumentiert sind und dass diese durch einen qualifizierten Operator schnell und einfach ausgeführt werden können.

  • Führen Sie regelmäßige Sicherungen der Datenbank und des Transaktionsprotokolls aus, um den Datenverlust zu minimieren. Es wird empfohlen, sowohl von System- als auch von Benutzerdatenbanken eine Sicherung zu erstellen.

  • Verwalten Sie Systemprotokolle auf sichere Art. Notieren Sie, welche Service Packs unter Microsoft Windows und SQL Server installiert sind. Notieren Sie, welche Netzwerkbibliotheken und welcher Sicherheitsmodus verwendet werden. Wenn SQL Server mit der Authentifizierung im gemischten Modus ausgeführt wird (die Modi SQL Server- und Windows-Authentifizierung), heben Sie auch das sa-Kennwort an einem sicheren Ort auf. Weitere Informationen finden Sie unter Sicherheit und Schutz (Datenbankmodul).

    Wichtiger HinweisWichtig

    Die Windows-Authentifizierung bietet deutlich mehr Sicherheit als die SQL Server-Authentifizierung. Verwenden Sie nach Möglichkeit die Windows-Authentifizierung.

  • Bei anderen Servern müssen Sie die zur Wiederherstellung im Notfall notwendigen Schritte abschätzen. Gegebenenfalls müssen Sie die Schritte auf die Erfordernisse der lokalen Serverumgebung abändern, und die abgeänderten Schritte dann testen.

  • Warten Sie ein Basisfunktionalitätsskript, um die Minimalfunktionen rasch bewerten zu können.

Überwachen und Reduzieren von potenziell katastrophalen Benutzerfehlern

Eines der problematischeren Wiederherstellungsszenarien ist die Wiederherstellung nach einem schwerwiegenden Benutzerfehler, wie z. B. im Fall von versehentlich gelöschten Datenbankobjekten. In diesem Abschnitt werden Tools vorgestellt, die Ihnen beim Überwachen und, in einigen Fällen, beim Regulieren von Änderungen an Datenbanken helfen können.

  • DDL-Trigger (Data Definition Language oder Datendefinitionssprache)

    Diese Trigger können zum Überwachen und Regulieren bestimmter Änderungen am Datenbankschema erstellt werden. Als Reaktion auf verschiedene DDL-Anweisungen werden von DDL-Triggern gespeicherte Prozeduren ausgelöst. Bei diesen Anweisungen handelt es sich hauptsächlich um diejenigen, die mit CREATE, ALTER und DROP beginnen. Der Geltungsbereich eines DDL-Triggers ist entweder eine bestimmte Datenbank oder eine vollständige Serverinstanz. Weitere Informationen finden Sie unter Grundlegendes zu DDL-Triggern.

  • Ereignisbenachrichtigungen

    Ereignisbenachrichtigungen werden als Antwort auf eine Vielzahl von Transact-SQL DDL-Anweisungen und Ereignissen der SQL-Ablaufverfolgung ausgeführt und senden Informationen zu diesen Ereignissen an einen Service Broker-Dienst.

    Ereignisbenachrichtigungen können für viele der Ereignisse programmiert werden, die von der SQL-Ablaufverfolgung erfasst werden. Im Gegensatz zum Erstellen von Ablaufverfolgungen können Sie jedoch mithilfe von Ereignisbenachrichtigungen eine Aktion innerhalb einer Instanz von SQL Server als Antwort auf Ereignisse ausführen. Ereignisbenachrichtigungen werden asynchron ausgeführt, weshalb diese Aktionen keine Ressourcen belegen, die durch die unmittelbare Transaktion definiert werden. Weitere Informationen finden Sie unter Ereignisbenachrichtigung (Datenbankmodul).

    HinweisHinweis

    Nicht alle DDL-Ereignisse können in DDL-Triggern verwendet werden. Einige Ereignisse sind ausschließlich für asynchrone, nicht transaktive Anweisungen konzipiert. Ein CREATE DATABASE-Ereignis kann z. B. nicht in einem DDL-Trigger verwendet werden. Für solche Ereignisse sollten Sie Ereignisbenachrichtigungen verwenden.

  • SQL Server-Agent

    Es handelt sich dabei um einen Windows-Dienst, mit dem geplante administrative Tasks ausführt werden, die als Aufträge bezeichnet werden. Der SQL Server-Agent verwendet SQL Server, um Auftragsinformationen zu speichern. Der SQL Server-Agent kann u. a. einen Auftrag als Antwort auf ein bestimmtes Ereignis ausführen, z. B. Fehler mit einem bestimmten Schweregrad oder einer bestimmten Meldungsnummer.

    Eine Einführung in den SQL Server-Agent finden Sie unter Automatisieren administrativer Tasks (SQL Server-Agent). Informationen zum Verwenden des SQL Server-Agents für Ereignisse finden Sie unter Überwachen von und Reagieren auf Ereignisse.

  • SQL-Ablaufverfolgung

    Die SQL-Ablaufverfolgung stellt zum Erstellen von Ablaufverfolgungen für eine Instanz von SQL Server Database Engine (Datenbankmodul) gespeicherte Transact-SQL-Systemprozeduren zur Verfügung. Sie können diese gespeicherten Systemprozeduren aus Ihren Anwendungen heraus verwenden, um Ablaufverfolgungen manuell zu erstellen. Weitere Informationen finden Sie unter Einführung in die SQL-Ablaufverfolgung.

    HinweisHinweis

    SQL Server Profiler ist eine grafische Benutzeroberfläche für die SQL-Ablaufverfolgung zur Überwachung einer Instanz von Database Engine (Datenbankmodul) oder Analysis Services. Weitere Informationen finden Sie unter Verwenden von SQL Server Profiler.