datenritter blog

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.

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.

Die Anleitung zum Sichern der eigenen Beiträge aus dem heise-Forum ließ in der Eile keine Zeit für große Erklärungen. Deswegen hier nun einige Informationen zu Cookies und ihrem Gebrauch mit wget... "wget und Cookies" vollständig lesen »

Will man die eigenen Beiträge bei heise online vor der Löschung retten, so bedient man sich eines Scripts, das der User cassiel dort veröffentlicht hat. Es benutzt wget mit Cookies:

#!/bin/bash

# Datei mit den beiden Heise-Cookies (notwendig für login)
COOKIEFILE=cookies.txt

# Nummer des ersten runterzuladenden Beitrags (0=der aktuellste)
POST=0

# Nummer des ältesten noch runterzuladenden Beitrags
MAXPOST=122

# eure Usernummer. Findet ihr in der URL der Liste der eigenen Beiträge im Forenprofil.
USERNR=12345

echo
echo "Schritt 1: Laden der Beitragslisten"
echo
while [ $POST -lt $MAXPOST ]; do
printf -v HTML "postlist-%04d.html" $POST
wget --load-cookies $COOKIEFILE -O $HTML http://www.heise.de/extras/foren/user_postings/user-${USERNR}/hs-${POST}/
sed -n '\/foren\/S-.*\/read\// s#.*href="\([^"]*\).*#\1#p' $HTML >> postlist.txt
POST=$ POST + 16
done

echo
echo "Schritt 2: Laden der einzelnen Beiträge"
echo
sort postlist.txt | uniq | while read line; do
wget --load-cookies $COOKIEFILE -x -N http://www.heise.de$line;
done

Das Vorgehen ist wie folgt:
1. Betreten des heise-Forums und Einloggen.
2. Klick auf Forenprofil.
3. Rechts im Menü Klick auf "Meine Beiträge".
4. Das erste Posting ist immer Nummer 0. Deshalb bleibt POST=0 gesetzt.
5. Die letzte Postingseite ansteuern. Die URL hat die Form http://www.heise.de/extras/foren/user_postings/user-123456/hs-123/. Die letzte Zahl solange erhöhen, bis nur noch das letzte Posting aufgelistet wird.
6. Die letzte Zahl aus der URL minus Eins für MAXPOST und die vorletzte Zahl (12345) für USERNR im Script eintragen.
7. Im Browser nach den Cookies schauen. Das folgende Cookie-File mit dem Wert für ssoheisede anpassen und als cookies.txt speichern:

# HTTP cookie file.
# Generated by Wget on 2008-10-30 05:20:54.
# Edit at your own risk.

www.heise.de FALSE / FALSE 122836265 ssoheisede %34%22dirid%22%35%2341...(cryptischer Code, ersetzen!)...
www.heise.de FALSE / FALSE 122836265 ssoinit userdb

Achtung: Zwischen den Feldern stehen Tabs, keine Spaces! Alle Daten außer dem Wert für ssoheisede, also "%34...", bleiben unverändert.

Dann startet man das Script, und wget saugt alle eigenen Beiträge auf die Platte. Wenn es nicht klappt, konnten die Cookies von wget nicht richtig eingelesen werden, und daher wurden die Benutzerbeiträge nicht erkannt. Das Script tut dann nach der Meldung "Schritt 2: Laden der einzelnen Beiträge" nichts mehr.

Michael Wilde, der Chef vom Dienst bei heise online hat am Montag angekündigt, dass alle Beiträge, die älter als zwei Jahre sind, aus den legendären Newsticker-Foren gelöscht werden sollen:

wir werden in den nächsten Tagen damit beginnen, Newsticker-Foren
sowie Foren aus dem Extra-Bereich der user2User-Foren zu löschen, die
älter als zwei Jahre sind. Bisher haben wir zwar so gut wie nie Foren
geschlossen, doch uns ist vor einiger Zeit aufgefallen, dass viele
Diskussionen, die vor Jahren in den Foren stattgefunden haben, heute
keine Bedeutung mehr haben.

Die Ankündigung hat zu erheblichem Protest geführt, der keineswegs in das leider für heise typische wilde Trollen auswuchs, sondern überwiegend wohlbegründet ist. Viele halten die heise-Foren für ein Stück Kulturgut. Unter anderem wurden die Einträge rund um den 11. September 2001 als erhaltenswert genannt, aber auch die Gründung der Bürgerrechtsinitiative Stop 1984, die tatsächlich im heise-Forum initiiert wurde.

Am Mittwoch schrieb Wilde dann konkret, dass die Löschung am Donnerstag beginnen werde. Heise online wolle jedoch ein Backup zurückbehalten und überlegen, ob die archivierten Beiträge der Allgemeinheit zur Verfügung gestellt werden.

Wilde betont, dass lediglich "redaktionelle Gründe" für die Löschaktion vorlägen:

Die
Maßnahme hat keine technischen Gründe, sondern ausschließlich
redaktionelle. Es sind weder Spendenaktionen, noch technische
Ratschläge erforderlich.

Welche diese Gründe im Einzelnen sind, blieb bislang unerwähnt. Und ausgerechnet dem technophilen Publikum zu sagen, dass technische Ratschläge nicht erwünscht seien, ist heikel. Viele fühlen sich hierdurch offenbar brüskiert.

Für die Forenteilnehmer typische Protestaktionen wurden angekündigt. Neben den übliche Abo-Kündigungen vor allem das Löschen von Links auf das Angebot von heise online aus Weblogs, Foren und anderen Online-Angeboten. "Backups? - heise löscht alte Forenbeiträge" ... »

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.

Hier ist ein kurzes Video von einer geöffneten defekten Festplatte, die nach dem Anlaufen sofort wieder stoppt. Wie man sieht, bewegen sich die Schreib-Lese-Köpfe nur ein wenig hin und her. Möglicherweise ist die Kopfsteuerung ausgefallen, oder es liegt ein Lagerschaden vor, durch den der Spindelmotor zuviel Strom zieht. Am Ende hört man ein leichtes Schleifgeräusch, und wie eine Parkposition sieht das auch nicht aus:



Die Daten sind zwar nicht weg, aber die Rettung wäre dennoch teuer. Dank RAID-Verbund und regelmäßigen Backups bleibt dem Besitzer das aber erspart.

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..."