Backups

Vor zehn Jahren habe ich den letzten Eintrag in dieser Kategorie verfasst. Seit dem hat sich vor allem ein relevantes Produkt durchgesetzt: Die SSD. Und SSDs machen uns glücklich.

Aber sie haben auch einen Makel. Festplatten als quasi mechanische Datenträger geben fast immer graduell den Geist auf und kündigen ihr Ableben durch Zunahme defekter Sektoren, Sing- oder Kreischgeräusche oder auffallend hohe Zugriffszeiten an. Man beachte das Kopfbild dieses Blogs. Die Hersteller haben mehrere Jahrzehnte Erfahrung mit der Steuerung der Scheiben und Köpfe, und Datenrettungsfirmen können sie mit Ersatzteilen auslesen oder die Oberflächen der Plattern abtasten.

SSDs hingegen können durch Firmwarefehler spontan das Zeitliche segnen. Im schlimmsten Fall war's das dann, die Platte meldet sich gar nicht mehr. Ob man durch Auflöten eines neuen Controllerchips etwas retten kann? Sehr wahrscheinlich nicht, da der Inhalt fast immer automatisch verschlüsselt wird.

Speichert man Daten auf SSDs braucht man also besonders frische Backups.

Dass solche Ausfälle in der Anfangszeit gelegentlich vorkamen, konnte man verzeihen. Inzwischen, sollte man meinen, haben die Hersteller das im Griff. Doch: Vor einiger Zeit machten Berichte über Probleme mit Samsung-SSDs der 990-Pro-Serie die Runde. Ausgerechnet, denn Samsung hat eigentlich einen guten Ruf.

Vor einigen Stunden wurde ich durch ein Video von JayzTwoCents darauf aufmerksam, dass auch die 980-Pro-Serie von Fehlern betroffen ist, sofern das Laufwerk eine Größe von 2TB hat und mit Firmware-Version 3B2QGXA7 läuft. Das ist bei solchen, die 2021 produziert wurden, ziemlich sicher der Fall.

Die fehlerhafte Firmware registriert irrtümlich Speicherblöcke als defekt und sperrt irgendwann das Laufwerk gegen Schreibzugriffe. Irreversibel. Hässlich. Aber: Ein rechtzeitiges Firmware-Update kann Probleme vermeiden.

Da fiel mir der kleine schwarze Karton ein, der nur wegen Zeitmangel noch ungeöffnet bei mir herumliegt. Mal reingucken...



Ups! In wenigen Tagen hätte ich nichtsahnend die SSD verbaut und vermutlich nicht als erstes die Firmware aktualisiert. o.O

Vor ein paar Tagen wollte ich endlich auch für mein Smartphone eine vernünftige Backup-Prozedur einrichten. Also habe ich ein paar Euro für eine Pro-Version von TitaniumBackup (siehe auch hier) ausgegeben. Die Anwendung sollte vollständige Backups erstellen und diese automatisch auf ein Netzlaufwerk schieben. Ein automatisierter Vorgang ist bequem und könnte vielleicht auch mal bei einem defekten Bildschirm helfen.

TitaniumBackup streikte. Ich ignorierte die Warnungen, dies bei meinem Cynogenmod auf keinen Fall zu versuchen, und probierte ein BusyBox-Update — ein wirklich dummer Fehler. Damit habe ich das BusyBox-Binary durch ein ungeeignetes ersetzt und damit mein Android und das Recovery-System 2ndInit gleich mit zerschossen. An die Daten, die nicht auf der SD-Karte, sondern im internen Speicher abgelegt sind, wie SMS und Kontakte, heranzukommen, erschien zunächst aussichtslos. Ich habe dann aber doch eine Lösung gefunden.


Ein automatisches Backup einzurichten sollte eine der ersten Aufgaben an einem System sein, nicht eine der letzten. Und Smartphones sind schnell weg oder kaputt.

Hier haben wir mal wieder einen Fall von "hätte ich ein Backup..." Der arme Mann fragt nun per Blog und Twitter, was er tun soll:

Mindestens ein Mal im Jahr zerschießt es meinen Windows XP Rechner. Genauer gesagt ist und war es meist die Festplatte, die aus einem mir nicht nachvollziehbarem Grund ihren Geist aufgibt und mir nun jede Menge Daten, als auch nicht extern gesicherte Fotos vorenthält. Ein persönliches Drama sozusagen an dem ich natürlich selbst dran Schuld bin. Daten zu sichern war bisher nicht meine Stärke ,(

Kein Backup, und Windows macht das regelmäßig. Was soll man dazu noch sagen?

TOLD YOU SO!

Vor einiger Zeit bekam fand ich nach dem Anschließen einer USB-Festplatte den Fehler "Buffer I/O error on device" im Syslog. Eine Websuche förderte diesen bemerkenswert halbwahren Beitrag hervor:

Ein Festplattencrash unter Linux sieht im Log i.d.R. folgendermaßen aus

Unter einem Crash versteht man dann doch etwas anderes als einen Ein-/Ausgabefehler. Der Fehler ist harmlos und tritt bei bestimmten Chipsätzen, welche offenbar überwiegend in USB-Adaptern verbaut werden, auf und wird seit Kernel-Version 2.6.20 korrekt behandelt.

In oben verlinktem Beitrag geht es dann mit einem schlauen Tipp weiter:

Das bedeutet i.d.R. nichts gutes und es hilft meist nur eines: Server herunterfahren und wenn möglich, ein Festplatten Testtool durchlaufen lassen, um den Fehler genauer zu lokalisieren und die HDD ggf. nochmal fit zu kriegen. Sollte dies gelingen, schleunigst ein Backup der Daten machen und die Harddisk anschließend austauschen.

Das ist gleich auf mehrere Arten falsch. Sollte der Fehler im laufenden Betrieb plötzlich auftreten, dann ist Datenverlust zu befürchten, und man macht natürlich sofort ein Backup. Ausschalten sollte man den Rechner auf gar keinen Fall, da es Festplattendefekte gibt, die erneutes Anlaufen des Motors verhindern. Die Platte mittels irgendeines "Tools" wieder flottzukriegen hätte ich ebenfalls keine Hoffnung.

Der einzige mir bekannte Fall, in dem Software mehr tun konnte, als nur das baldige Ableben der Festplatte zu prophezeien, ist ein Firmware-Fehler, wie er vor einiger Zeit bei einigen Seagate-Modellen auftrat. Sehr lästig und gefährlich, wenn man ein RAID aus genau diesen Festplatten betreibt.

Wegen eines Fehlers beim Umkopieren eines großen Datenbestands sind mir die Änderungszeitstempel (modification time, mtime) abhanden gekommen. Ein weiterer guter Grund, ein Backup zu haben!

Um die Zeitstempel wiederherzustellen, ohne die Dateien selbst zu überschreiben, habe ich aus dem Backup eine Liste erzeugt, in der Dateipfade und Zeiten getrennt durch " #+# " gespeichert werden. Das geht z.B. mit stat, und zwar so:

#!/bin/sh

ifs_backup="$IFS"
TARGETDIR=/actual/place

find . | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
MODTIME=`stat -c %y "${DIRFILE}"|sed -s "s/\..*//"`
DIRFILE2="${TARGETDIR}"`echo -n "${DIRFILE}"|sed -s "s/^.//"`
echo "${DIRFILE2} #+# ${MODTIME}">> dirfilelist.txt
done


Die Einträge in dirfilelist.txt sehen dann etwa so aus:

/home/adorno/test/script.sh #+# 2009-06-06 15:23:00


Das folgende Script liest diese gespeicherten Daten und ändert die Dateien auf dem Zielsystem:

#!/bin/sh

ifs_backup="$IFS"

while true; do
COUNT=0
cat dirfilelist.txt | while IFS= read -r DIRFILE; do
IFS="$ifs_backup"
DIRFILE2=`echo "${DIRFILE}"|sed -s "s/\ #+#\ .*//"`
NEWMODTIME=`echo "${DIRFILE}"|sed -s "s/.*\ #+#\ //"`
if [ -e "${DIRFILE2}" ]; then
MODTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
touch -cm -d "${NEWMODTIME}" "${DIRFILE2}"
NEWTIME=`stat -c %y "${DIRFILE2}"|sed -s "s/\..*//"`
echo "${DIRFILE2} has modification time ${MODTIME}, changed to ${NEWMODTIME}. Result: ${NEWTIME}" >> mtimeset.log
COUNT=$((COUNT + 1))
else
echo ${DIRFILE2}" does not exist!" >> mtimeset_error.log
fi
if [ ${COUNT} -gt 10000 ]; then
echo "Deleting 10000 lines from dirfilelist.txt."
sed '10001,$w dirfilelist2.txt' dirfilelist.txt >/dev/null
mv dirfilelist2.txt dirfilelist.txt
break;
fi
done
done


Die äußere Schleife bewirkt, dass die Liste gleich um die abgearbeiteten Einträge (evtl. abzüglich einer Zeile zu wenig) bereinigt wird, verhindert aber, dass das Script terminiert. Man kann es also auch mal abbrechen, muss dafür aber die Logfiles im Auge behalten.

Die Scripte sind nicht unbedingt elegant, und natürlich gibt es viel Raum für Verbesserungen. Vor allem an der Geschwindigkeit lässt sich sicher noch etwas machen, wenn man z.B. Aufrufe von stat einspart.

Wie dem auch sei: Have a backup!

Die letzten zwei Stunden lief Chaosradio 144 "Datenträger, Datenverlust und Datenrettung — Vom magnetischen Flußwechsel zum Dokument".

Es ging um Festplattenfehler ebenso wie Anwenderfehler, um die Methoden zur Rettung der Daten, um RAID-Systeme und sogar um das zuverlässige Löschen alter Daten. Und der häufigste Tipp war: Habt ein Backup!

Robin Harris schrieb 2007 in einem Artikel bei ZDNet, dass RAID5-Systeme seiner Ansicht nach im Laufe dieses Jahres aufhören werden zu funktionieren, bzw. dass und RAID6-Systeme keine größere Sicherheit als RAID5-Systeme geben werden.

Was ist dran an der Behauptung?

Die Zahlenspielereien, die er anstellt, basieren auf der Annahme, dass die durchschnittlichen Lesefehlerraten gleich bleiben, während die Kapazitäten der Laufwerke sich immer weiter erhöhen. Dadurch steigt die Gefahr eines zweiten — fatalen — Fehlers nach dem Ausfall einer Festplatte im RAID5-Verbund. Denn nach so einem Ausfall wird das Reservelaufwerk (Spare Drive) aktiviert, und vollständig beschrieben, um den Verbund wieder zu vervollständigen.

Während dieser Wiederherstellung (Recovery) der vollen Redundanz werden die anderen Laufwerke komplett gelesen. Bei gleichbleibenden Raten von einem unbehebbaren Fehler auf etwa zwölf Terabyte Daten hat man also bereits mit sechs 2TB Laufwerken — und solche wird es im Laufe dieses Jahres geben — ein reale Chance, dass ein solcher Fehler auftritt. Der zweite Lesefehler kann seiner Ansicht nach aber das gesamte RAID5-System ruinieren.

Kurz: Die zur Rekonstruktion des RAID-Verbundes zu lesende Datenmenge steigt gegenüber der Lesefehlerrate.

Nun ist es so, dass mittlere Fehlerraten und ähnliche Kennzahlen gerne missverstanden werden. Doch ist es ohne tief in die Materie einzusteigen und eine anständige Portion Stochastik nahezu unmöglich, die Qualität von Harris' Voraussagen zu bewerten. Deswegen sollte man einen Blick auf weitere Meinungen werfen.

Am Rande erwähnt sei ein Artikel in einem Mitarbeiter-Blog von SUN Microsystems. Hier wurden verschiedene mathematische Modelle verglichen und Berechnungen für RAID-Z2 angestellt, ein Raidsystem, welches mit dem Dateisytem ZFS verbandelt ist und höhere Sicherheit vor Inkonsistenzen bei Scheibfehlern bietet. Das ist auch bei RAID-Systemen ein nicht zu vernachlässigender Punkt, denn Schreibfehler sind möglich und das wird meist nicht berücksichtigt. Der Artikel geht etwas sehr ins Detail, bestätigt Harris' Vorhersage aber zumindest teilweise.

Ein lesenswerter Artikel im Blog von subnetmask255x4 betrachtet viele Äußerungen zum Thema eher kritisch und beruhigt in sofern, dass er die Fehlerraten schneller sinken sieht, als die Kapazitäten der Laufwerke sich erhöhen. Die Annahme, dass die Fehlerraten gleichbleiben, scheint also der Haken an Harris' Prophezeiung zu sein.

Allerdings empfiehlt der Autor, lieber RAID6 statt RAID5 zu nutzen, bzw. RAID10 für den Hausgebrauch. Zudem soll man gezielt spezielle Festplatten mit geringerer Fehlerquote kaufen und natürlich Backups anlegen.

Die sind eine gute Idee, denn im Gegensatz zu RAID-Systemen schützen sie vor Dummheiten und Rechenfehlern.

Nachtrag 2009-02-28: Grundsätzlich sollte man auch bedenken, dass auch RAID5 und RAID6-Systeme nicht vor Bedienfehlern geschützt sind. Wird statt der ausgefallenen Platte vom "Bedienpersonal" versehentlich eine andere Platte entfernt, so wird das Dateisystem möglicherweise schwer beschädigt. Der RAID-Controller bzw. der Daemon gibt dann sofort auf, und überredet man ihn, den Verbund trotz der entstandenen Inkosistenz wieder in Betrieb zu nehmen, kann sonstwas passieren. Eine möglichkeit, ein Laufwerk als "half failed" zu markieren, kenne ich jedenfalls nicht.

Fefe erwähnt einen Beitrag in der WAZ, laut dem ein Jugendlicher Cracker die Webseite der fränkischen Stadt Ansbach manipuliert hat. Die WAZ schreibt:

Ein Fachmann hatte daraufhin festgestellt, dass die Seiten größtenteils vom Server gelöscht worden waren.

Für diese lapidare Feststellung braucht es offenbar auch 2008 noch einen "Fachmann". Hätte dieser Fachmann der Stadt Ansbach mal ein Backup empfohlen, dann wäre das ganze nicht so grenzenlos peinlich für die Stadt.

Felix hat vollkommen recht mit seiner Kritik daran, dass der Lausebengel laut WAZ für die Neugestaltung der Webseite aufkommen soll. Denn hier geht es nicht um die Begleichung eines durch eine Missetat entstandenen Schadens, sondern darum, dass die Stadt Ansbach grob fahrlässig die Sicherung ihrer Daten vernachlässigt hat. Damit hat sie den größten Teil des Schadens nämlich selbst verursacht.

Man vergleiche das ganze zur Verdeutlichung mit einem maroden Staudamm, der durch den Steinwurf eines Kindes zusammenbricht und ein Dorf wegspült. Dann das Kind als schwerkriminell hinzustellen, weil ja schließlich Menschen gestorben seien, wäre schon arg mittelalterlich.

Kurz: Man muss zwischen Verursacher und Auslöser unterscheiden. Ich hoffe mal, die Juristen bekommen das hin.

Bruce Schneier erwähnt einen weiteren Grund, regelmäßig Backups zu machen: Ransomware. Das sind Viren, die einem die Daten verschlüsseln um ein Lösegeld zu erpressen. Das ist eine schlimme Sache, da man im Gegensatz zu einem fatalen Hardware-Fehler weiß, dass man die Daten wiederbekommen könnte. Wer ein Backup hat, muss sich natürlich nicht erpressen lassen.

Doch die Menschen machen keine Backups. Ihnen fehlt das Verständnis. Dabei kann man dieses Modell (im Gegensatz vielen anderen aus der IT) prima auf die Realität übertragen:

"Sie haben meine Tochter? Macht nichts, wir haben Zwillinge..."

Die Pfeil-Taste klemmt ein wenig, statt einer Mail werden fünf ausgewählt, das endgültige Löschen mit Shift-Entf ist von der Routine zum Reflex geworden. Zu spät, die Mails sind endgültig gelöscht, und welche es sind, weiß ich auch nicht mehr.

Doch der Server speichert jede Nacht eine Kopie meiner Mailbox und meines Home-Verzeichnisses. Ausgerechnet mit mutt kann ich das gesicherte mbox-File öffnen, darin navigieren, und die verschwundenen Mails in das aktuelle File kopieren.

Noch einfacher wäre es gewesen, wenn ich die eingebaute "Backup"-Funktion des Mailprogrammes genutzt hätte, also den Papierkorb. Die schützt auch, wenn die Mails nicht schon "von gestern" sind.