datenritter blog - Backups

Backups! 12: Windows macht das regelmäßig

nospam@example.com (datenritter) — Tue, 03 Nov 2009 14:18:00 +0100

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!

Backups! 11: Buffer I/O error on device

nospam@example.com (datenritter) — Sat, 24 Oct 2009 18:31:00 +0200

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.

Backups! 10: modification time wiederherstellen

nospam@example.com (datenritter) — Sun, 07 Jun 2009 22:03:00 +0200

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!

Backups! 9: Chaosradio über Datenverlust und Datenrettung

nospam@example.com (datenritter) — Wed, 25 Mar 2009 23:57:00 +0100

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!

Backups! 8: RAID5-Systeme werden zum Risiko

nospam@example.com (datenritter) — Sat, 28 Feb 2009 11:44:00 +0100

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.

Backups! 7

nospam@example.com (datenritter) — Fri, 29 Aug 2008 12:25:00 +0200

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.

Backups! 6

nospam@example.com (datenritter) — Mon, 16 Jun 2008 22:25:00 +0200

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

Backups! 5

nospam@example.com (datenritter) — Sat, 14 Jun 2008 07:23:00 +0200

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.

Backups! 4

nospam@example.com (datenritter) — Wed, 05 Mar 2008 08:17:00 +0100

Ich benutze Courier als IMAP-Server und Thunderbird als Client. Gute Software, doch schon häufiger fiel mir eine mysteriöse Verdoppelung von Mails auf im Papierkorb auf. Außerdem nützt die beste Software nichts, wenn sie mit zu vielen Daten zu kämpfen hat. Zeit zu handeln...
"Backups! 4" vollständig lesen

Backups! 3

nospam@example.com (datenritter) — Sun, 02 Mar 2008 12:30:00 +0100

Der Sicherheitsexperte Bruce Schneier schreibt in seinem Beitrag Third Parties Controlling Information über ein Forum, das eine wertvolle Informationsquelle für Weinkenner war, bis seine Daten verloren gingen:

Wine Therapy is a web bulletin board for serious wine geeks. It's been active since 2000, and its database of back posts and comments is a wealth of information: tasting notes, restaurant recommendations, stories and so on. Late last year someone hacked the board software, got administrative privileges and deleted the database. There was no backup.

Of course the board's owner should have been making backups all along, but he has been very sick for the past year and wasn't able to.

"Backups! 3" vollständig lesen