datenritter blog

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!

Interessant:

Nebenbei bemerkt überleben Speicherkarten, sofern sie hermetisch dicht sind (einige SD-Typen, xD, Micro-SD), durchaus auch eine Vollwäsche bei 60°, wie wir bereits (unfreiwillig) testen konnten. Problematisch sind dagegen Kartentypen mit unvollständig verklebtem Gehäuse oder konstruktiv undichten Kontakten (CompactFlash).

Quelle: Heise-Meldung.

Es gibt also Hoffnung für die Urlaubsfotos, auch wenn diese am Grund des Sees liegen. Andererseist: Mal schnell das Kärtchen ins Wasser werfen, um Beweise zu vernichten ist auch nicht drin.

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.

Michael Wilde teilt heute mit, dass die Foren, die heise online eigentlich löschen wollte, erhalten bleiben:

Ich darf Ihnen im Auftrag des Forenbetreibers folgendes zur Kenntnis
geben:

1. Ihm war nicht bewusst, wie sehr einzelne User an alten Beiträgen
hängen.

2. Die bisher dafür vorgesehen Foren werden nicht gelöscht, sondern
nur auf read-only gesetzt.

(...)

Die Foren werden allerdings nicht mittels der Forensuchmaschine durchsuchbar sein. Außerdem wird es eine Möglichkeit geben, die eigenen Beiträge zu löschen.

Bleibt die Frage, ob man sich bei heise wirklich nicht darüber im klaren war, oder etwas anderes bezweckte. Z.B. konnte man in den letzten Tagen sicher ob zahlreicher Versuche, die Foren zu spiegeln, die Belastbarkeit des Servers testen. Auch wurde heise online durch die Ankündigung in den Fokus der Aufmerksamkeit gerückt. Nicht ungeschickt. Andererseits hat es heise wohl wieder mal ein paar Abonnenten gekostet.

Nett anzusehen ist ein ganz anderes Ergebnis: Das "Ausfallforum" mit dem "heise offline"-Logo: debain.org/ausfallforum/

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

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.