Im ersten Teil der Serie "Vorschläge zur Datensicherung mit SQL-Server" habe ich ein paar Dinge zum Umfeld und zum Verständnis geschrieben. Im zweiten Teil will ich das Vorgehen beim Offline-Backup beschreiben.

Das Offline-Backup wird üblicherweise über Nacht durchgeführt, weil ja niemand in der Zeit des Backup arbeiten kann. Damit ergibt sich schon gleich die wichtigste Einschränkung: Wenn man ein 24x7-Szenario (es wird "rund-um-die-Uhr" gearbeitet) hat, dann kann es nicht eingesetzt werden.

Grundsätzlich sollte man gekoppelt mit dem Backup möglichst auch eine Datenbank-Überprüfung durchführen. Damit man weiss, ob die gesicherte(n) Datenbank(en) auch in Ordnung waren. Daher ergibt sich üblicherweise folgender Ablauf, der z.B. als Batch ausgeführt werden kann:

  • Datenbanken überprüfen
  • SQL-Server-Dienst stoppen
  • Datenbank-Dateien sichern
  • Dienst neu starten
  • Nacharbeiten

Datenbanken überprüfen

Wenn man die Datenbanken überprüft, dann muss man am nächsten Morgen kontrollieren, ob die Prüfung Fehler entdeckte und ggf. die vorherige Sicherung besonders gut aufheben… Weil,die Sicherung nicht mittels SQL-Mitteln durchgeführt wurde kann der Sicherungsteil nicht oder nur in Ausnahmefällen (z.B. nur eine Datenbank) auf die Prüfung reagieren. Deswegen wurde die Datenbank auf jeden Fall gesichert, selbst wenn es sich dabei um eine defekte Datenbank handelt.

Es versteht sich eigentlich von selbst, aber zur Sicherheit hier noch der genereller Hinweis bei wiederverwendtbaren Medien: Bitte immer mehrere Sicherungsbänder verwenden und die Sicherungen von bestimmten Stichtagen generell aufheben. Beispielsweise könnte man 10 Generationen verwahren: Mo, Di, Mi, Do, Fr, Mo, Di, Mi, Do, Fr. Die Wochenendsicherungen werden dann dauerhaft archiviert: KW23, KW24, KW25, …

Dann kann man bei versehentlichem Löschen die Daten der letzten zwei Wochen tagesaktuell restaurieren und ältere Daten wochengenau.
Wenn man kein SQL kann, dann kann man diesen Schritt auch weglassen, aber sollte vielleicht öfters mal eine Generation der Sicherungen archivieren, z.B. Mittwochs und Samstags… 😛

SQL-Server-Dienst stoppen

Ich bin ein Fan der Kommandozeile, z.B. "net stop mssql$mytestsql", aber hier gibt es beliebige Freiheiten.

Datenbank-Dateien sichern

Das Sichern ist hier denkbar einfach. Dazu werden alle Dateien der zu sichernden Datenbanken gesichtert: MDF, LDF und, falls vorhanden, NDFs. Wichtig beid er Rücksicherung ist, dass immer alle Dateien einer Datenbank konsistent zurückgesetzt werden. Man darf keine unterschiedlichen Stände mischen.

Ich würde empfehlen die Dateien zunächst in ein Verzechnis auf einer anderen Platte zu sichern und von dort zu archivieren. Das reduziert die Down-Zeit erheblich, kostet aber unter umständen viel Plattenplatz.

SQL-Server-Dienst starten

Wieder irgendwie, z.B. auf der Kommandozeile mittels "net start mssql$mytestsql".

Nacharbeiten

Die Dateien werden nur zu diesem Zeitpunkt gesichert und vorbei am SQL-Server. Daher muss man beachten, dass der "Recovery-Modus" der zu sichernden Datenbank darauf abgestimmt ist. Hat man als Recovery-Modus "Full" oder "Bulk-Logged" gewählt, dann wird das Transaktionslog der Datenbank sehr schnell sehr groß. Deswegen muss man in diesem Fall noch das Transaktionslog der (hoffentlich) erfolgreich gesicherten Datenbanken "abschneiden".

Statt dessen kann man auch den Modus "Simple" verwenden. Hier werden im Transaktionslog nur die Daten der Transaktionen gespeichert, die noch nicht im Rahmen eines Checkpoint auf die Platte geschrieben wurden. Damit entfällt das Nachbearbeiten.

Datenbanken am "SQL Server 2000" haben als Default den Modus, wenn sie an eine MSDE angehängt werden, und "Full", wenn sie an eine Standard- oder Enterprise-Edition angehängt wurden. Beim 2005er habe ich das noch nicht überprüft. Ich gehe davon aus, dass es immer noch so ist.

Vorteile dieser Vorgehensweise

  • Sie wird auch von Laien verstanden.
  • Für die Rücksicherung werden keine Datenbank-Kenntnisse benötigt: Einfach Dienst stoppen, die Dateien zurückkopieren, Dienst starten, fertig.
  • Es ist kein SQL-Server-Verwaltungswerkzeug notwendig.
  • Sie ist schnell.

Risiken und Nebenwirkungen

  • Während der Down-Phase kann nicht mit den datenbanknutzenden Anwendungen gearbeitet werden.
  • Die Kopplung mit dem Recovery-Modus "Simple" bietet sich an. Das führt dazu, dass im Crashfall immer auf den letzten Sicherungsstand zurückgesetzt werden muss. Man verliert also vermutlich einen Tag Arbeit.
  • Die Datenbank-Dateien werden komplett kopiert, nicht nur die gefüllten Seiten, wie beim Online-Backup. Daher wird mehr Platz auf dem Sicherungsmedium benötigt.
  • Sollte in ein anderes Verzeichnis kopiert werden, dann muss dort immer ausreichend Platz zur Verfügung stehen, sonst scheitert die Sicherung. In gewissen Weise ist das bei der Online-Sicherung auch so.
  • Sollte der Dienst nicht gestoppt werden, dann werden die Dateien nicht kopiert.
  • Im Falle der Rücksicherung verliert man die Arbeit seit dem Datum der letzten Sicherung erledigt wurde. Daher sollte man jede Nacht sichern…

Mein persönliches Resümee:

Diese Art der Sicherung eignet sich besonders für EDV-Laien, die mittlere Anforderungen an die Datenverfügbarkeit haben. Insbesondere die einfache Art der Rücksicherung ist ein großes Plus. (Hinweis: Die Daten-Rücksicherung sollte unbedingt einmal getestet werden… :-))

Im dritten Teil werde ich die Online-Datensicherung beschreiben.