Nein, nix zu Corona hier, sondern zu einem Problem auf meinem NAS-Laufwerk daheim. Vor etlichen Jahren habe ich mir mal ein NAS-Gehäuse von Synology geleistet, eine Diskstation DS-211J und mit 2 Festplatten zu je 1 TB bestückt, das ganze als RAID1, konfiguriert. Neulich ist dann eine Platte ausgefallen.

Das ist auch nix schlimmes, denn RAID steht ja für Redundant Array of Inexpensive Disks. Und wieder kann ich aus dem Buch „Unix Backup & Recovery“ zitieren:

The question is not, if your hard drive is going to fail, the question is when.

Unix Backup & Recovery, Curtis Preson, O’Reilly 1999

An sich also nix tragisches, denn das „inexpensive“ heißt ja, dass es vergleichsweise billige Platten sind. Also mal eben Ersatz bestellt, für 40€ bekommt man heute eine 1 TB SATA Platte.

Dann die Diskstation runter gefahren und geöffnet. Das sieht dann in etwa so aus:

Es hatte das Laufwerk 2, also die untere Platte erwischt. Also mal eben getauscht, ist ja alles kein Problem, die Station wieder zu geschraubt, an Strom und Netzwerk und los.

Dann kam die erste Ernüchterung: Die Admin-Oberfläche im Web wollte nicht mehr laden. Gleichzeitig nervte die Station durch ständige Gepiepse um mich auf das Problem aufmerkam zu machen. Und nein, es gibt keinen Hardware-Knopf um das Gepiepse auszuschalten, dazu muss man in die Admin-Weboberfläche gehen und die wollte wie gesagt nicht. Also rumprobiert in verschiedenen Kombinationen, auch mal die intakte Platte weg und nur die neue Platte eingebaut, könnte ja sein, dass das Runterfahren die intakte Platte auch gekillt hat. Das einzige was sich ändert ist die IP-Adresse des NAS, ich vermute also, dass die grundlegende Konfiguration auf der Platte liegt und nicht im Firmware-Speicher.

Irgendwann habe ich dann bemerkt, dass die Admin-Weboberfläche nach einer gefühlten Ewigkeit doch ein Login-Fenster bringt. Dann nochmal eine Etwigkeit warten und man kann tatsächlich administrieren. Hier habe ich dann mal alle anstehenden Updates eingespielt und die Station vom Ballast einiger Pakete die ich hier gar nicht nutze befreit. Außerdem habe ich dann bemert, dass das Ding mir doch eigentlich Mails schicken sollte wenn was schief geht, aber seit Jahren keine Mails mehr gesehen. Genauer gesagt, wohl seit dem Zeitpunkt an dem ich mein Passwort für den SMTP-Zugang geändert hatte über den die Station die Mails verschickt. Also den Mailversand neu konfiguriert. Und siehe da, nach dem nächsten Reboot kommt dann auch gleich die Mail, die mir sagt, dass das Volume „degraded“ ist und repariert werden musse.

Neue Platte ist drin, also wieder die Admin-Oberfläche aufrufen, mit viel Geduld. Und nach einigen Minuten sehe ich dann auch die Fehlermeldung im Speichermanager der Oberfläche:

Von hier bis zum Initialisieren der neuen Platte und Start des Rebuild des RAIDs sind es dann nur noch ein paar Mausklicks. Der Rebuild wird allerdings einige Zeit dauern, denn immerhin muss ja die intakte Platte nun vollständig auf die neue Platte gespiegelt werden.

Intern läuft in dem Ding übrigens ein Linux wie man per SSH-Zugang einfach rausbekommt. Noch ein uralter Kernel 2.6.32 (der damals neu war als ich das gekauft habe) und insgesamt hat der ARM-Prozessor „Feroceon 88FR131 rev 1 (v5l)“ dann auch nur 128 MB RAM, der mit Swap-Partion dann um 2 GB erweitert wird, wovon jetzt gerade tatsächlich 105 MB Swap verwendet werden. Das Webinterface läuft auf einem nginx Webserver, der vielleicht weniger Ressourcen verbrät als ein Apache.

Hardwaretechnisch ist das Ding also eher aus der Steinzeit, verglichen mit meinem Raspberry Pi ist die Hardware in dem NAS-Laufwerk eher mickrig, tut es aber für ein NAS. Modernere NAS-Gehäuse haben natürlich mehr zu bieten, Mehrkern-Prozessoren, mehrere Hot-Swap-fähige Laufwerkschächte und mehr RAM. Was man dann aber auch bezahlt.