ZyXEL NAS542 Dauer-resync Raid5 4-Bay
Zitat von linuxopa am 9. Juni 2024, 13:43 UhrMein NAS542 fing an, alle paar Tage an zu resyncen. Die NAS-interne Diagnose sagte: "Platten gesund".
Also aufs CLI und smartctl -x /dev/ Platte 1-4 aufgerufen.
Erwischt: /dev/sdd3: Ganz unten steht dann:Error 1372 [3] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1371 [2] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1370 [1] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1369 [0] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1368 [23] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1367 [22] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1366 [21] occurred at disk power-on lifetime: 13780 hours (574 days + 4 hours) Error 1365 [20] occurred at disk power-on lifetime: 13780 hours (574 days + 4 hours) Ach schau mal an, von wegen HEALTH: PASSEDPlatte getauscht und schon ist wieder Ruhe.
Bei der Gelegenheit gleich ein kleines Script geschneidert, das mich sofort warnt, wenn das was im Argen ist.
Mein NAS542 fing an, alle paar Tage an zu resyncen. Die NAS-interne Diagnose sagte: "Platten gesund".
Also aufs CLI und smartctl -x /dev/ Platte 1-4 aufgerufen.
Erwischt: /dev/sdd3: Ganz unten steht dann:
Error 1372 [3] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1371 [2] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1370 [1] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1369 [0] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1368 [23] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1367 [22] occurred at disk power-on lifetime: 13830 hours (576 days + 6 hours) Error 1366 [21] occurred at disk power-on lifetime: 13780 hours (574 days + 4 hours) Error 1365 [20] occurred at disk power-on lifetime: 13780 hours (574 days + 4 hours) Ach schau mal an, von wegen HEALTH: PASSED
Platte getauscht und schon ist wieder Ruhe.
Bei der Gelegenheit gleich ein kleines Script geschneidert, das mich sofort warnt, wenn das was im Argen ist.
Zitat von zebolon am 9. Juni 2024, 14:01 UhrHallo @linuxopa,
möchtest Du Dein Script hier vllt. veröffentlichen?...
Grüße
zebolon
Hallo @linuxopa,
möchtest Du Dein Script hier vllt. veröffentlichen?...
Grüße
zebolon
Zitat von linuxopa am 9. Juni 2024, 14:17 Uhr#läuft auf meinem Dektop per cronjob irgendwann nachts, könnte ich mal auf meinen Server verschieben;
#aber da alle Maschinen 24/7 rennen, ist das auch in der Rubrik "wenn ich mal Lust habe."
#geht sicher noch schöner, aber funzt für mich:sshpass -p 'root-sein-passwort' ssh root@192.168.178.100 \
'for i in sda sdb sdc sdd
do
printf $i" : \n"
smartctl -H /dev/$i|grep -i passed|sed 's:SMART.overall.health.self.assessment.test.result:HEALTH:g'
smartctl -A -d sat /dev/$i>/tmp/nas_dev_$i
grep "^ 5" /tmp/nas_dev_$i
grep "^ 10" /tmp/nas_dev_$i
grep "^197" /tmp/nas_dev_$i
grep "^198" /tmp/nas_dev_$i
smartctl -l error /dev/$i|grep -i "logged\|error count"
printf "\n"smartctl -s on \
-o on \
-S on \
-s apm,off \
-s rcache,on \
-s wcache,on \
-s lookahead,on \
-s wcreorder,on \
-t short \
/dev/$i 1>/dev/nulldone' \
|awk {'print $1" "$2" "$10'} >/var/tmp/nas542.logsshpass -p root-sein-passwort' ssh root@192.168.178.100 \
'for i in sda sdb sdc sdd
do
printf $i" : \n"
smartctl -x /dev/$i|grep -i "error [0-9]"
done' >> /var/tmp/nas542.logcat /var/tmp/nas542.log|mail -s "Status NAS542" an-meine-mail-adresse@mein-provider.de
#sshpass, weil ssh-copy-id anfangs nicht über den Neustart des NAS gehalten hat (müßte ich mal wieder testen.)
#die smartctl Schalter sind evtl. übertrieben oft geschaltet (jede Nacht), aber wurscht, schadet nicht
#und nach Plattenwechsel ist alles gleich in gegelten Bahnen
#läuft auf meinem Dektop per cronjob irgendwann nachts, könnte ich mal auf meinen Server verschieben;
#aber da alle Maschinen 24/7 rennen, ist das auch in der Rubrik "wenn ich mal Lust habe."
#geht sicher noch schöner, aber funzt für mich:
sshpass -p 'root-sein-passwort' ssh root@192.168.178.100 \
'for i in sda sdb sdc sdd
do
printf $i" : \n"
smartctl -H /dev/$i|grep -i passed|sed 's:SMART.overall.health.self.assessment.test.result:HEALTH:g'
smartctl -A -d sat /dev/$i>/tmp/nas_dev_$i
grep "^ 5" /tmp/nas_dev_$i
grep "^ 10" /tmp/nas_dev_$i
grep "^197" /tmp/nas_dev_$i
grep "^198" /tmp/nas_dev_$i
smartctl -l error /dev/$i|grep -i "logged\|error count"
printf "\n"
smartctl -s on \
-o on \
-S on \
-s apm,off \
-s rcache,on \
-s wcache,on \
-s lookahead,on \
-s wcreorder,on \
-t short \
/dev/$i 1>/dev/null
done' \
|awk {'print $1" "$2" "$10'} >/var/tmp/nas542.log
sshpass -p root-sein-passwort' ssh root@192.168.178.100 \
'for i in sda sdb sdc sdd
do
printf $i" : \n"
smartctl -x /dev/$i|grep -i "error [0-9]"
done' >> /var/tmp/nas542.log
cat /var/tmp/nas542.log|mail -s "Status NAS542" an-meine-mail-adresse@mein-provider.de
#sshpass, weil ssh-copy-id anfangs nicht über den Neustart des NAS gehalten hat (müßte ich mal wieder testen.)
#die smartctl Schalter sind evtl. übertrieben oft geschaltet (jede Nacht), aber wurscht, schadet nicht
#und nach Plattenwechsel ist alles gleich in gegelten Bahnen
Zitat von linuxopa am 13. Juli 2024, 18:40 UhrZitat von linuxopa am 9. Juni 2024, 13:43 UhrMein NAS542 fing an, alle paar Tage an zu resyncen. Die NAS-interne Diagnose sagte: "Platten gesund".
Nachtrag:
2 Drives starben nacheinander,ersetzt, NAS-Volume abgekackt;
aber Opa sichert noch parallel auf 'nem 4TB Drive wg. Trau-Schau-Wem; und richtig.
NAS-Volume gekillt, neu erstellt, 4TB->NAS, dauerte doch schon etwas...
nun laufen wieder aller rsync's wie a Glöckerl
BTW: NAS542 läuft am saubersten mit nfs defaults 0 0 in der /etc/fstab, NFS4 handelt sich den Rest aus.
Zitat von linuxopa am 9. Juni 2024, 13:43 UhrMein NAS542 fing an, alle paar Tage an zu resyncen. Die NAS-interne Diagnose sagte: "Platten gesund".
Nachtrag:
2 Drives starben nacheinander,ersetzt, NAS-Volume abgekackt;
aber Opa sichert noch parallel auf 'nem 4TB Drive wg. Trau-Schau-Wem; und richtig.
NAS-Volume gekillt, neu erstellt, 4TB->NAS, dauerte doch schon etwas...
nun laufen wieder aller rsync's wie a Glöckerl
BTW: NAS542 läuft am saubersten mit nfs defaults 0 0 in der /etc/fstab, NFS4 handelt sich den Rest aus.