Spaß mit Festplatten
2. Februar 2023 um 8:37 Uhr von Atari-Frosch
Mein Tag begann heute damit, daß sich mein PC mehrfach weigerte, die Paßwörter für die beiden verschlüsselten Partitionen der Systemplatte anzunehmen. Ich bin mir recht sicher, mich nicht so häufig vertippt zu haben, aber OK.
Als das System dann gebootet war, startete ich als root ein kleines Shell-Script, das ich mir vor einiger Zeit geschrieben hatte. Es öffnet das Daten-RAID1 mit cryptsetup und fragt mich die notwendige Passphrase ab, mountet die Partition, kopiert dann das Thunderbird-Verzeichnis aus meinem Home-Verzeichnis als Backup aufs RAID1, dann noch zwei weitere Dateien, die ich täglich verändere, und schließlich führt es ein apt update durch, um zu sehen, ob irgendwelche Programmpakete ein Update haben wollen. Also, zumindest theoretisch soll das so laufen (und lief es auch monatelang).
Heute nicht.
Das Mounten schien ungewöhnlich lange zu dauern, und nach dem Start des Kopiervorgangs für das Thunderbird-Backup passierte dann scheinbar nichts mehr. htop meldete mir nach 10 Minuten eine Load um 13, was bei vier Prozessorkernen bedeutet, daß die Maschine mehr als dreimal so viel Last hat, als sie verarbeiten kann. Nur: Ein Prozeß, der diese Last verursachte, war nicht erkennbar.
Auf der Root-Konsole bekam ich immer wieder den Hinweis, daß cp und ein kworker-Prozeß jeweils blockiert würden, und die Anzahl an Sekunden, die dabei angezeigt wurde, wurde immer höher. Erst zwei Minuten, dann fünf, dann bald noch mehr. Auf Control-C reagierte das Script nicht. Auf kill -9 auch nicht. Auch die darüberliegende bash ließ sich damit nicht stoppen. Der Kopierprozeß hatte den Status D+. Schließlich blieb mir nach 25 Minuten Wartezeit nichts anderes übrig, als den Reset-Knopf zu drücken.
Nach dem Reboot dauerte das Mounten des RAID1 wieder so lange, aber immerhin waren vorher die Passphrasen für die Systemplatte sofort angenommen worden. Diesmal führte ich das cryptsetup, den mount und dann den Kopierbefehl für Thunderbird manuell aus. Gleiches Ergebnis: Die Load stieg, die beiden Prozesse wurden geblockt, ich konnte zwar Dinge eingeben, aber es dauerte alles lange, und er wurde nicht fertig. Hardware-Reset.
Diesmal ließ ich das Backup weg und mountete nur das RAID1. Und siehe da, das System läuft einwandfrei. Ich zog die täglichen Datenbank-Backups vom Server – immerhin 28 MB –, und zwar direkt ins RAID1. Kein Problem. Auch Thunderbird läuft einwandfrei.
Daß außer dem Kopierprozeß auch einer der kworker-Prozesse blockiert wurde, deutete für mich darauf hin, daß das Crypto-Zeug auf dem RAID1 ein Problem haben könnte. Also war die erste Idee, den Inhalt des RAID1 zu sichern, bevor ich irgendwelche Tests starte. Zu diesem Zweck schloß ich die vor einiger Zeit dafür eingerichtete externe, ebenfalls voll verschlüsselte 3-TB-HDD an. Aber die macht jetzt auch Schwierigkeiten: Sie wird zwar laut Log und lsusb als neues Gerät erkannt, erhält aber keinen Eintrag unter /dev/sd*. Damit kann ich sie nicht mit cryptsetup öffnen und natürlich auch nicht mounten.
Haben sich meine Festplatten gegen mich verschworen?
Neuer Versuch. Externe Festplatte über USB2 statt USB3 verbunden. Selbes Ergebnis: Auf USB-Ebene erkannt, aber kein Device-Eintrag.
Ein Suchmaschinenlauf mit der Geräte-ID der externen Platte brachte auch kein brauchbares Ergebnis. Zwar gibt es ein paar Links, aber die zeigen auf Windows-Probleme – auch dann, wenn ich explizit Linux mit angebe. Im Archlinux-Forum gibt es zwar einen Eintrag, der für exakt dieselbe ID exakt dasselbe Problem beschreibt, aber der ist von 2012 – und hat zwar mehrere Rückfragen, aber keine explizite Antwort bekommen.
Interessant ist ja jetzt die Frage, wieso diese Festplatte ursprünglich mal erkannt wurde? Sie ist zwar offensichtlich schon älter – zumindest ist das zu vermuten, wenn es zu der Geräte-ID bereits 2012 Foren-Einträge gibt –, aber ich konnte sie ja mal problemlos einrichten und bespielen.
Nun denn. smartctl -a kann ja nu einklich keinen Schaden anrichten. Also lassen wir das mal laufen, ne?
Bei sda, der ersten Platte im RAID1, ist das Ergebnis fehlerfrei.
Bei sdb nicht. Sie meldet 18 Fehler. Ich brauch dann wohl demnächst 'ne neue 3-TB-Platte. Oder besser zwei, falls die externe weiterhin keinen Bock mehr hat. Und dann darf ich wohl mal ein RAID1 neu zusammensetzen, das hab ich bisher auch noch nie gemacht.
Spannend ist dabei, daß die beiden internen 3-TB-Platten identisch sind. Beide sind WL3000GSA6454G, ich habe sie zusammen gekauft und zusammen eingebaut. Sie liefen identisch lange. Nun ja …