Einige Fälle von Datenwiederherstellung oder Datenverlust in den letzten etwas über zehn Jahren finde ich erwähnenswert.

Nach der Beschreibung meines Vorgehens im ersten Teil möchte ich hier einige Besonderheiten und Ausfälle beschreiben, die zu diesem Setup geführt haben – quasi als anekdotische Evidenz und Trugschluss zugleich. Je nach Fall, würde ich zumindest behaupten immer etwas gelernt zu haben (auch über den Non-Determinismus von IT) und mich dennoch in meinen Annahmen bestätigt zu sehen.

Nur selten sind auch wirklich Daten verloren gegangen. Jedes Mal war es eine Frage des Recovery Point Objective (RPO) und somit eine mehr oder weniger bewusste Entscheidung, bzw. Abwägung.

Ich hoffe ich habe alle Erinnerungen richtig dargelegt, aber einiges ist schon lange her und die Details waren bisher nicht so wichtig. Es fällt nicht immer alles genau in die Rubrik Backup & Recovery, aber die anderen Themen passen wohl in diesen Artikel und dienen der Unterhaltung.

Disclaimer: Ich kriege kein Geld irgendeine Software oder gar Hardware zu loben oder zu bashen. Ich gebe nur meine Meinung und Erfahrung wieder. Die Schwäche einige Tools könnte aber auch nur meine eigene Unfähigkeit sein diese zu bedienen – also bitte nicht als allgemeine Kritik an diesen verwenden.

Blöder Zeitpunkt (aka die Hardware ist schuld)

Im Juni 2011 ist mein Laptop wenige Tage vor dem Umzug nicht mehr angegangen (ein viertel Jahr später konnte ich es reparieren, es war wohl eine lose Verbindung auf dem Mainboard lose). Meine komplette Umzugsplanung war schon damals in OneNote, aber noch ohne Cloud nur lokal. Mein jetziger Server war damals noch mein Spiele-PC und konnte dann einfach die Arbeit übernehmen. Dieser war damals zum Glück noch nicht in dem 35-kg-Gehäuse und somit etwas mobiler als heute.

Ich hatte Zugriff auf die Backupplatte, konnte aber auch direkt auf der HDD aus dem Laptop (nur halt im anderen PC) weiterarbeiten. Das OneNote-Notizbuch ließ sich nach der Installation einfach importieren – fertig.

Für die Bestellung Ersatz-IT war der Umzug natürlich unpraktisch, da ich nur eine Fahrt machen wollte und der Lieferort vom Lieferdatum abhing.

Noch eine Anmerkung zu einem anderen Thema am Rande: Unglücklich war auch die Anpassung der Gemeindestruktur einige Monate vor dem Umzug. Damit änderte sich die Postleitzahl, aber an mir ging das vorbei und war eigentlich kein Problem da erfahrungsgemäß die alte Postleitzahl noch sehr lange funktioniert. Doch dann schlug die Bezahlung der Bestellung fehl, weil die Bank meine Postleitzahl zur Verifikation der Kreditkartenzahlung intern änderte und mich nicht informierte. Ich kannte nur die alte und kam gar nicht auf diese Idee. Jedenfalls war meine Kreditkarte durch die fehlerhafte Eingabe der Postleitzahl ratzfatz gesperrt und hat das hat die Lieferung endgültig verzögert.

Und die Moral aus der Geschichte: Streng genommen brauchte ich in diesem Fall keine Datensicherung, weil ja nur das Gerät defekt war, aber nicht das Laufwerk. Mein Konzept mit verfügbarer zusätzlicher IT-Ausstattung hat dieses Mal gegriffen. Wichtige Daten in der Cloud auf mehreren Geräten verfügbar zu haben, kam erst später auf.

Falsches Ziel (aka das Tool ist schuld)

Im August 2012 war ich an einem Samstag viel in der Eifel fotografieren: Vor allem in und um die Burg Eltz und meine Wohnung in Cochem Sehl von der anderen Moselseite aus. Da ich erst wenige Monate davor mit dem Fotografieren angefangen habe, waren meine Speicherprozesse noch nicht sehr reif. Danach habe ich die Fotos auf meinen Laptop geschoben, aber dann keine Sicherung mehr durchgeführt und bin sonntags auf einen zweiwöchigen Lehrgang gefahren. Dort ist mein Laptop kollabiert (an die Details erinnere ich mich nicht mehr) und ich wollte die Wiederherstellung unter Windows 7 nutzen. Dazu nutzte ich, wenn ich mich richtig erinnere, das mitgelieferte Dell-Tool. Leider war diese nicht auf mein Laufwerkssetup optimiert (2012 war SSD + HDD noch ungewöhnlich). Das Tool hat das reparierte Windows statt auf meine SSD auf die HDD installiert und dank der vorherigen Verschlüsselung war dann (vor allem unterwegs) wenig zu retten (nach dem nächsten Vorfall weiß ich es besser). Meine mobile HDD habe ich ja extra nicht mitgenommen, denn die Szenarien, bei denen dann beide Datenträger weg sind, schienen mir wahrscheinlicher, als dass ich das Backup brauche oder aktualisieren muss. Ich habe leider nur noch zwei Fotos von der Burg Eltz, weil ich auf dem Lehrgang bearbeitet und direkt auf Google Fotos hochgeladen habe. Da ich zwei Wochen später von der Mosel weggezogen bin und seitdem nicht mehr dort war, konnte ich die Fotos bisher auch nicht neu schießen. Die später beschriebene Wiederherstellung der Fotos auf der SD-Karte kam mir nicht in den Sinn, da ich mit dem erneuten Umzug direkt im Anschluss genug beschäftigt war. Außerdem habe ich auf dem Lehrgang ebenfalls viel mit der Kamera experimentiert und daher vermute ich, dass meine einzige SD-Karte zu der Zeit eh randvoll war.

Was habe ich darauf gelernt? Sonder-Spezial-Tools zur Sicherung und Wiederherstellung machen manchmal mehr kaputt, als dass sie helfen. Wichtige Daten sollten vor Reisen mehrfach (anlassbezogen) gesichert werden (RPO). Wenn unterwegs auf Reisen die IT versagt, wäre eine Sicherung, die man immer dabeihat, schon hilfreich – aber auch nur, wenn es nicht die einzige ist. Umgekehrt nehme ich noch heute meine Sicherungs-HDD gerne mit auf Reisen, wenn mein Laptop daheimbleibt.

Zu viel virtueller Speicherplatz (aka die fehlende Warnung ist schuld)

Über den nächsten Fall wollte ich eigentlich mal eigen eigenen Beitrag schreiben, aber hier passt es auch gut rein. Bei den Details bin ich mir nicht mehr ganz so sicher, aber ich hoffe es ist schlüssig.

Ich weiß nicht mehr genau, wann es war, es könnte aber Anfang 2014 gewesen sein. Der Kern des Problems ist die Nutzung von Storage Spaces, die ich in den Artikeln SATAnische Flammen im PC und im ersten Teil ja schon angedeutet habe.

Damals hatte ich einen Storage Pool aus mehreren HDD (500 GB bis 3 TB) mit einer Gesamtgröße knapp über 12 TB. Auf dem Storage Pool habe ich wenige Storage Spaces gehabt, die alle mit Bitlocker verschlüsselt waren. Diese wollte ich der Bequemlichkeit halber zu einem großen Storage Space zusammenführen. Also habe ich den größten Storage Pool mit der PowerShell auf 50 TB vergrößert – deutlich mehr als der Pool eigentlich an Speicherplatz hatte. So weit war es kein Problem. Auch die Verschlüsselung hat mir hier noch keinen Strich durch die Rechnung gemacht. Ich habe direkt die anderen Storage Spaces leer gemacht und alles in meinen super-duper 50 TB Storage Space verschoben und die anderen leeren Spaces entfernt. Das ganze Kopieren hat schon eine Weile gedauert, also habe ich meinem Server anschließend seine wohlverdiente Pause gegönnt und heruntergefahren.

Beim nächsten Hochfahren war Bitlocker aber der Meinung, dass die Integrität des Laufwerks gestört sei. Wie eine Recherche ergab, mag Bitlocker gar keine Laufwerksvergrößerungen – ein Hinweis beim Vergrößern gab es aber nicht. Somit war kein Zugriff auf die Daten mehr möglich. Ich habe einige Tage viele gelesen, rumexperimentiert und einen Ablauf gefunden:

Mit dem Windows-System-Tool repair-bde konnte ich Daten aus dem Space in ein neues Laufwerk retten. Hierbei ist der Bitlocker-Recovery-Key einer der Parameter, neben Quelle und Ziel. Leider hatte ich gerade keine 50 TB HDD zur Hand. Aber wenn ich ein kleineres Laufwerk nehme, ist das wiederhergestellte Dateisystem nur RAW. Mit chkdsk konnte ich Dateisystemfehler finden und beheben, aber das Dateisystem blieb RAW (hier könnte es auch etwas anders gewesen sein). Mit einem Tool zur Wiederherstellung von Dateien aus einem korrupten NTFS-Dateisystem konnte ich aber einige Dateien einsehen und problemlos auf diese zugreifen.

Von diesem Vorgehen war ich so überzeugt, dass ich mir vier Festplatten à 4 TB gekauft habe (das war damals eine ordentliche Stange Geld). Wenn ich mich richtig erinnere, habe ich meinen PCI-SATA-Controller auch kaufen müssen, da natürlich keine vier SATA-Ports frei hatte. Aus diesen habe ich einen neuen Storage Pool gebaut. Da für die vier zusätzlichen HDD kein Platz im Gehäuse war, sah es ziemlich wild aus. Dann habe ich mit repair-bde und chkdsk einen Storage Space mit dem fehlerhaften RAW-Dateisystem erstellt. Jetzt musste ich mutig werden und habe den originalen defekten Storage Space löschen müssen (noch mal 4 x 4 TB war nicht drin). Dann habe ich mit dem NTFS-Tool die Dateien auf einen neuen Storage Space im alten Storage Pool wiederhergestellt.

Jetzt konnte ich die Dateien aus diesem einen (jetzt nicht mehr super-duper) Storage Space auf viele verschiedene Storage Spaces auf dem neuen Storage Pool auf den vier 4TB HDD verteilen – natürlich wieder mit Bitlocker. Ich meine für die Zwischenschritte habe ich auf Parität in den Storage Spaces verzichtet (und Spiegelung genutzt?), damit es schneller geht. Auf Bitlocker habe ich zwischendurch ganz verzichtet. Diese Schritte haben dennoch zusammen über einen Monat gedauert. Dies liegt sicherlich an der alten Hardware (damals aber auch erst 6 Jahre als) aber vor allem an der unterirdischen Performance von Windows Storage Spaces. Dass der Rechner dazu auch nachts durchlief, würde mir heute – nach meinem kleinen Brand im Server – echt Sorgen bereiten.

Vielleicht wäre es einfacher und schneller mit anderen Tools oder einfach nur anderen Parametern von repair-bde oder chkdsk gegangen, aber ich wollte auch nicht mehr experimentieren als notwendig, denn so ist das Übel ja erst entstanden.

Ich habe das ganze mal versucht grafisch zu veranschaulichen:

Das Resultat hat aber auch durchaus Vorteile für mich: Seit dem habe ich die alten HDD übrig, die ich bis heute teilweise noch zum Zwecke der ausgelagerten Datensicherung nutze. Die Grundstruktur der Storage Pool und Spaces ist bis heute gleichgeblieben.

Weil es so gut passt, habe ich noch einige Details zu meinem Storage Pool: Laut Microsoft ist ein Pool mit genau acht gleichgroßen Laufwerken am performantesten. Die Anzahl erfülle ich, aber die Speicherstruktur ist mehr oder weniger noch immer JBOD. Nur noch eine der HDD im Pool ist eine der zur Rettung gekauften.

Am Ende wüsste ich nicht, dass auch nur eine einzige Datei fehlte oder nicht wiederherstellt worden ist. Das finde ich noch heute ziemlich unglaublich.

Aus diesem Vorfall konnte ich einige Lektionen lernen:

• Verschlüsselung ist kein Spielzeug: Bei jeder Bearbeitung von (Bitlocker-)verschlüsselten Laufwerken habe ich seitdem Sicherungen aktualisiert, Bitlocker entschlüsselt, das Laufwerk bearbeitet und neu verschlüsselt. Das war vor allem bei der Anpassung des Over Provisioning von SSD notwendig. Die Größe von Storage Spaces habe ich nicht mehr angepasst, sondern diese neu erstellt und den Inhalt migriert. Auch Firmware-Aktualisierungen von mit Bitlocker-geschützten Laufwerken gibt es nur noch nach Entschlüsselung. Dennoch hat sich Bitlocker als zuverlässig herausgestellt, denn die Bitlocker-Kommandozeilen-Tools sind mächtig, zuverlässig und Bestandteil von Windows (und funktionieren auch wenn die Bitlocker-GUI durch den Admin gesperrt wurde :-).
• Storage Pools und Storage Spaces sind kein Spielzeug: Fast alle Storage Spaces haben seitdem eine ausgelagerte Datensicherung. Die Storage Spaces sind so klein (max. 10TB), dass eine Wiederherstellung einfacher möglich ist. Weiterhin mögliche Problemfälle sehe ich vor allem beim Wechseln von Laufwerken eines Storage Pools.
• Reboot tu gut: Wichtige Änderungen am System erfahren bei mir einen Neustart. Dann wäre nur ein Storage Space defekt gewesen, aber die anderen wären noch nicht verschoben und gelöscht gewesen. Andererseits hat dies die Leidensdruck geschaffen eine Lösung zu finden.
• Geduld ist eine Tugend: Das Finden und Ausprobieren der Lösung hat einige Tage gedauert. Hier habe ich viel gelesen und die Lösungsoption nach Irreversibilität priorisiert. Gerade vor dem Löschen der bearbeiteten Storage Pools habe ich viel getestet, gelesen und eine Weile gegrübelt und den Datenverlust nicht endgültig zu machen. Das mag nicht immer meine Stärke sein, hat hier aber gut funktioniert.

Mainboard defekt (aka schon wieder ist die Hardware schuld)

Hier ist noch eine kurze Anekdote zu einem weiteren Hardwareausfall. Im Frühjahr 2015 war ich auf einem Lehrgang in Köln als meine mobile Workstation plötzlich ausging. Ich hatte einen Wackelkontakt und ohne Laptop war es nicht einfach Notizen zu machen und zu lernen, also habe ich trotz Lehrgang viel Zeit in die Analyse investiert (ich glaube das war M_o_R und somit nicht schlimm).

Es stellte sich heraus, dass mein Laptop auf der Fahrt nach Köln wohl zu eng eingepackt war und wie mir Dell später bestätigte das Mainboard an der Energieversorgung gerissen war. Die drei Jahre Garantie waren aber schon rum und Dell hat einen vierstelligen Betrag für die Reparatur geschätzt. Ohne Akku funktioniert die mobile Workstation aber problemlos und auch nicht empfindlich auf Wackeln – nur halt weniger mobil. Da das Gerät von 2011 erst Anfang 2015 einige Upgrades erfahren hatte (neue SSD + mehr RAM), war seine Lebenszeit aber noch nicht zu Ende und ich konnte es noch bis 2018 selbst weiterbetreiben. In der Familie läuft das Gerät auch ohne Akku noch problemlos bis heute und rennt (hoffentlich bis zum EoL von Win10). Elf Jahre ist nicht mal Forrest Gump gelaufen.

Die Stromversorgung scheint generell ein Problem bei meinen Geräten zu werden: Beim Nachfolgegerät ist die Batterie aufgebläht und hat das Touchpad zu Geisterbewegungen verleitet. Beim Laptop meiner Frau ist der Akku aufgebläht und hat das Gehäuse aufgedrückt.  Beide Geräte laufen seit Jahren ohne Akku, auch wenn mein Touchpad ohne Gegendruck des Akkupacks nicht mehr funktioniert. Der Akku des 2in1-Gerätes meines Vaters hat sogar die Glastastatur des Gerätes zerdrückt und einen Totalschaden verursacht.

In Punkto Datenverfügbarkeit konnte ich etwas feststellen: Auf dem Lehrgang hatte ich keine Ersatz-IT dabei und hätte wohl ein komplett neues Gerät kaufen müssen, um arbeitsfähig zu sein. Die HDD wäre ja problemlos nutzbar gewesen.

Geiz ist geil (aka der Geiz ist schuld)

Ein sehr typischer Fall von vermeintlichem Datenverlust trat direkt in den Flitterwochen auf. Mittlerweile ist das Datenvolumen durch Fotografie gestiegen und ich habe in der Woche einige SD-Karten vollgeschossen. Üblicherweise habe ich SD-Karten von SanDisk gekauft, aber es waren auch 3 SD-Karten von Trancend dabei. Beim Fotografieren habe ich keinen Unterschied gemerkt, aber innerhalb weniger Jahre sind alle drei Trancend-Karten kaputt gegangen – jedoch keine einzige von SanDisk. Jedenfalls hat eine der Karten direkt in den Flitterwochen den Geist aufgegeben und es hat danach einige Datenrettungstools gebraucht die meisten Fotos wiederherzustellen. Bei den beschädigten Bildern war meist nur die RAW- oder die JPEG-Datei betroffen, so dass sich der totale Verlust in Grenzen hält.

Gelernt habe ich etwas über Diversifizierung in der IT: Hätte ich nur auf Trancend gesetzt, hätte ich eventuell mehr Ausfälle gehabt und es als normal angesehen, dass Karten ausfallen. Hätte ich nur SanDisk, hätte ich ohne Ausfälle kein Misstrauen gegen die Karten und weniger Sicherungsmaßnahmen (Karten auch tauschen, wenn diese nicht voll sind etc.). Durch die Mischung sind die Unterschiede der Kartenhersteller sehr offen zu Tage getragen worden.

Für eine Kamera mit zwei Karten-Slots habe ich nicht den Business Case (für die anderen Features dieser Kameras auch nicht). Seit Jahren musste ich keine neuen Karten mehr kaufen, aber wenn dann SanDisk und auch nur von seriösen Händlern.

Der Tag, der nie existierte (aka höhere Mächte sind schuld)

Auch über diesen Fall habe ich einen eigenen Blogartikel auf meiner Liste gehabt und kann ihn mir jetzt sparen.

Im Januar 2017 habe ich mit meinem Roboter, den ich zu Weihnachten erhalten habe, einige Fotos geschossen. Der Ablauf war wie üblich und durchaus erfolgreich: Fotos schießen, von der SD-Karte auf die mobile Workstation verschieben (auf die SSD), dort bearbeiten und dann die finalen Fotos in meine Dokumente kopieren (auf der eingebauten HDD). Einige Bilder habe ich sofort auf Google Fotos hochgeladen und ein Album erstellt. Dies war meine Rettung, aber das wusste ich noch nicht. Ich habe den bearbeiteten Ordner mit den RAW-Dateien aber noch nicht auf meinen Server verschoben. Das erledige ich selten unmittelbar nach der Bearbeitung, weil der Server meist ausgeschaltet ist.

Am Ende des Tages habe ich mein Laptop ausgeschaltet und beim Einschalten am nächsten Tag fingen die Merkwürdigkeiten an. Ich habe eine andere Datei nicht mit Bearbeitung des Vortags vorgefunden und dann nach den Fotos gesucht. Diese waren weder auf der SSD noch auf der HDD. Um es kurz zu machen: Alle Dateien und auch der Ereignisverlauf von Windows waren so als hätte ich die mobile Workstation  am Vortag gar nicht erst eingeschaltet. Auch mit diversen Datenrettungstools habe ich nichts auf der SSD und der HDD gefunden, was auf den Vortag hindeutet. Eine Suche im Internet war nicht erfolgreich (es gibt bestimmt ein Zauberwort). Es war kein großes Fotos-Shooting nach denen ich heute die Daten immer doppelt sichere. Wenn ich den Server am Vortag angeschaltet hätte, würde mich interessieren, ob die Daten auf dem Server oder auf der externen HDD auch nicht persistiert wären.

Es bleibt mir ein Rätsel. In meinem ersten Job nach dem Studium hatten wir eine Software, die angeblich genau das macht (hatte es nie genau getestet). Diese war für einen Lehrsaal gedacht, um die PCs dort täglich auf den Ursprung zurückzusetzen. Ich weiß nicht, ob Windows das auch von Hause aus mitbringt und einfach nur ein Flag dafür beim Boot falsch gesetzt war. Zumindest rede ich mir ein, dass es so gewesen sein muss.

Zum Glück gab es das Album im Google Fotos. Das half mir zumindest mich nicht für verrückt zu erklären (also nicht noch mehr als sonst auch). Hätte mein Laptop auch die Google-Cloud zurückgesetzt, hättet ihr schon früher davon gelesen. Dann habe ich die RAW-Dateien von der SD-Karte vollständig wiederhergestellt und die Fotos einfach erneut so bearbeitet, wie sie im Google Album waren (hätte ich mir aber auch sparen können).

Auch hier gar es etwas zu lernen und zu verbessern: SD-Karten dienen für eine gewisse Zeit auch als Datensicherung (bis sie überschrieben wurden). Bis heute schaue ich nach einem Boot des Systems nach, ob die zuletzt bearbeiteten Dateien wirklich verändert sind. Es gab nie wieder Probleme. Seitdem aktualisiere ich die Datensicherung auf der externe HDD anlassbezogen – auch wenn ich nicht weiß, ob es hier geholfen hätte. Ich glaube diese Lektion hatte ich oben schon, aber RPO ist wohl immer verbesserungswürdig. Da nicht wirklich Daten verloren gingen, war der Schmerz nicht groß genug für grundlegende Änderungen.

Die Sicherung gleich mit löschen (aka schon wieder ist das Tool schuld)

Ich weiß nicht genau wann und warum, weil es erst deutlich später auffiel – viel zu spät. Ich schätze 2018 ist bei einer Operation am offenen Herzen vom Storage Space für das RAW-Foto-Archiv etwas schiefgelaufen. Üblicherweise erfolgt sehr schnell automatisiert ein Rebuild des Storage Space und dann hilft eine Überprüfung des Dateisystems auf Fehler. Das scheint mir hier durch die Lappen gegangen zu sein. Das muss auch nicht die Ursache gewesen sein, halte ich aber für wahrscheinlich.

Ich fand wirklich sehr spät heraus, dass einige Ordner beschädigt waren und um einige Fotos ärmer. In der Zwischenzeit habe ich beide externen Kopien aktualisiert und damit auch dort die Fotos gelöscht. In Synkron wird dies nicht so übersichtlich angezeigt wie beispielsweise in Beyond Compare und daher bin ich auf die gelöschten Fotos nicht aufmerksam geworden. Ich konnte mit chkdsk das meiste noch wiederherstellen – aber nicht mehr alles.

Gelernt habe ich: Wie in Teil 1 beschrieben bin ich erst beim Rekapitulieren des Themas von Synkron auf Beyond Compare umgestiegen – also Jahre nach der Entdeckung des Verlustes. Da stecke ich wohl zu häufig in meinen etablierten Abläufen fest – und das ist generell gefährlich in der IT, aber nur allzu menschlich. Nun wird in Beyond Compare die Analyse sinnvoll vor dem Kopieren angezeigt und man erkennt sofort welche Daten im Ziel gelöscht werden sollen – was bei Fotos im Archiv nie auftreten sollte. Und chkdsk mache ich mittlerweile etwas regelmäßiger auch ohne konkreten Verdacht auf Fehler im NTFS.

Keine Langeweile unter diesem Anschluss (aka der Storage Pool ist schuld, die Hardware aber auch)

Auch hier bin ich mir nicht sicher, wann es war, aber Mitte 2019 haut grob hin. Ich wusste schon, dass einer meiner beiden USB-A 3.0 Ports am Laptop manchmal Aussetzer hat, aber zu der Zeit hatte ich die Details nicht ausgeforscht. Da mein Server kein USB 3.0 hat, aber schnelles Ethernet, habe ich die Datensicherungs-HDD meiner Frau an mein Laptop angeschlossen, um eine Kopie auf den Server zu schieben (Ethernet statt WLAN).

Zu der Zeit hatte ich die externe HDD meiner Frau auch mit einem Storage Pool versehen, um die Storage Spaces für verschiedene Zwecke als flexible Partition nutzen zu können. In diesem Setup sind alle Storage Spaces so groß wie das gesamte Laufwerk an sich und maximal flexibel nutzbar, mit sehr geringem Overhead. Dann gibt es auch keine Probleme mit Bitlocker bei der Anpassung der Partitionsgrößen (eine Lehre, die oben ja gezogen habe).

In diesem Fall war das fatal. Durch einen Aussetzer des USB-Ports und einem kurzen Verbindungsabbruch, verbunden mit dem sofortigen Wiederanlaufen der HDD hatte sich der Storage Pool wohl selbst zerstört. Leider habe ich kein Screenshot oder die genaue Fehlermeldung gespeichert, aber all meine Recherchen im Internet liefen darauf hinaus, dass der Storage Pool mit all seinen Spaces unrettbar (unter normalen Umständen) verloren ist. Gut, es war nur die Sicherung und ein Teil war ja zusätzlich auf dem Server, also habe ich die HDD formatiert und ohne Storage Pool neu aufgesetzt und die Datensicherung aktualisiert. Bei mir hätte ein vergleichbares Vorgehen wegen der Datenmengen ewig gebraucht. Die verhältnismäßig wenigen Dateien in diesem Fall machen den Prozess schnell und einfach. Jetzt gibt es dort keine verschiedenen Laufwerke mehr, aber dafür eine Orderebene mehr.

Mittlerweile weiß ich, dass diese Verbindungsaussetzer des einen spezifischen USB-Ports nur bei USB 3.0 bzw. Massenspeichern auftreten. Andere USB-Geräte (meist nutze ich mein Headset) machen nie Probleme. Und nach der nächsten Erfahrung weiß ich aus, dass es weder ein Softwareproblem noch das Mainboard ist, sondern der physische USB-Port am Laptop.

Und die Moral aus der Geschichte: Storage Pools sind nicht immer sinnvoll und durchaus eine zusätzliche Fehlerquelle. Gerade bei Datenträgern anderer Personen (auch wenn dieser streng genommen meiner ist), lasse ich lieber die Finger weg. Wenn man von defekten USB-Ports weiß, sollte man diese auch nicht nutzen. Ich nutze ihn nicht mehr für Speichermedien. Wenn ich mehr als einen brauche, nutze ich den USB-C-Hub am dritten USB-3-Port. Das Setup mehrerer Storage Spaces als flexible Partitionen einzusetzen, nutze ich für mich aber weiterhin. Auch im Zusammenspiel mit Bitlocker ergibt sich für mich ein großer praktischer Nutzen, den ich sonst durch mehrere Datenträger realisieren müsste.

Kein Zugriff unter diesem Controller (aka das Update ist schuld)

An Heiligabend 2019 wollte ich vormittags mal eben die Treiber von meinem Laptop aktualisieren (natürlich mit Lebkuchen und Weihnachtslieder). Das Ziel war es das oben beschriebene Problem mit dem einen USB-Port wegzupatchen. Leider hatte ich danach keinen Zugriff mehr auf das System. Es blieb mir auch keine lange Zeit für eine Analyse und damit ich Weihnachten mein Laptop habe, bin ich sofort zum einzigen Saturn in München, der ein m2-SSD-Gehäuse vorrätig hatte und 10 Minuten vor Ladenschluss damit raus. Leider hat dieser Adapter entgegen der „Beratung“ der Mitarbeiter nicht die Möglichkeit auf NVME zuzugreifen. Damit war ich raus und konnte die Ursache nicht ergründen. Mit der Fahrt nach Weihnachten zu meinen Eltern – zwei Stunden entfernt von jedem Elektronikgeschäft – konnte ich auch nicht weiter am Problem arbeiten. Für die Zwischenzeit habe ich mir eine weitere NVME-SSD und ein externes NVME-Gehäuse im Internet bestellt, die aber auch viel später als angegeben ankamen. In der Zwischenzeit war der Jahreswechsel gewesen und ich auch wieder zu Hause.

Die Tests haben gezeigt: alle SSD laufen problemlos und mein Laptop erkennt einfach keine SSDs mehr in beiden m2-Slots. Den Bitlocker-Wiederherstellungsschlüssel kannte ich bei den vielen Versuchen am Ende sogar auswendig. Jetzt hatte ich erst die Möglichkeit mit dem Hersteller Schenker in Kontakt zu treten und nach einem Telefonat mit dem Support das Gerät einzusenden. Hier habe ich nur die leere neue SSD mitgeschickt und keine SSD und HDD die vorher im System genutzt wurden. Weniger, weil ich einen unerlaubten Zugriff verhindern wollte, sondern primär, um zu verhindern, dass die Datenträger später mit weniger Daten zurückkommen (siehe oben als das Tool schuld war). Es war tatsächlich der NVME-Controller auf dem Mainboard defekt und dieses wurde komplett ersetzt. Nach dem Einbau der alten Laufwerke in mein Laptop war der neue TPM auf dem neuen Board etwas trickreich, aber letztendlich funktionierte es dann wie erwartet. Leider hat es insgesamt gut drei Wochen gedauert. Interessanterweise ist der USB-Port, wegen dem ich überhaupt alle Treiber aktualisieren wollte, noch immer defekt, so dass ich nun weiß, dass es nicht am Mainboard lag.

In der Zwischenzeit konnte ich aber direkt an meinem Server arbeiten mit der Sicherung der Daten direkt vor dem Defekt auf der externen HDD. Da es aber kein so schönes Arbeiten am PC war und ich nicht so viel aktiv auf dem Backup arbeiten wollte, hatte ich Zeit für Netflix (The Witcher und Lost in Space erschienen gerade) und zum Puzzeln (es war ja erst Weihnachten gewesen).

Es war nervig, aber mein Ansatz hat ja trotzdem funktioniert. Und seitdem habe ich eine zweite SSD im System und das ist auch ganz praktisch. Auch das externe NVME-Gehäuse gibt mir etwas Sicherheit bei Zugriff auf diese ohne ein weiteres System mit m2-Anschluss im Haus.

Und die Moral aus dieser Geschichte: Patches und Updates sind gut, aber alle systemnahen Patches gehen mit einer Datensicherung einher und bei manchen sitze ich das Problem lieber aus, vor allem, wenn ich kein Angriffspotential durch den Patch mitigiert sehe.

Ansonsten zieht sich wie ein roter Faden durch diesen Artikel die Erfahrung, dass die HDD/SSD problemlos in anderen Geräten funktionieren – wenn man passende Adapter hat. Davon habe ich jetzt mehr. Die wichtigen Daten habe ich damit meist verfügbar.

Das war doch nicht so offensichtlich (aka China ist schuld)

Anfang 2022 bekam ich von einem Verwandten einen USB-Stick, der scheinbar nicht mehr funktioniert. Erst war ich skeptisch und die Ursache war mir auf dem ersten Blick klar. Es muss einfach ein gefälschtes Gerät sein: Dabei habe gleich ich an eine dieser offensichtlichen Fälschungen gedacht, bei denen ein Controller mehr Größe angibt als vorhanden ist und diese Daten auch schreiben kann. Beim Lesen kann er dann aber nicht mehr alle Daten hervorzaubern. Das glaubte ich, bis ich herausfand, dass 128 GB USB-Sticks heute wirklich so günstig sind.

Aber da keiner meiner PCs und anderer Geräte (habe es auch mit OTG an Chrome OS und Android versucht) diesen Stick mag, ist er wohl einfach defekt. Es liegt nicht nur am Dateisystem, da auch das Formatieren nicht mehr klappt. Die Datenträgerverwaltung verhält sich auch nicht-deterministisch bei diesem USB-Stick.

Gelernt habe ich, dass große USB-Sticks nicht mehr teuer sind, aber auch nicht immer gut.

Die Daten der anderen (aka endlich ist wirklich jemand anderes schuld)

Im Sommer 2022 bat mich eine Bekannte, mir mal ihre externe Festplatte anzuschauen, da diese am PC nicht mehr erkannt wird. Das war bei mir auch der Fall, aber mit passenden Tools ging etwas. Nach etwas Herumprobieren habe ich eine 1:1 Kopie auf eine meiner HDD gemacht. Das Ganze hat für ~100GB (die HDD war 250GB groß) um die 20 Stunden gedauert. Dabei gab es laut CrystalDiskInfo nach dem Kopieren circa 24.000 UltraDMA-CRC-Fehler. Als mir ein SATA-Kabel (diesmal das Datenkabel, nicht wieder das Stromkabel) um die Ohren geflogen ist, hatte ich mal 30 davon. Daher gehe ich davon aus, dass diese HDD wirklich ihr Lebensende erreicht hat

Nach der Reparatur des Dateisystems waren viele Daten da. Nach etwas Magie von chkdsk auf einem Klon der wiederhergestellten Partition wurden auch einige Dateien zusätzlich gefunden – aber nicht viele. Ob es alle ursprünglichen Dateien auf der Festplatte waren weiß ich nicht, aber laut Rückmeldung fehlte nichts.

Und die Moral von der Geschicht‘: Anderen helfen schadet nicht. So habe ich wieder ein Szenario geübt und nur etwas Zeit und Strom investiert.

SATAn holt sich die Daten persönlich (aka die Hardware ist ständig schuld)

Auf den kleinen kurzen Brand in meinem Server bin ich im Artikel SATAnische Flammen im PC ausführlich eingegangen.

Hier möchte ich nur auf die Lektionen und Konsequenzen für meine Datensicherung eingehen: Zum einen war es für mich gut zusehen, dass selbst kleine Kabel eine große Wirkung haben können. Beim neuen Server werde ich versuchen eine SATA-Strom-Verkabelung zu haben, die dazu führt, dass ich bei einem Kabelfehler (beim Netzteil werde ich machtlos sein) nicht vier Laufwerke auf einmal verliere. Ich bezweifle aber, dass es mir gelingen wird, denn eine erste Suche führte zu dem Resultat, dass eigentlich bei allen Netzteilen mehrere SATA-Stromanschlüsse in Reihe oder parallel geschaltet sind. Da kann ich nur hoffen, dass die Qualität der mitgelieferten SATA-Kabel hoch genug ist.

Wäre es zu einem Ausfall der vier Laufwerke gekommen, wäre wohl der gesamte Storage Pool mit allen Spaces verloren. So viel Redundanz, dass vier beliebige HDD ausfallen können, ist mir teuer. Ich kenne kein Datenrettungstool, das hier geholfen hätte. Immerhin waren einige Daten (mit einem miesen RPO) auf externen HDD und sogar in einem anderen Haushalt gelagert. Also selbst im Extremfall, dass das gesamte Haus abbrennt, hätte ich noch einige Daten (was dann wohl aber geringste Sorge wäre). Das 3-2-1-0 Prinzip (das im Heise-Artikel ja der Ursprung für den ersten Artikel war, hätte hier Anwendung gefunden.

Verschieben ist gut – Kontrolle ist besser (aka wer ist jetzt schon wieder schuld?)

Kurz vor der Fertigstellung dieses Beitrags, nach der im vorherigen Artikel angekündigten Umstellung von Synkron auf Beyond Compare wurde mir ein Fehler anzeigt. Das wurde beim Kopieren der Daten vom Server auf die Sicherungs-HDD bemerkt. Zwei Verzeichnisse in meinem RAW-Foto-Archiv gibt angeblich nicht mehr, sondern diese sind jetzt leere Dateien. Außerdem sind einige Dateien nur noch 0 kB groß. Das spart zwar Speicherplatz, ist aber sinnlos. Da es nur die ausgelagerten Dateien sind, hält sich der Schaden in Grenzen, aber zum Glück habe ich genug Motivation, um einige Versuche zu starten.

Das erste Problem ist, dass PhotoRec und TestDisk ganz andere Bezeichnungen der Laufwerke, haben als ich mit Windows nativ und diversen Tools angezeigt bekommen. Windows mag halt kein sdj, sdk, sdx etc.

Die GUI-Version von PhotoRec hat sinnvollere Laufwerksbezeichnungen. Dort werden die UUIDs wie in der PowerShell unter Get-Disk angezeigt. Aber auch nur diese und in anderer Reihenfolge, so dass eine Übertragung zur CLI-Version nicht möglich ist. Da ist es langfristig wohl angebracht alle Storage Spaces mit unterschiedlichen Größen zu konfigurieren, um diese immer unterscheiden zu können.

Leider werden nur sinnlose und gigantisch große Dateien (>60GB) gefunden, die die SSD voll machen und daher dafür sorgen, dass das Programm nicht durchläuft. Da keine einzige sinnvolle Datei dabei war, habe ich den Versuch fürs erste abgebrochen.

Recuvia als Alternative stürzt beim Start direkt ab ☹.

GetDataBack hat auch nur Dateien mit 0 Byte Größe wiederhergestellt, aber immerhin auch aus den Verzeichnissen, die jetzt Dateien sind. Aber auch viele Dateien, die gar nicht weg sind – das ist beunruhigend.

Bis Redaktionsschluss wurden bisher keine Dateien wiederhergestellt. Aktuell läuft chkdsk und im Köcher habe ich noch Windows File Recovery von Microsoft und dann sehe ich weiter.

[Update 2022-09-29]: Nach einem 26-stündigen Durchlauf von chkdsk waren die Ordner und die Dateien wieder da, aber alle Dateien nur 0 kB groß.

Ich stelle mir die Frage, ob die Dateien direkt beim Verschieben gar nicht erst richtig geschrieben worden sind. Dann wäre jeder Wiederherstellungsversuch vergebens. Da die Quelle eine SSD war, ist dort ein Widerherstellungsversuch quasi ebenfalls sinnlos. Schwer zu sagen, also probiere ich etwas rum.

Und auch diese Erfahrung hat jetzt schon einige Lektionen für mich: Wenn es wirklich wichtig Daten gewesen wären, hätte ich sie nicht auf den Server verschoben und von dort gesichert. Stattdessen hätte ich sie kopiert und direkt das Original in die Sicherung (ohne Umweg über den Server) verschoben. Aber zum Glück habe ich eigentlich keine wirklich wichtigen Daten nur auf dem Server – aber ärgerlich ist trotzdem jeder Datenverlust (von dem Unterhaltungsfaktor hier mal abgesehen). Am Ende könnte man auch dies als eine Entscheidung des RPO klassifizieren.

Interessant wäre auch, ob eine Kontrolle unmittelbar nach dem Verschieben schon den Fehler aufgezeigt hätte und ob dann eine Reparatur erfolgreicher wäre. Man wird es nie erfahren. Wenn doch weiß ich ja, wo ich etwas dazu schreiben werde.

Zusammenfassung

Wie sich herausstellt, wurden einige Lehren gleich mehrfach gezogen: Gerade eine Verbesserung des RPO bedeutet aber immer einen Mehraufwand (HDD anstecken, Server hochfahren etc.) und ist daher eine Kosten-Nutzen-Rechnung. Hier konsequenter zu sein ist halt auch schwer. Zumindest bei wichtigen Daten mache ich das, aber einen konkreten Grenznutzen habe ich nie kalkuliert oder meine Daten explizit nach Verfügbarkeitsanforderungen klassifiziert. Implizit mache ich das seit Jahren.

Es ist nicht immer möglich zu gewährleisten, auf Reisen die benötigte Ersatz-IT dabei zu haben, um schnell wieder arbeitsfähig zu sein (RTO). Hier wäre Daten in der Cloud (oder mit Resilio Sync) auf dem Smartphone zu bearbeiten eine echte Option. In dem Fall habe ich aber Vertraulichkeit, Verfügbarkeit und Aufwand abgewogen und bin zu einer hoffentlich ausgeglichenen Lösung gelangt, bei der ich nur einige Daten dabeihabe.

Wenn ich die Szenarien oben zusammenfasse, stelle ich fest, dass folgendes gefährlich für meine Daten ist:

• die Zeit kurz vor einem Umzug
• die Weihnachtszeit
• Storage Pools und Storage Spaces
• wenn man mich an IT lässt

Zusammenfassend lässt sich wohl sagen, dass eine Datensicherung immer Tücken hat und Komplexität häufig mehr schadet, als das sie hilft. Ich gebe mir Mühe die üblichen Schadensfälle zu berücksichtigen, aber es passiert halt immer etwas Neues. Ich bin gespannt auf das nächste Mal – ehrlich. Vielleicht kommt jemand wie Thanos und lässt die Hälfte aller Dateien im Universum verschwinden? Zumindest gibt es was zu berichten, wenn es nicht wie geplant läuft.

Generell war es aber sehr hilfreich für mich alles mal niederzuschreiben und in Ruhe zu rekapitulieren. Genau das wollte ich mit dem Blog erreichen. Ich hoffe das diese Gedanken langfristig auch zu besseren Entscheidungen führen (wie es mit dem Wechsel von Synkron zu Beyond Compare ja schon anfing).

Mir ist bewusst, was die Hauptkritik von Dritten sein wird:

1. Nutze kein Storage Pool
2. Nutze kein Bitlocker
3. Nutze kein Windows

Bis ich meinen aktuellen Erfahrungsschatz mit diesen Technologien in einem anderen Technologie-Stack (bspw. zFS, VeraCrypt, Linux) aufgebaut hätte, würde viel Zeit vergehen. Da ich nur wenig zum „Spielen“ mit IT komme und es ja auch um Redundanz und das Verhalten in Fehlerfällen geht, ist es mehr als nur Basiswissen und Migration. Daher ist jede erfolgreiche Wiederherstellung für mich eher der Beweis des Gegenteils.

Die Nutzung von Storage Pools unter Windows habe ich generell schon Frage gestellt. Als Alternative habe ich zFS erwogen (bin begeistert, seit ich im Studium erstmals darüber gelesen habe). Aktuell bin aber zu dem Schluss gekommen, dass ich mich mit Linux nicht genug auskenne und dann wohl eher neue Risiken erwachsen. Letztendlich sind Storage Pools mittlerweile auch eine abgehangene Technologie (von den gravierenden Patch-Fehlern von Microsoft in den letzten Jahren mal abgesehen).

Was bietet sich mehr diesen Beitrag zu beenden mit dem Abschluss vom Chaos Radio: „Lasst euch nicht überwachen und verschlüsselt immer schön eure Backups“. Und jetzt ab für Verdächtig von Systemabsturz.