{"id":46,"date":"2006-07-15T20:11:26","date_gmt":"2006-07-15T18:11:26","guid":{"rendered":"http:\/\/www.glorf.it\/blog\/2006\/07\/15\/sql-talk\/db-defekte\/ursachen-fur-datenbank-defekte-teil-3\/"},"modified":"2006-07-18T22:25:57","modified_gmt":"2006-07-18T20:25:57","slug":"ursachen-fur-datenbank-defekte-teil-3","status":"publish","type":"post","link":"http:\/\/www.glorf.it\/blog\/2006\/07\/15\/sql-talk\/db-defekte\/ursachen-fur-datenbank-defekte-teil-3","title":{"rendered":"Ursachen für Datenbank-Defekte (Teil 3)"},"content":{"rendered":"

Nach den eher skurrilen Gründen im ersten Teil<\/a> der Serie über Ursachen für Datenbank-Defekte und den Festplatten im zweiten Teil<\/a>, geht es heute um Datenverluste durch eine defekte Datensicherung<\/strong>. <\/p>\n

Natürlich führt die Datensicherung<\/strong> 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.
\nUnter 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.
\nIn 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.<\/p>\n

Aber viel öfter machte die Rücksicherung<\/strong> 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. \ud83d\ude09<\/p>\n

Hintergrund ist, dass wir schon so oft den Fall hatten, dass die zurückgesicherten Dateien fehlerhaft waren. <\/p>\n