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 beschrieb ich das Vorgehen beim Offline-Backup. In diesem Teil gehe ich auf die Online-Vollsicherung ein. Dabei wird im laufenden Betrieb der Inhalt der Datenbank mit Bordmitteln des SQL-Servers gesichert.
Ablauf
- Datenbank-Prüfung
- Datenbank-Sicherung
- Archivierung der Sicherungsdateien
Datenbank-Prüfung
Wenn man die Datenbanken überprüft, dann muss man auch recht zeitnah (also am besten am nächsten Morgen) kontrollieren, ob die Prüfung Fehler entdeckte und ggf. die vorherige Sicherung besonders gut aufheben. Es wäre denkbar in dem SQL-Sicherungsskript pro Datenbank abzufragen, ob die Prüfung Fehler ergab und die Datenbank ggf. nicht zu sichern. Das erscheint mir aber unnötig mühsam. Außerdem sollte man sowieso mehrere Generationen an Sicherungen haben. Dann ist es durchaus sinnvoll auch eine defekte DB zu sichern solange die letzte korrekte Datenbanksicherung nicht überschrieben wird.
Deswegen will ich auch hier noch kurz auf das Generationenprinzip bei den wiederverwendtbaren Sicherungsmedien hinweisen: 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.
Die Datenbank-Prüfung kann durchaus im laufenden Betrieb erfolgen. Allerdings wird die Performance dadurch deutlich gedückt. Man sollte sich dazu also keine Spitzenzeiten aussuchen. Außerdem kann es bei parallelem Arbeiten vorkommen, dass ein Allokierungsfehler gemeldet wird, der keiner ist: Wenn für eine Seite die Verkettungen geprüft werden und zufällig diese verkettete Seite gleichzeitig geändert wird (z.B. aufgesplittet), dann wird das als Fehler erkannt. In so einem Fall sollte man die Prüfung einfach nochmal durchführen und schauen, ob der gleiche Fehler erneut angezeigt wird.
Datenbank-Sicherung
Mit dem Backup-Befehl wird der Inhalt der Datenbank komplett gesichert. Dazu wird der Inhalt von benutzten Seiten in die Sicherungsdatei rausgeschrieben. Weil in einer Datenbank immer etliche Seiten leer sind, ist die Sicherungsdatei erheblich kleiner als die Datenbank-Dateien. Tipp: Wenn man sie dann noch zippt, erreicht man erstaunliche Kompressionsraten.
Diese Sicherung kann im laufenden Betrieb durchgeführt werden. Dabei wird genau der Stand gesichert, der zu dem Ende der Sicherung konsistent ist. Um das hinzubekommen, muss der SQL-Server etwas in die Trickkiste greifen: einige Sperren werden aufrechterhalten, andere Seiten werden im Tranlog gesichert. Um hier die Performance zu verbessern hat Microsoft im SQL-Server-2005 den neuen Snapshot-Modus verwendet. Damit ist die Performance deutlich besser. Hier wird dann allerdings der konsistente Zustand zum Beginn der Sicherung gespeichert.
In diesem Szenario wird eine Vollsicherung durchgeführt: Es werden alle Datenseiten gesichert. Das ist besonders einfach in der Rücksicherung, kann aber schon ein Weilchen dauern. Die Performance ist ganz gut: Meiner Erfahrung nach geht das fast so schnell, wie die Kopie der Dateien auf der Platte.
Tipp: Bitte ein Passwort für die Sicherungsdateien vergeben, sonst haben es Datendiebe unnötig leicht. Andererseits sollte das Passwort nicht nur einer kennen, der jeden Morgen mit überhöhter Geschwindigkeit (und womöglich noch mit dem Motorrad) zur Arbeit rast. 🙁
Archivierung der Sicherungsdateien
Anschließend müssen die Sicherungsdateien noch auf ein dauerhaftes Medium archiviert werden. Dabei muss unbedingt darauf geachtet werden, dass die Archivierung erst nach dem Ende der SQL-Server-Sicherung beginnt. Im Einzelfall ist das gar nicht so einfach. 100%ig kann man es nur dadurch erreichen, dass die SQL-Server-Sicherung als Batch in der Pre-Phase der Datensicherungssoftware läuft.
Für die Erstellung des Skriptes sind aber SQL-Kenntnisse erforderlich.
Vorteile
- Diese Methode ist vergleichsweise schnell.
- Die Rücksicherung ist auch für die meisten Laien noch machbar sofern sie eine sehr gute Anleitung bekommen.
- Diese Methode ermöglicht einen 7x24-Stunden-Betrieb.
Risiken und Nebenwirkungen
- Für diese Sicherungsmethode muss man gruendlegende Kenntnisse über Datenbanksystemen haben.
- Man muss ein SQL-Server-Werkzeug verwenden oder SQL beherrschten und mit der "normalen" Sicherung koordinieren.
- Die Dauer kann bei sehr großen Datenbanken recht lange werden. Mann muss also auf jeden FAll mal testen, wie lange das auf der eigenen Hardware dauert, bevor man sich dafür entscheidet.
Mein persönliches Resümee:
Ich finde diese Methode recht gut, aber würde die nur empfehlen, wenn jemand mit dem SQL-Server per "Du" ist oder man einen 24-Stunden-Betrieb benötigt. In diesem Fall sollte in dem Büro aber wenigstens ein Selfmade-Admin vorhanden sein, der bereit ist sich da reinzuarbeiten…
Im vierten Teil gehe ich auf die inkrementelle und die differentielle Online-Sicherung ein.
