Datenverlust, die zweite ...

« | 26 Aug 2019 | »

Ja leck mich am A…Arm! Was für ein Wochenende!

Das Schlimmste was einem Datenmenschen passieren kann, ist Datenverlust. Siehe November-2018

Und das Schlimmste hoch zwei was passieren kann ist, wenn sich das wiederholt.

---

Wie Backups Daten vernichten können

Angefangen hat es eigentlich ein paar Tage zuvor in der Firma. Ich liebe es ja, dass ich noch Kollegen haben darf, die voll und ganz IT und Technik begeistert sind. Übel ist dann nur, wenn man feststellt:

Boah! Die sind mir weit voraus.

Und so fühlte ich mich beim letzten Thema, namentlich “Backup”.

Zwar habe ich nun recht viel auf mehreren Computern und Servern bis hin zur Cloud verteilt, aber tägliche Echtzeit-Backups, und dann noch mit zusätzlicher Sicherung über Nacht zum Zweitwohnsitz … nö, da kann ich nicht mithalten.

Also startete ich einen Backup Anlauf und wollte dabei auch gleich meinen Datenmüll ausmisten, durchsortieren und dann geordnet auf unterschiedliche Medien duplizieren.

Mein Fehler war (wieder mal), mit dem Müll anzufangen.
Der war inzwischen gut sortiert und gesichert, als ich zwischendurch auf die Idee kam:

Hey, ich seh’ auch gleich meine alten Floppies durch, ob da noch was Rettenswertes drauf ist und setze einen meiner Alt-PCs so auf, dass dort ein Retro-Backup läuft.

Der “Retro-Backup-Rechner” war mein altes Asus A7V600 Board mit einem Athlon XP aus dem Jahr 2003/2004, welches als einziges meiner Boards Floppy-, IDE/P-ATA und S-ATA Ports hatte.

Natürlich musste ich zuerst nachprüfen, ob es denn ein BIOS Update für diese Maschine im Netz gab … und Ja, es gab eines.

Und wie wurde das seinerzeit aufgespielt? Richtig, mit einer DOS-Startdiskette. Und weil ich ohnehin Disketten auf dem Tisch liegen hatte, schnappte ich mir eine, schmiss sie ins USB-Diskettenlaufwerk und startete den gut bekannten Win32 Disk Imager, um ein Boot-Diskettenimage auf den Datenträger zu übertragen.

Das hatte ich noch nie zuvor ausprobiert (sondern nur bei SD-Karten), doch nachdem das Laufwerk angezeigt wurde, dachte ich, dass es problemlos funktionieren sollte.
Und dann hieß es:

• Image auswählen
• Laufwerk auswählen
• Den Schreiben-Button klicken
• 1% fertig
• Access denied
• Abbruch

Seltsam. Alles lief mit Administrator-Rechten, und auch auf anderen Disketten trat das gleiche Problem auf.

Nun gut, muss ja nicht heute sein.

… war mein nächster Gedanke.

**Und als ich eine Stunde später meinen Rechner neu startete, ** **waren die Hälfte meiner Laufwerke weg. … W.T.F. ?? **

Genau genommen waren es jene Laufwerke meiner primären Datenplatte, wo Partitionen für die Softwareentwicklung, Programm-Archive und die neu angelegten Backups gespeichert waren.

An dieser Stelle möchte ich mich über den abgesetzten Aufschrei, der in allen südlichen Wiener Bezirken am Sonntag zu hören war, hiermit entschuldigen.

Was war geschehen?

Nach viel Verzweiflung und einigen fehlgeschlagenen Platten-Restore-Versuchen gelang mir dann die Wiederherstellung der Partitionstabelle und alle Laufwerke waren wieder da. Der Held der Stunde heißt: “MiniTool Partition Wizard Pro 11.5”

Meine Vermutung ist, dass der Win32 Disk Imager anstatt auf Floppy Drive “0” das Disketten-Image auf PhysicalDrive0 geschrieben hatte, wo die Partitionstabelle ungeschützt, aber die anschließende erste Partition gesperrt war … daher das Access Denied.

Das Problem wurde erst beim nächsten Rechnerstart wirksam, als beim Start die Partitionen neu eingelesen werden sollten. Und man konnte das Chaos in der Tabelle auch in der Windows Datenträgerverwaltung wunderbar sehen.

Diesen vermeintlichen Bug im Win32 Disk Imager werde ich aber noch nachgehen!

Was wäre wenn?

Naja, wäre die Platte einfach so eingegangen, hätte ich das auch überlebt. Zwar wäre die Arbeit von einer Woche weg gewesen, doch dank GIT und Fileserver sind sowieso alle wichtigen Daten verteilt gespeichert.

Doch es hätte mich schon sehr geärgert, wenn ich wieder alles neu zusammenstellen hätte müssen.

Auch lade ich gerne Programme und Dokumente herunter, die für eine spätere “Abarbeitung” ungesichert in Ordnern liegen, ganz zu schweigen von vielen VMs, die zwar entbehrlich, aber dennoch mühsam in der Rekonstruktion sind, wenn man sie mal braucht.

Ich denke, ich werden mich also doch an meinen übervorsichtigen Kollegen orientieren, die täglich ihre Backup-Prozedur laufen lassen und so bei Ausfällen nur wenig verlieren.

Jedenfalls hat sich wieder einmal folgendes bewahrheitet:

Aus Schaden wird man klug!

Nachtrag: Ja, Win32DiskImager war Schuld

Meine uralte Version aus dem Jahr 2013, die mir bei SD Karten immer wieder gute Dienste erwies, hat laut Internet den bekannten Bug mit USB-Floppies fehlerhaft zu arbeiten und Festplatten zu korrumpieren.
Es gibt aber eine neue Version des Tools, wo der Fehler nicht mehr auftreten soll … ausprobieren werde ich das aber sicher nicht!