Homeserver 25: Sind wirklich keine Daten verlorengegangen?

War der Ausfall des RAIDs letztens jetzt eigentlich folgenlos? Sind meine Daten evtl. in Mitleidenschaft gezogen worden? Diese Fragen kann ich mit einem definitiven „Ich habe keine Ahnung!“ beantworten. 🙂 Denn ein Kommentar von Stefan Jansen in meinem vorigen Artikel brachte mich zum Nachdenken. Zum Einen, ob der Ausfall wirklich folgenlos war, und zum Anderen, wie ich das denn jetzt überprüfen kann. Also habe ich den Browser meiner Wahl geöffnet, paar Stichworte in die Suchmaschine meiner Wahl eingegeben und eine ganze Weile gelesen.

Der einfachste Weg, zu prüfen, ob die Datenintegrität noch da ist, sind Hashes. Ein Hash ist eine Prüfsumme, an der man sehen kann, ob Daten verändert wurden. Wer genaueres wissen möchte, kann sich den Wikipedia-Artikel zu Prüfsummen durchlesen.

Damit ich also Prüfsummen erstellen kann, und diese auch gegenprüfen kann, muss ich diverse Tools haben. Meine Wahl fiel auf MD5Deep, weil dieses wirklich für alle relevanten Betriebssysteme vorhanden ist und identisch bedient wird. So muss ich nicht für jedes System ein neues Tool haben. Aber auch wenn es „MD5Deep“ heißt, es ist eine Sammlung von Programmen, die mit allen möglichen Hash-Funktionen umgehen kann.

Hashwerte für mein Datenbackup erstellen

Dieser Schritt ist nur dieses Mal nötig, weil ja noch keine Hashes von intakten Daten existieren. Später werden die Daten direkt auf dem RAID gehashed.

Um also zu gucken, ob die Daten auf dem RAID noch in Ordnung sind, muss ich ja erst mal Hashes von Daten haben, von denen ich weiß, dass sie in Ordnung sind. Also muss erst mal ein Hashset von meinem Datenbackup erstellt werden. Dieses liegt auf mehreren externen Festplatten, die auch unter Windows lesbar sind.

Zunächst muss ich mir MD5Deep für Windows von der MD5Deep Homepage herunterladen. Die Datei packe ich aus. Hier sind viele Dateien drin, vor allem auch für die diversen Hash-Typen. Mich interessiert zunächst aber nur die Datei hashdeep64.exe, weil ich ein Windows 7 64 Bit nutze. Diese kopiere ich in ein Verzeichnis, von dem aus ich dieses Programm leicht aufrufen kann.

Nun muss ich von meinem Backup Hashes erstellen. Um dies zu tun, muss ich das für jede externe platte tun, auf der Backupdaten liegen. Da ich eine Festplatten-Dockingstation habe, ist das Wechseln von Platten denkbar einfach, einfach senkrecht reinstellen… 🙂

Meine externe Platte lässt sich über den Laufwerksbuchstaben G: ansprechen. Die Backups liegen in exakt der Verzeichnisstruktur auf der Platte, wie sie auch auf dem RAID liegen.

Nun stelle ich also die erste Platte ins Dock, schalte sie ein und dann starte ich das Hash-Programm von der Kommandozeile. Der Befehl sieht so aus:

hashdeep64 -re -j1 g:\daten >>known.txt
  • hashdeep64: Das Programm.
  • -re: Diese Parameter hashen die Daten rekursiv, also alle Dateien aller Unterverzeichnisse. Und es wird die zu erwartende Dauer bei großen Dateien angezeigt.
  • -j1: Verwendet nur einen CPU-Kern. Sonst werden 4 Operationen gleichzeitig gemacht. Ich habe ja eine Quadcore-CPU in meinem Rechner, also ein Thread pro CPU-Kern. Das mag bei internen Platten oder RAIDs kein Problem sein, aber bei externen Platten, auch wenn es USB 3.0 ist, verlangsamt das den Prozess fast auf die doppelte Länge.
  • g:\daten: Da liegt mein Backup.
  • >>known.txt: Leitet die Ausgabe der Hashes in diese Datei um.

Diese Datei wird später noch wichtig, denn hier sind die bekannten Hashwerte drin, gegen die die Daten auf dem RAID geprüft werden sollen. Und warum habe ich zwei Größerzeichen verwendet? Weil dieser Befehl nach und nach mit allen Backupplatten ausgeführt werden soll. Die neuen Hashes sollen an die Datei angefügt werden. Würde da nur ein Größerzeichn stehen, würde die Datei bei jeder Ausführung überschrieben werden.

Jede Datei, auch große Videos, MP3s und Bilder, wird jetzt gehashed und dessen Hashwert in der Datei gespeichert. Da dies für alle Backupplatten gemacht werden muss, kann das eine geraume Zeit dauern.

known.txt bearbeiten

Ich fühle mich gerade wie ein HDD-DJ, ich jongliere hier mit Festplatten, wie andere mit CDs… 🙂 Aber egal.

Das Hashen hat nun eine geraume Zeit gedauert, und es ist dabei eine sehr große known.txt dabei entstanden. Die kann aber, so, wie sie jetzt ist, nicht verwendet werden. Zum Einen sind die Pfadangaben für Windows, zum Anderen haben wir hashdeep mehrere Male aufgerufen und die Hashes an diese Datei anhängen lassen, so dass der Datei-Header nun mehrere Male vorhanden ist. Dies muss geändert werden, bevor die Datei auf dem Server verwendet werden kann.

Ihr könnt zwar so ziemlich jeden Editor nutzen, den ihr möchtet, da es ja nur eine einfache Textdatei ist, ich benutze den Notepad++, aus gewohnheit und weil ich meine, dass der mit großen Dateien besser klarkommt.

Die known.txt beginnt mit den folgenden Zeilen:

%%%% HASHDEEP-1.0
%%%% size,md5,sha256,filename
## Invoked from: c:\
## c:\> hashdeep64 -re g:\daten
## 

Darunter beginnen die Hashes, jede Zeile enthält einen Hashwert und die dazu passende Datei.

Diese 5 Zeilen lassen wir so auch stehen. Weiter unten tauchen diese 5 Zeilen leider aber noch mehrere Male auf. Das könnte zum Problem werden, daher müssen wir diese entfernen. Also nutze ich die Suchfunktion und suche nach den 4 aufeinanderfolgenden Prozentzeichen. Dann wird der zusätzliche Header gelöscht, bis nur noch die Headerzeilen ganz oben vorhanden sind. Diese müssen sein.

Nun zeigen auch noch die Pfade auf Windows-Pfade, weswegen das Programm auf dem Server nichts finden würde. Mit zwei einfachen Suchen und Ersetzen Schritten wandeln wir diese Pfade in Linux-Pfade um.

Gehen wir also in das Suchen und Ersetzen Dialogfeld, in fast allen Editoren ist das mit Strg+H möglich. In das Feld „Suchen nach“ geben wir „g:\daten“ ein. In das „Ersetzen mit“ Feld geben wir „/raid1/daten“ ein. Nun aktivieren wir die Schaltfläche „Alle ersetzen“. Bei der Größe der Datei kann das einige Zeit dauern.

Im zweiten Schritt gehen wir wieder in das Suchen und Ersetzen Dialogfeld, und geben bei „Suchen nach“ „\“ ein, und in das „Ersetzen mit“ Feld einen „/“. Auch jetzt aktivieren wir wieder die Schaltfläche „Alle ersetzen“.

Jetzt ist die Datei bereit, weiterverwendet zu werden. Also schließe ich den Editor, speichere die Datei dabei ab und kopiere sie auf den Server ins Home-Verzeichnis. Hierfür hatte ich ja eine Freigabe eingerichtet, also kann ich das mit dem Explorer tun.

Hashwerte gegenprüfen auf dem Server

Um nun zu prüfen, ob die Dateien auf meinem RAID in Ordnung sind, habe ich ja die known.txt in mein Home-Verzeichnis kopiert. Also logge ich mich per SSH auf dem Server ein. Das Erste, was ich nun tue, ich installiere erst mal MD5Deep auf meinem Server:

sudo apt-get install md5deep

Nun stehen mir alle Programme wieder zur Verfügung, die ich auch unter Windows schon hatte, darunter auch hashdeep. Mit diesem Programm und der zuvor erstellten Liste der bekannten Hashes kann ich nun prüfen, ob die Dateien auf dem RAID dem entsprechen, wie sie in meinem Backup vorhanden sind.

Hinweis: Die Prüfung wird in jedem Falle fehlschlagen. In der Zwischenzeit wurden Dateien hinzugefügt, entfernt und bearbeitet. Hashdeep prüft aber, ob der Verzeichnisbaum und -inhalt identisch sind. Kleinste Abweichungen führen schon zum Fehlschlagen des Audits. Das macht aber nix, wie ich gleich zeigen werde. Ich wollte es nur gleich gesagt haben… 🙂

Ich rufe Hashdeep also nun mit folgendem Befehl auf:

sudo hashdeep -vv -rak known.txt /raid1/daten >resultat.txt

Der Parameter -v regelt die Ausführlichkeit der Ausgabe. Ein einzelnes v gibt nur etwas mehr Informationen, vv führt die Diskrepanzen auf und vvv gibt den Status für jede Datei an.

Den Status jeder Datei zu sehen, wäre too much. Mich interessieren nur die Diskrepanzen. Denn so kann ich entscheiden, ob ich die Datei gelöscht, bewegt, bearbeitet oder sie durch den Crash kaputtgegangen ist.

Der Parameter -rak scant das Ziel rekursiv, aktiviert den Audit-Modus und übergibt die Hash-Datei. Der Audit-Modus untersucht nun jede Datei in der Hash-Datei, ob sie geändert ist oder überhaupt noch vorhanden ist.

Am Ende wird das Resultat in die Datei resultat.txt geschrieben, wo ich es dann in Ruhe analysieren kann. Und da die Diskrepanzen nur eine Hand voll Dateien betreffen sollten, wenn alles gutgegangen ist, dürfte das ein überschaubarer Aufwand sein.

Resultate?

Eine Handvoll Dateien, ja nee, is klar! 🙂 Das habe ich ja mal so was von unterschätzt!

Woran ich nicht gedacht habe, alle Dateien, die nicht im Backup vorhanden sind, werden natürlich als „No match“ angegeben und in die resultat.txt geschrieben. Und es gibt einiges auf dem RAID, was nie ins Backup kommt. Diese Daten sind einfach zu unwichtig, tämporäre Dateien, Podcasts oder sonst Daten, die ich leicht aus dem Netz bekommen kann. Das macht die Analyse der Datei nicht einfach, aber da muss ich jetzt durch… Wie zu erwarten war, steht am Ende der Datei natürlich „hashdeep: Audit failed“.

Das macht aber nix, ich war tapfer und bin die ganze Datei durchgegangen. Das ist auch relativ einfach, da die Einträge ja nach Verzeichnissen sortiert waren. So konnte ich die unwichtigen Verzeichnisse einfach durchblättern.

War der Ausfall des RAIDs letztens jetzt eigentlich folgenlos? Sind meine Daten evtl. in Mitleidenschaft gezogen worden? Diese Fragen kann ich jetzt mit einem definitiven „Alles ist gut, nichts ist kaputt!“ beantworten! Das beruhigt mich ja ungemein, auch wenn das jetzt echt Arbeit war, das zu prüfen.

Für die Zukunft

Jetzt, wo ich weiß, dass die Daten auf dem RAID OK sind, kann ich es mir ja bedeutend einfacher machen. Statt nach einem Desaster mühsam alle Backupplatten zu hashen, werde ich jetzt in größeren Abständen die Daten direkt auf dem RAID hashen. Hierfür werde ich folgenden Befehl nutzen:

sudo hashdeep -re /raid1/daten >hashes.txt

Die hashes.txt liegt dann in meinem Homeverzeichnis auf der SSD. Sollte ich nun mal wieder das Bedürfnis haben, die Integrität meiner Daten prüfen zu wollen, so kann ich immer auf diese Datei zugreifen:

sudo hashdeep -vv -rak hashes.txt /raid1/daten

Somit entfällt natürlich der gesamte obere Teil, die Datenbackups zu hashen und die Hash-Datei manuell zu bearbeiten. Selbstverständlich muss die Hash-Datei gelegentlich aktualisiert werden, aber das dürfte ja klar sein.

Fazit

Ich bleibe dabei, das Linux Software-RAID ist echt robust und kann ganz schön was ab, bevor es zu Datenverlusten kommt. Aber, und das kann ich gar nicht oft genug sagen, wer kein Backup hat, hat ein größeres Problem, als nur paar Tage mit Hashen und Prüfen zu verlieren.