Nach den eher skurrilen Gründen im ersten Teil der Serie über Ursachen für Datenbank-Defekte und den Festplatten im zweiten Teil, geht es heute um Datenverluste durch eine defekte Datensicherung.
Natürlich führt die Datensicherung selber nur sehr selten zu Problemen, aber es kam durchaus schon bei unseren Kunden vor. Als wir noch den Sybase SQL Server einsetzten kam es mehrfach vor, dass wir sehr seltsame Effekte bei Kunden feststellten, die vermutlich auf die Datensicherung zurückzuführen waren. Die meisten davon traten allerdings unter Novell NetWare (Friede seiner Asche) auf.
Unter Windows 2000 hatten wir einmal einen Fall bei dem im Errorlog des "Sybase SQL Anywhere" jede Menge Informationen aus dem Sicherungsprotokoll der Sicherungssoftware standen. Das hat mich damals sehr gewundert, weil der SQL-Anyhwere-Dienst die ganze Zeit lief und die Errorlog-Datei exklusiv geöffnet hatte. Ich hatte bis dahin gedacht, dass sich ein Prozess nicht so einfach Zugang zu anderen Dateien verschaffen kann. Den Trick mit den Hooks habe ich erst später gelernt.
In einem anderen Fall wurden die Datenbanken vor dem nächtlichen Backup geprüft (keine Fehler), dann wurde der Dienst gestoppt, die Dateien gesichert und der Dienst wieder gestartet. Am nächsten Morgen konnte man mit einer der Datenbanken nicht mehr arbeiten. Hier war es so, dass man mit dem Hex-Editor erkennen konnte, dass einfach Schrott in der Datenbank stand. Für mich sahen es wie Fragmente eines Word-Dokumentes aus. Als ob da jemand etwas durcheinander gebracht hätte… Aber wir konnten nie beweisen, dass es die Sicherungssoftware war. Deswegen nenne ich auch keine Namen.
Aber viel öfter machte die Rücksicherung bei Kunden Ärger. Deswegen würde ich empfehlen die Rücksicherung nie in das originale Verzeichnis zu machen oder wenn schon, dann das Original wenigstens vorher umzubenennen. Am besten man macht vor der Rücksicherung eine Datensicherung. 😉
Hintergrund ist, dass wir schon so oft den Fall hatten, dass die zurückgesicherten Dateien fehlerhaft waren.
- Häufig genug hatten die Kunden beim Backup kein "Verify" eingestellt ("Das dauert dann so lange!").
- Der SQL-Server-Dienst wurde nicht gestoppt, die Datenbank-Dateien waren im Zugriff und wurden nicht gesichert. Das Protokoll nicht kontrolliert.
- Es wurden immer die gleichen (kaputten) Bänder genommen.
- Beim Sichern waren die Daten noch OK, während der (sachgemäßen?) Lagerung ruderten die DVDs rüber.
Und warum machen die überhaupt eine Rücksicherung? Na, z.B. weil ein Mitarbeiter versehentlich etwas zu viel gelöscht hat…
Naja, und wenn man dann die kaputte Dateien über die Originale geschrieben werden, dann ist das Jammern groß. Komischweise sind das dann auch die Kunden, die keine weitere Sicherung haben… Vielleicht mache ich mal eine Serie zum Thema Datensicherung. Aber das Lesen ja doch bloß die, die schon eine Sicherung machen: der Pfarrer predigt immer nur vor den Frommen!
Demnächst geht es weiter …