[PROLOG]
Festplatten abschalten wenn keine Zugriffe erfolgen ist eins der größten Mysterien in der QNAP-Welt, nicht umsonst sind die Threads zum Festplattenstandby (Festplatten) in der mittlerweile 4. Generation etliche Seiten lang. Doch was bewegt das NAS dazu, die Festplatten aktiv zu halten, was kann man dagegen tun und warum sollen die Festplatten überhaupt in den Standby gehen?
In den angesprochenen Threads (siehe erster Post) wird schon einiges darüber ausgesagt, der Rest ist über die vielen hundert Posts verteilt und Vieles wiederholt sich. Ich möchte im Folgenden mal etwas Ordnung schaffen.
[WARUM HDD SCHLAFEN SOLLTEN - ODER BESSER NICHT]
Wer sich ein NAS hinstellt, dass 24/7 erreichbar sein soll, der macht sich natürlich so seine Gedanken. Der Stromverbrauch ist dabei oft entscheidend und sicherlich das Kriterium schlechthin, weshalb man die HDD gerne „schlafen“ sieht, damit sie weniger Strom verbrauchen.
Doch lohnt sich das? Je nach Modell benötigt eine Festplatte etwa zwischen 3 und 8 Watt im Leerlauf und zwischen 0,5 und 0,8 Watt im Standby. Schöngerechnet spart dies also je HDD etwa 8W-0,5W = 7,5W * 24h * 365T = 65,7kWh * 0,3€ = 19,71€ im Jahr.
Das ist wirklich sehr, sehr schöngerechnet; in der Praxis wird die Ersparnis oftmals eher zwischen 3 und 10€ liegen. Auch das ist Geld, das wir nicht verbrennen wollen, keine Frage.
Auch die Langlebigkeit der Festplatten wird für Viele ein Thema sein, da schleicht sich sehr schnell der Gedanke ein, dass eine schlafende Festplatte länger hält, als eine die quasi im ständigen Leerlauf ist. Doch dieser Gedanke ist nicht komplett zu Ende gedacht, denn je häufiger eine Festplatte schläft, desto häufiger muss diese bei einem Zugriff auch wieder aufwachen, sprich der Motor muss anlaufen und der Schreib-/ Lesekopf in Betriebsposition gebracht werden. Dieses Aufwecken ist die größte Belastung, die eine Festplatte in ihrem Alltag erfährt und wäre sicherlich nicht dramatisch, wenn dies ein bis zwei Mal am Tag geschieht, wenn man mal auf seine Daten zugreift. Doch auch hier trügt der Schein, denn das NAS weckt die Festplatten nicht nur dann, wenn eine Datei geöffnet wird, sondern auch dann wenn irgendeine Aktion am oder vom NAS ausgeführt wird. So wird z.B. täglich um 23 Uhr nach Updates gesucht und (standardmäßig) läuft um 3 Uhr der Malware Remover, um nur zwei Beispiele von Vielen zu nennen, wo das NAS „unbemerkt“ die HDD aufwecken muss. Selbst wenn ein Rechner eingeschaltet wird oder sich ein Smartphone mit dem WLAN verbindet, kann dies das Wecken der HDD zur Folge haben - mehrmals täglich.
Ob das so gesund ist und die Lebensdauer erhöht? Ich denke nicht!
Das Aufwecken der HDD (Lade-/ Entladezyklen) ist übrigens wesentlicher Bestandteil der Herstellerangaben zur Lebensdauer und ist bei NAS-HDD typisch mit 600000 angegeben. Damit dürfte der Betrieb einer HDD selbst im schlimmsten anzunehmenden Fall (Aufwecken jede halbe Stunde) über 30 Jahre gesichert sein. Wer’s glaubt…
Geräusche sind auch oft ein Thema. Selbst wenn man mit dem dezenten Geräusch von Lüfter und Luftstrom leben kann, stechen die Geräusche der Disks doch oftmals deutlich und störend hervor. Hier muss man allerdings auch wieder sehen: Stört mich das ständige Drehen der Disks mehr, oder ist das Anlaufgeräusch der Disks, welches mehrmals täglich passiert, nicht sogar viel störender?
Denkt man über all das nach, verflüchtigt sich der Wunsch nach schlafenden Festplatten sehr schnell. Wer seine HDD dennoch gerne schlafen sieht, muss sich auf die unter Umständen lange Reise ohne Ziel begeben und nach der Ursache forschen.
[STANDBY-PROBLEMEN AUF DEN GRUND GEHEN]
Apps und Dienste prüfen und deaktivieren
Im oben verlinkten Thread sind einige Dienste und Apps genannt, die den HDD-Standby verhindern, da diese ständig Zugriffe verursachen. Es ist nahezu unmöglich, diese Liste aktuell zu halten, aber QNAP versucht dies stets auf dieser Seite: https://www.qnap.com/en-us/how…not-entering-standby-mode .
Eines hat aber immer Bestand: Ballast abwerfen! Alle Apps und Dienste, die nicht benötigt werden, sollten zunächst abgeschaltet bzw. deinstalliert werden, das kann schon die Lösung sein!
Apps werden im Appcenter deinstalliert, oder im Zweifel erstmal gestoppt. Einige Dienste sind in den Systemeinstellungen zu finden, wie z.B. „AFP“, „Bonjour“ oder der Webserver und können dort deaktiviert werden. Im Zweifel fragt einfach im Forum nach, ob diese Dienste und Apps für euch relevant sein könnten.
Übrigens: Ein Blick ins Ereignis-Log kann auch schonmal Aufschluss geben: Welche Meldungen stehen dort so, bzw. gibt es etwas Auffälliges? Deckt sich irgendwas mit etwaigen Zeiten zu denen die HDD geweckt wurden?
Geräte im LAN als Verursacher ausschließen
Ist im NAS erstmal Ordnung geschaffen und das Problem dadurch nicht beseitigt, nehmen wir das Netzwerk als Übeltäter ins Visier. Hier kann jedes Gerät im Netzwerk prinzipiell dafür sorgen, dass das NAS bzw. die HDD aufgeweckt werden. Die einfachste Möglichkeit das schnell auszuschließen, ist es das LAN Kabel vom NAS zu trennen. Im zweiten Step können alle Geräte getrennt werden, sodass das NAS nur noch über den Router mit dem Internet verbunden ist. Durch das sukkzesive Verbinden der Geräte kann man unter Umständen eingrenzen, welches der Geräte der Übeltäter ist. Aber Achtung: Wird ein Gerät wieder verbunden und die HDD werden geweckt, ist noch nicht sichergestellt, dass das Gerät im Normalbetrieb schuldig ist. Nun sollte erstmal eine Weile beobachtet werden, ob das Problem weiterhin auftritt.
Stellt sich heraus, dass ein oder mehrere Geräte im Netzwerk den Standby verhindern, muss man forschen, warum das so ist. Dies ist sehr individuell, aber an dieser Stelle ist man nun schonmal einen bedeutenden Schritt weiter.
Übrigens: Ein defektes LAN-Kabel oder ein defekter LAN-Port kann auch solche Probleme verursachen.
Das System selbst unter die Lupe nehmen
Nachdem wir nun ein paar Klassiker als Ursache ausgeschlossen haben, widmen wir uns kurz dem System selbst und stellen uns spätestens jetzt eine ganz wichtige Frage: Besteht das Problem schon immer? Wenn nicht: Seit wann besteht es? Ein Klassiker sind hier Firmware Updates. Könnte es daran liegen, kann ein Downgrade in Erwägung gezogen werden, dazu aber bitte sorgfältig prüfen, ob dies möglich ist und ob eventuell auch Apps durch das Downgrade beeinträchtigt werden! Auch nicht immer unschuldig ist die Hardware: Wurde z.B. RAM erweitert? Dann erstmal raus damit!
Wenn dem Menschen nun nichts weiter an diese Stelle einfällt, dann könnte aber das Dumplog wertvolle Informationen enthalten. Dies erhalten wir über die Helpdesk-App, welche zuvor bestimmt schon deaktiviert oder deinstalliert wurde 😉. Diese aktivieren/ installieren wir temporär wieder und laden im linken Menü der App die Logs herunter. Das kann einen Moment dauern, dann wird es wieder sehr individuell. In der heruntergeladenen Zip-Datei öffnen wir die HTML-Datei und schauen ganz oben auf „Error Log Count“ und „Segfault“. Hohe Werte könnten für systembedingte Probleme sprechen, wobei „hoch“ relativ ist. Meine Faustformel: Bei einer NAS-Betriebszeit von einem Jahr, wobei die Betriebszeit mit jeder Initialisierung neu beginnt, sollte „Error Log Count“ bei maximal 1000 und „Segfault“ bei maximal 10 liegen. Grobe Richtwerte halt, die lediglich auf meinen Erfahrungen mit „problematischen“ und „unproblematischen“ QNAP-NAS basieren.
In jedem Fall aber sollte nun ein Blick auf die Einträge unter [KERNEL LOG] und [EVENT LOG] geworfen werden, diese umfassen unzählige Seiten und sind weit oben im geöffneten Dumplog verlinkt. Wir betrachten zunächst nur die Uhrzeiten und können somit schnell durchscrollen. Hier sollte es möglichst feste Zeiten geben, zu denen Einträge enthalten sind, bzw. sollten sich die Einträge auf relativ geringe Zeitspannen beschränken. Gibt es innerhalb einer relativ langen Zeitspanne sehr viele Einträge, so könnte hier das Problem zu finden sein. Aufschluss können die entsprechenden Meldungen im Log geben.
Werden wir hier nicht fündig, widmen wir uns ein paar integrierten Funktionen, die uns neue Logs zum Durchforsten geben - yeahaa!
Übrigens: Systembedingte Probleme können auch durch die Migration von einem NAS aufs Andere hervorgerufen werden, wie ich hier beschrieben habe: QTS Migration auf neue Geräte - Fluch oder Segen?
Klassischer Standby-Test „blkdev“ aka „Der für Anfänger“
Ich nenne dies den klassischen Test, weil ich diesen seit jeher kenne. Mittlerweile ist der Test ganz einfach über die Helpdesk-App unter „HDD Standby Test“ abrufbar.
Dazu wählt man bei Bedarf das NAS-Gehäuse aus, sofern ein Zusatzgehäuse verwendet wird, und klickt auf Start. Nun ist es zwingend erforderlich sich aus der GUI auszuloggen, außerdem darf nichts und niemand auf das NAS bzw. die Daten zugreifen. Selbstredend: Automatische Backups, etc. sollten während des Tests auch nicht anlaufen.
Nun heißt es warten. Etwa ab dem Moment des Ausloggens sollte so viel Zeit vergehen, dass das NAS wenigstens drei Mal, besser öfter, die Möglichkeit hat die HDD abzuschalten. Sollen die HDD also nach 30 Minuten in den Standby gehen, sollte der Test wenigstens 1,5 Stunden laufen.
Ist die Zeit um, loggen wir uns wieder ein und rufen den Test über die Helpdesk-App auf. Entweder wurde der Test automatisch gestoppt oder wir machen das jetzt über den entsprechenden Button. Dann kann das Ergebnis in Form einer Logdatei heruntergeladen werden und es geht an die Auswertung.
Diese ist natürlich mal wieder sehr individuell und kann hier nicht pauschal beschrieben werden. Anhand eines Beispiel-Logs kann ich daher nur grob umreißen, was hier zu sehen ist.
Das Log sieht wie folgt aus, es wurde für das Beispiel nur wenige Minuten laufen lassen und für den Artikel gekürzt:
Das Log ist in Test-Blöcke unterteilt, wobei maximal 100 Tests gemacht werden, danach wird der Test automatisch beendet. Ein Test-Block wird immer dann gestartet, sobald eine Aktivität auf den Datenträgern stattfindet. Das können innerhalb weniger Minuten also schon 20 Tests sein, was auf viel Aktivität hindeutet, oder innerhalb langer Zeit sehr wenige Tests, was auf wenig Aktivität hindeutet. Sollte zwischen den Tests die Zeit vergehen, nach der die HDD in den Standby wechseln sollen, so sollte genau das auch passiert sein. Den ersten und ggf. letzten Test kann man ignorieren, da hier die Aktivitäten vor dem Ausloggen, bzw. ggf. nach dem Einloggen aufgezeichnet werden. Hier ein paar Erläuterungen zu dem obigen Log:
Test 0/100 = „qLogEngined“ deutet auf Aktivität des QuLogCenters hin, hier wurde also etwas in das Ereignis-Log geschrieben, in diesem Fall wird es das Ausloggen aus der GUI sein.
Test 1/100 = „worker“ und „WRITE block“ bedeutet, dass irgendeine Datei geschrieben/ geändert wurde. Eine genauere Info lässt sich hier nicht ableiten, außer dass es auf dm-123 passierte, was bei mir ein Snapshot-Speicherbereich ist und daher keinerlei weitere Auskunft gibt.
Test 3/100 = Bedeutet, dass hier eine Datei gelesen wurde.
Test 11/100 = Hier haben wir endlich mehr Details. Hier wurde die Datei xxxx_01.img verändert. Wegen „dirtied inode“ braucht man sich nicht zu sorgen, auch wenn es unschön klingt.
Test 14/100 = Hier hat der Syslog-Dienst gearbeitet. Das ist zuletzt ein klassisches Problem, denn der Syslog-Dienst ist bei dem System abgeschaltet.
Test 17/100 = Eine Änderung an der Konfigurations-Partition md-9, hier hervorgerufen durch den Login in die GUI.
Die Auswertung ist also durchaus mühselig und gibt selten Details bekannt. Immerhin sieht man welche Dienste/ Prozesse tätig sind und unter Umständen auch, an welcher Datei oder wenigstens auf welcher Partition die Aktivität stattfand.
Moderner Standby-Test „Disk_Standby_Debug“ aka „Der für Fortgeschrittene“
Für mich ist das der moderne Test, da er neuer ist, als der zuvor beschriebene. Viel Erfahrung habe ich damit noch nicht, weshalb ich gerne beide Tests durchführen lasse, da die Wahrscheinlichkeit höher ist, dass man etwas Brauchbares findet.
Als Vorbereitung sollte die Helpdesk App deaktiviert werden, da diese angeblich das Standby-Problem verursachen kann.
Dies ist vermutlich auch der Grund für diesen modernen Test, da der klassische Test mittlerweile über das Appcenter gestartet wird (andere Startmethoden erfordern keine Helpdesk App, diese zu beschreiben erspare ich mir an dieser Stelle allerdings).
Dieser Test erfordert die Eingabe von ein paar Befehlen auf dem CLI über SSH. Den Weg dorthin habe ich hier beschrieben: Schnelleinstieg: Mittels SSH auf das QNAP-NAS zugreifen
Sind wir in der CLI angekommen, führen wir folgende Befehle aus um das Test-Tool herunterzuladen und auszuführen:
cd /tmp
wget --no-check-certificate https://download.qnap.com/Storage/tsd/utility/Disk_Standby_Debug
chmod 755 Disk_Standby_Debug
for (( i=1; i<=30; i=i+1 )); do ./Disk_Standby_Debug --file 300 ; cat /var/ledvalue; echo -----${i}------;sleep 300; done 2>&1 | tee /share/Public/Standby_test.log
Der Test startet nun in mehreren Durchläufen im Abstand von 5 Minuten, jeder Durchlauf wird mit der Anzeige von 0x00000000----- n ----- abgeschlossen, die Zeilen dazwischen müssen anschließend ausgewertet werden. Die Ausgabe der CLI wird zudem in die Datei „Standby_test.log“ im Public-Ordner geschrieben.
Auch hier ein Beispiel zur Auswertung anhand eines ebenfalls gekürzten Logs:
Der erste Testdurchlauf sollte grundsätzlich ignoriert werden, da hier unter Umständen noch Aktivitäten der Testvorbereitung aufgezeichnet werden. Von Relevanz sind hierbei die Einträge, die nicht mit „**“ beginnen und z.B. Dateiänderungen und -Zugriffe aufzeigen. Dennoch teilt uns ** Search file ** between Wed May 25 10:34:59 2022 and Wed May 25 10:39:59 2022 die nicht unwichtige Info mit, dass der aktuelle Testdurchlauf die Aktivitäten im angegebenen Zeitraum verfolgt, sodass man gegebenfalls Rückschlüsse darauf ziehen kann, was hier passiert ist.
Durchlauf 2 und 4 = Hier ist alles in Ordnung, es finden keinerlei Aktivitäten statt, mit Ausnahme der Logdatei die für den Test geschrieben wird, was in diesem Fall ja normal ist. All diese Zeilen ignorieren wir bei der gesamten Auswertung.
Durchlauf 8 = Hier habe ich ein Netzwerkkabel entfernt, was sehr viele Einträge verursacht. Anhand der Ausgabe lässt sich aber sehr gut auf eine Netzwerkänderung schließen, für die natürlich Logeinträge erfolgen und in diesem Fall auch eine Benachrichtigung verschickt wird.
Durchlauf 9 = „ihm_status.conf“ deutet auf das Ironwolf Health Management hin. Was und warum hier eine Aktivität erfolgt geht daraus nicht hervor, zumal ich gar keine Ironwolf HDD verbaut habe.
Durchlauf 10 = Hier macht das System etwas mit den Zertifikaten. Was und warum? Keine Ahnung!
Durchlauf 11 = Hier gibt es wieder viele Einträge, vor allem weil ich mich in der GUI angemeldet habe. /share/CACHEDEV1_DATA/Public/.@upload_cache“ lässt darauf schließen, dass eine Datei in den Ordner „Public“ hochgeladen wurde. Die genaue Angabe der Datei fehlt hier, ich vermute weil ich die Datei unverzüglich wieder gelöscht habe.
Man sieht auch hier, dass es sehr müßig ist dem Problem auf den Grund zu gehen, aber es gibt ggf. Anhaltspunkte dafür, wo man weiter forschen muss.
Der Test ist nach 30 Durchläufen (ca. 2,5 Stunden) abgeschlossen und kann nicht ohne Weiteres manuell beendet werden. Um ihn manuell zu beenden, muss der entsprechende Prozess mit dem kill-Command in einer neuen SSH Session abgeschossen werden. Der Prozess nennt sich „Disk_Standby_Debug“, die erforderliche ID ist unter Umständen allerdings sehr schwer zu ermitteln, da der Prozess bei Systemen mit wenig Aktivität nur sporadisch und sehr kurz läuft.
Vergleich moderner und klassischer Test
Beide Tests haben ihr Vorzüge, wobei man nicht sagen kann, dass einer besser ist als der andere. Die Kombination macht’s meiner Meinung nach! Während der klassische Test aufzeigt, welche Dienste für Aktivität sorgen, zeigt der moderne Test welche Dateien angefasst wurden. Warum das so ist verrät uns aber niemand, man muss also stets selbst der Ursache auf den Grund gehen, die Tests liefern nur mehr oder weniger brauchbare Hinweise für die weitere Nachforschung.
[EPILOG]
Wir können also festhalten, dass es kein leichtes Unterfangen ist, den Problemen mit dem HDD-Standby auf den Grund zu gehen. Wer trotz aller Widerworte auf dem HDD-Standby beharrt muss sich somit darauf einstellen einen anstrengenden und lästigen Weg zu gehen, dessen Aussicht auf Erfolg oft sehr trübe ist. Es ist ein wahrlicher Kampf gegen Windmühlen.
Ich mag diese Redewendung eigentlich nicht, finde sie hier jedoch angemessen. Denn mit dem HDD-Standby führt man nicht nur einen aussichtslosen Kampf, wofür diese Redewendung steht, sondern man kämpft auch gegen ein Problem, was eigentlich gar keins ist.
Warum Don Quijote nur auf die Idee kam, dass die Windmühlen der Feind seien? Ich habe da so eine Ahnung, die ich mal an der nächstgelegenen Windmühle testen werde. Dazu brauche ich eigentlich nur ein paar Bier… cheers! 
Kommentare 3
dr_mike
Du erwähnst einige Logs in die man schauen soll (Ereignis-Log, Kernel-Log, Event-Log...) aber merkst nicht an, dass diese auch Ursache für das Aufwecken sein können. Immerhin kann man ja nur reinschauen, wenn diese irgendwo hin geschrieben wurden und in der Regel geschieht dies auf die Festplatten.
tiermutter Autor
Deine Penibilität ist immer wieder bemerkenswert und tatsächlich meistens angemessen. dr_mike sieht halt alles.
Ist so, und das ist ziemlich geil... und manchmal lästig
Ich kann hier nicht wirklich widersprechen (würde ich auch niemals tun
), versuche es aber trotzdem...
Ich denke und hoffe, dass dies durch "hier wurde also etwas in das Ereignis-Log geschrieben" und "für die natürlich Logeinträge erfolgen" klar geworden ist.
Sicherlich habe ich mich aber auch etwas auf der Aussage im verlinkten Artikel ausgeruht: "Das bedeutet aber auch, dass ständig Logs geschrieben werden müssen, und wer hätte es geahnt: Dann gehen die HDD auch nicht schlafen." (QTS Migration auf neue Geräte - Fluch oder Segen?)
## Sorry, Zitate sind hier nicht möglich...
So richtig eindeutig geht es aber nicht hervor, da kann ich nicht wirklich widersprechen.
Unterm Strich bleibt klar festzuhalten:
Jeder Logeintrag (das ist nicht auf die Anzeige im QuLogcenter/ Ereignislog im GUI beschränkt) erzeugt Datenträgeraktivität. Dies reicht von einem Login bis hin zur kleinsten, relevanten Abweichung im Betriebssystem oder seiner Umgebung.
Ausnahmen mögen natürlich Logeinträge im RAM sein, deren Präsenz mir bei QNAP-NAS jedoch nicht bekannt ist und für den Disk-Standby entsprechend irrelevant wäre.
Mavalok2
Hmm? Ist das so?
Mühsamer sind wohl eher die fehlenden Emojis. Kenne die nicht alle mit Textzeichen.
Hätte da einen kleinen Tipp: Installiert Q'Center mit Q'Agent auf Euren NAS und Ihr müsst Euch nie mehr Gedanken über den Festplatten Standby manchen. Denn damit gehen die Festplatten never ever niemals mehr in den Standby. Wie auch, wenn alle paar Minuten Daten zum Zustand abgegriffen werden.