Wie SQL-Server-Datenbanken am besten gesichert werden
Eine solide Strategie für die Notfall-Wiederherstellung von Daten kann über die Existenz eines Unternehmens entscheiden. Neben den üblichen Regeln für die Datensicherung gibt es bei SQL-Server-Datenbanken auch spezifische Best Practices, die Stefan Rabben, Autor dieses Gastbeitrags für silicon.de, erklärt.
Datenverluste durch technische Probleme oder Cyberangriffe werden sehr leicht existenzbedrohend, so dass aktuelle Datensicherungen grundlegend für die Bewältigung der Krisensituation sind. Eine Disaster-Recovery-Strategie muss dann dafür sorgen, dass Datensicherungen vorhanden, konsistent und jederzeit schnell wiederherstellbar sind.
Eine solide Strategie für die Notfall-Wiederherstellung von Daten kann über die Existenz eines Unternehmens entscheiden. Neben den üblichen Regeln für die Datensicherung gibt es aber auch spezifische Best Practices, die bei SQL-Server-Datenbanken zu befolgen sind.
Die bewährten Best Practices für eine wirkungsvolle Datensicherung sind bekannt: Sicherungen stets getrennt von den Quelldaten aufbewahren, gegebenenfalls auch an Offsite-Standorten; je kritischer die Daten, desto öfter Backups durchführen; die Wiederherstellbarkeit der Daten prüfen; Sicherungsmedien mit Redundanzen vorsehen.
Diese allgemeinen Regeln für das Vorgehen bei der Datensicherung müssen beim Einsatz von Microsoft-SQL-Server-Datenbanken um zusätzliche Maßnahmen ergänzt werden. Für Sicherung und Wiederherstellung seiner Daten kennt der SQL Server mehrere Verfahren, die teilweise auf dem Transaktionsprotokoll beruhen. Für die korrekte Rekonstruktion der Datenbank muss zuvor ein Wiederherstellungsmodell ausgewählt werden. Es gibt an, auf welche Weise die Sicherung und Wiederherstellung von Datenbanken durchgeführt wird.
SQL Server bietet von Haus aus drei Wiederherstellungsmodelle: einfach, vollständig und massenprotokolliert. Für die meisten Datenbanken sind nur das einfache und vollständige Wiederherstellungsmodell üblich.
Das einfache Wiederherstellungsmodell
Beim einfachen Wiederherstellungsmodell werden die Transaktionsprotokolle nicht gesichert, und zur Erleichterung der Administration wird der Protokollspeicher regelmäßig wieder freigegeben. Deshalb lassen sich die Transaktionsprotokolle nicht für die Wiederherstellung einsetzen, sondern lediglich die Daten. Dieses Wiederherstellungsmodell eignet sich nur für Datenbanken, die selten geändert werden. Für geschäftskritische ERP– oder CRM-Datenbanken hingegen ist es ungeeignet.
Das vollständige Wiederherstellungsmodell
Beim vollständigen Wiederherstellungsmodell wird, im Unterschied zum einfachen Wiederherstellungsmodell, neben der Datenbanksicherung auch eine Protokollsicherung durchgeführt. Daher lassen sich hier die Transaktionsprotokolle zur Wiederherstellung einsetzen.
Die Wiederherstellung bis zu einem beliebigen Zeitpunkt ist möglich, etwa die Rückführung der Datenbank in den Zustand vor einem Anwendungs- oder Benutzerfehler. Allerdings muss die Protokollsicherung regelmäßig ausgeführt werden, da die Log-Dateien permanent anwachsen und immer mehr Speicherplatz belegen. Erst nach der Protokollsicherung wird er wieder freigegeben.
All diese Vorgänge sollten zur Steigerung der Prozessqualität automatisiert werden, beispielsweise mit NetVault Backup, einer Sicherungs- und Wiederherstellungslösung von Dell, für die es ein spezielles SQL-Server-Plug-in gibt.
Das massenprotokollierte Wiederherstellungsmodell
Eine Besonderheit ist das massenprotokollierte Wiederherstellungsmodell. Hier gibt es wie beim vollständigen Modell eine Protokollsicherung. Das Modell reduziert aber die Speicherauslastung durch den Einsatz minimaler Protokollierung für die meisten Massenvorgänge. Aus diesem Grunde ist es nur in besonderen Situationen wie dem geplanten Import von größeren externen Datenbanken sinnvoll. Für den Alltagsbetrieb hat es keine besonderen Vorteile.
Damit das vollständige (und das massenprotokollierte) Wiederherstellungsmodell korrekt arbeitet, ist eine wichtige Vorkehrung zu treffen: Mit dem SQL Server Agent muss ein regelmäßiger Sicherungsplan für die Logdatei eingerichtet werden. Sie sollte mindestens einmal täglich gesichert werden, unter Umständen auch öfter. Nur dann führt der Server die Protokollsicherung ohne Unterbrechung aus.
Falls es zu Speicherplatzproblemen kommt, unterbricht SQL Server seine Arbeit und nimmt die Datenbank offline. Aus diesem Grund ist es wichtig, die Größe der Protokolle zu überwachen und sie bei Bedarf manuell zu kürzen. Nach der Freigabe von Speicherplatz ist aber eine vollständige Datenbanksicherung nötig, um Datenverluste bei der Wiederherstellung zu vermeiden.
