Ein Laufwerksfehler tritt auf, es ist nur eine Frage der Zeit. Meine DS918+ hat für das Laufwerk 4 fehlerhafte Sektoren gemeldet (ganze 17 Stück :-O) und rät natürlich zum Austausch des Laufwerks. Allerdings ist dieses Laufwerk nicht Teil eines RAIDs, sondern ein einzelnes Volume, welches als Archiv und internes Sicherungsziel dient. Und das auszutauschen ist aufwendiger als erwartet.
Jetzt wollte ich natürlich keinen geordneten Rückzug abarbeiten, was vermutlich der beste Weg und problemlos möglich gewesen wäre. Ich wollte den Ernstfall testen, also den Crash simulieren. Also stumpf Laufwerkschlitten entriegeln und raus mit der Platte. Das System freut sich sichtlich und protokolliert dann:
FileStation wird gestoppt, es hagelt Warnhinweise und dann geht es erstmal normal weiter. Selbst im DSM waren bis dahin das Volume und die Platte weiterhin vorhanden. Also dann jetzt doch beides gelöscht, neue SSD auf den Schlitten geschraubt, selbige eingesteckt, initialisiert und wieder mit einem Volume reaktiviert. Im nächsten Schritt wurde der gemeinsame Ordner wieder angelegt und die Daten von der USB-Backup-Platte zurückgespielt.
Die Freigabe vom Archiv funktionierte wieder, man könnte meinen, die Aktion wäre damit beendet. Allerdings fehlte auf einmal der Medienserver, AudioStation und PhotoStation verweigerten ebenfalls ihren Dienst und konnten nicht gestartet werden. Auch eine Reinstallation scheiterte, das Paketzentrum meinte nur unspezifisch nicht installieren zu können. Im Protokoll fanden sich allerdings Fehler zu „Internal system service [pgsql, synoindexd] start failed“.
Also nur ein Teilerfolg – schade, hätte klappen können. Um das korrekt einzuordnen, FileStation funktioniert zu diesem Zeitpunkt. Man kann im Ernstfall die Daten vom NAS ziehen. Allerdings funktionieren einige Dienste nicht.
Was findet sich im Netz zu diesem Problem? Einiges. Ein Ansatz war die Neuinstallation vom DSM gemäß Anleitung von Synology. Sicherheitshalber habe ich nochmal alles auf die externe Festplatte kopiert und diese dann ausgeklinkt. Vertrauen gibt es bei solchen Aktion nicht im IT-Umfeld. :-/ Das NAS habe ich dann zurückgesetzt, neu eingerichtet und die gesicherte Systemkonfiguration eingespielt. Die pgsql Fehler blieben und auch die Apps ließen sich nicht reinstallieren. >> Keine Lösung – unnötige Arbeit.
Als Alternative fand sich im Netz noch das Löschen der Datenbank:
Daten sind gesichert, also direkt SSH aktivieren und mit putty auf das NAS schalten. per „sudo -i“ Adminrechte aktivieren und den Befehl absetzen. In der shell gibt es keine Erfolgsmeldung, es tut das einfach. Im Anschluss putty schließen und das NAS neustarten. Die Datenbank wird dann neu erstellt und jetzt lassen sich auch die Apps reinstallieren. DLNA funktionierte danach wieder, SSH habe ich deaktiviert.
Fassen wir zusammen:
- Der Crash eines einzelnen Laufwerks zieht diverse NAS-Dienste mit in den Abgrund.
- Es empfiehlt sich nicht, einzelne Laufwerke zu betreiben. Als RAID1 wäre das völlig unfallfrei abgelaufen.
- Das bedeutet auch, NAS mit nur einem Schacht sind „todesmutig“.
- Wer ein 4-Bay-NAS betreibt und intern Backups anfertigt, legt lieber 2x RAID 1 an und verzichtet auf ein Hot Spare.
- Eine Neuinstallation von DSM hilft nicht.
- Hier und da kommt man um die Kommandozeile nicht herum. :-/
- Man kann mit sowas direkt mal seine Backup-Strategie testen. 🙂
