Hallo liebe Gemeinde,
nachdem der Watchdog heute morgen meinen Hausautomationsserver auf Basis eines Raspberry Pi3 erst in eine Bootschleife geschickt hat, weil die überwachte Datei auf der Festplatte nicht mehr geschrieben wurde, und der Rechner dann bald gar nicht wiederkam, habe ich das Problem identifiziert: nach noch nicht einmal 8 Monaten Einsatz ist die externe WD Elements WD750BMVW (USB3) mit /, /var, /opt/fhem dahingeschieden. Lesefehler, syslog sagt: blk_update_request: critical medium error, dev sdX, sector XXXX.
Die entsprechenden SMART-Einträge zeigen das Disaster:
9 Power_On_Hours 0x0032 093 093 000 Old_age Always - 5633
193 Load_Cycle_Count 0x0032 065 065 000 Old_age Always - 405857
Gemäß Wikipedia (https://en.wikipedia.org/wiki/S.M.A.R.T.) erleben WD-Laufwerke 300.000 bis 600.000 Load Cycle Counts. Das Laufwerk war also nicht für Dauerbetrieb unter Linux geeignet. Tod nach 235 Tagen. Näheres auch in diesem Beitrag (http://www.linuxforen.de/forums/showthread.php?267786-Der-gr%FCne-Festplattentod-Load-Cycle-Count-Liste-anf%E4lliger-Festplatten), von dem ich mir den Titel geborgt habe.
Was bleibt, wenn SD-Karten ähnlich kurz leben und HDD-Markenlaufwerke über den Bach gehen? Werde es jetzt mit einem tragbaren SSD-Laufwerk versuchen (Intenso 128GB 1,8 Zoll USB 3.0). Auslagern übers Netzwerk kommt übrigens für mich nicht in Frage, weil der Hausautomationsserver autark von den restlichen Rechnern laufen soll.
Dies als Erfahrungsbericht, der andere davor bewahren soll, in diese Falle zu tappen.
Viele Grüße
Boris
Hi Boris!
Zitat von: Dr. Boris Neubert am 27 November 2017, 14:46:16
...kurz leben und HDD-Markenlaufwerke über den Bach gehen?
Das Jesus über das Wasser gegangen sein soll, das habe ich ja auch schon mal gehört. Aber wo hast Du denn diese Metapher her?
https://de.wiktionary.org/wiki/den_Bach_runtergehen (https://de.wiktionary.org/wiki/den_Bach_runtergehen)
Gruß Franz
Falls der Jordan als Bach durch geht... ;)
Hallo Boris,
vielen Dank fuer die Info. Mein pidrive am RP hat, wenn auch nicht so dramatisch, nach meinem Geschmack auch
einen zu hohen Load_Cycle_Count:
smartctl -dsat -a /dev/sda|egrep Power_On_Hours\|Load_Cycle_Count
9 Power_On_Hours 0x0032 085 085 000 Old_age Always - 11173
193 Load_Cycle_Count 0x0032 187 187 000 Old_age Always - 41294
Mein RP laeuft mit Raspian und daher habe ich in die /etc/rc.local ein
"/sbin/hdparm -B 253 /dev/sda1"
eingetragen. Die Angabe des Laufwerkes fehlt uebrigens in dem von Dir verlinkten Beitrag unter Loesungsansaetze.
Gruss Helmut
naja .. die "GREEN" sind auch nicht unbedingt für 24/7 vorgesehen. Das währen eher die RED.
Aber mittlerweile haben alle Hersteller das Problem, das entweder die Platten schnell sterben .. oder laaange laufen.
Habe auch mal eine GREEN-PLatte 3 mal in der Garantie tauschen müssen. Anschließend keine Probleme mehr.
Aber bei allen anderen Herstellern die Problematik auch schon durch
-> Nichts geht über ein ordentliches Backup ;o)
Zitat von: Wernieman am 27 November 2017, 16:21:24
naja .. die "GREEN" sind auch nicht unbedingt für 24/7 vorgesehen. Das währen eher die RED.
Stimmt. In meinem NAS dient eine Western Digital Red als Systemplatte:
9 Power_On_Hours 0x0032 073 073 000 Old_age Always - 19852
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 482Und drei Seagate Barracuda
Green (AF) als Datenspeicher:
9 Power_On_Hours 0x0032 094 011 000 Old_age Always - 6043
193 Load_Cycle_Count 0x0032 085 085 000 Old_age Always - 30097
Ich gehe mal noch der Variante WD Red + USB-Gehäuse nach. Auf Varianten mit Systemwechsel (z.B. OrangePi) habe ich noch keine Lust.
Zitat
-> Nichts geht über ein ordentliches Backup ;o)
Jede Nacht! :D
Fehlt noch das Cold Stand-By. Der Raspberry liegt schon hier ;D
Viele Grüße
Boris
Habe hier mal mit einem RasPi Cluster und "Docker Swam", besser wäre "Kupernetis" rumgespielt. Da könnte man auch von "Hot-Standby" Reden...und das zu RasPi-Preisen ;o)
Eigentlich ist es sogar ein echter Cluster, da es 4 Pis sind ...
Dann will ich mal "Vergleichswerte" von meinem Debian-Server beisteuern...
2.5" Systemplatte:
9 Power_On_Hours 0x0012 001 001 000 Old_age Always - 50593
193 Load_Cycle_Count 0x0012 088 088 000 Old_age Always - 124649
3.5" WD Red als Datenspeicher:
9 Power_On_Hours 0x0032 071 070 000 Old_age Always - 21474
193 Load_Cycle_Count 0x0032 199 199 000 Old_age Always - 3402
Bei der WD habe ich seinerzeit extra drauf geachtet, weil das "überall" Thema war. Bei der Systemplatte nicht, also nicht weiter beachtet.
Es kommt auch darauf an, wie man sein Speichermedium behandelt. Ich habe meine fstab folgendermaßen angepasst:
/dev/mmcblk0p2 / ext4 defaults,noatime,commit=120 0 1
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/log tmpfs defaults 0 0
Die SD in PI1 und PI3 laufen problemlos. Leider haben SD Karten keine Art S.M.A.R.T., wäre interessant zu wissen.
Zitat von: Wernieman am 27 November 2017, 21:13:26
Habe hier mal mit einem RasPi Cluster und "Docker Swam", besser wäre "Kupernetis" rumgespielt. Da könnte man auch von "Hot-Standby" Reden...und das zu RasPi-Preisen ;o)
Du meinst Kubernetes?
Jep ... war heute morgen scheinbar noch nicht wach ;o)
@sku
noatime ist eigentlich immer eine gute Idee. Ansonsten könnte es sein, das für eine reine Leseoperation aus dem cache auch die Platte aufgeweckt wird ....
Moin,
im NAS ist bei mir gerade eine WD-Purple nach 22Monaten im 24/7Betrieb abgeraucht. Da lief aber kein FHEM drauf.
Die WD-Green ist auch ausdrücklich nicht für den RAID-Dauerbetrieb im 24/7Modus zertifiziert/geeignet. Hinterher ist man immer schlauer.
Aus aktuellem Anlass bei FHEM mache ich jetzt folgendes:
Ich habe 2 BackupHardwareDevices (Raspi3, BananaPiPro). Beide haben ein funktionierendes System auf SD-Karte.
Diese Karten kommen jetzt jeweils in einen Cardreader am aktuellen BananaM2Berry (aktueller FHEM-Server). Die Karten werden gemountet, und bekommen per rsync stündlich das aktuelle FHEM geflasht/gesynct. Sollte mein aktueller Server "abrauchen", kann ich somit ohne viel Aufwand direkt auf die Ersatzhardware wechseln und bin in FHEM immer noch aktuell.
TAR-Backups gehen zwar auch, aber ist beim Rückspielen etc. mit IMO deutlich mehr Aufwand verbunden
Hi Bartimaus,
das klingt interessant. Kannst du dafür mal eine Kurzanleitung erstellen wie du das machst?
Ich möchte demnächst auch auf Festplatte umsteigen, da mir immer nach ca. einem Jahr die SD-Karte verreckt. Hatte die Logfiles dann auf nen USB-Stick ausgelagert. Da ist mir dann der USB-Stick verreckt. ::)
Aber deine Idee mit dem Cardreader finde ich super interessant.
VG, Thomas
Wenn man weiß, das ein copy eines gemounteten Dateisystems korrupt sein kann, bzw. weiß, wie man so etwas behebt, dann ist so ein Backup gut ;o)
Allerdings würde ich Dir empfehlen, mehr als eine Version aufzubewahren. Ansonsten ist gerade die Copy auch defekt.
@Tom
warum hängst Du keine SSD an Deinen Banana@SATA und verschiebst RootFS dorthin ?
SSD-Controller sollen deutlich besser sein, da sie nicht immer in den selben Cluster schreiben, sondern "random".
Zweitens profitierst Du auch von einem enormen Geschwindigkeitsschub.
sudo fdisk -l (herausfinden wie die SD-Karte eingehangen ist, z.B. /dev/sdb1)
dann
sudo mount /dev/sdb1 /media/SDBackup (überlebt keinen reboot, dafür den mountbefehl in die /etc/fstab)
dann
rysnc /opt/fhem /media/SDBackup/opt/fhem (oder so ähnlich)......
dann sudo crontab - e
rsync eintragen....
ganz grob gesagt
Zitatwarum hängst Du keine SSD an Deinen Banana@SATA und verschiebst RootFS dorthin ?
Das habe ich ja vor. :) Wollte es aber erst mal mit einer alten HDD testen bevor ich eine SSD dafür kaufe.
Leider lassen meine RPI-Sata Kabel von Ali noch auf sich warten.
VG, Thomas
Zitat von: Dr. Boris Neubert am 27 November 2017, 14:46:16
Was bleibt, wenn SD-Karten ähnlich kurz leben und HDD-Markenlaufwerke über den Bach gehen?
Meine SD-Karte ist seit über 3 Jahren ununterbrochen im Einsatz!
Ich habe schon immer gesagt:
Wer behauptet Festplatten seien besser als SD-Karten, der macht irgendetwas falsch!!
ZitatMeine SD-Karte ist seit über 3 Jahren ununterbrochen im Einsatz!
Da hast du entweder eine minimale Konfiguration oder viel Glück ;)
Oftmals merkt man erst dann dass die Karten kaputt sind, wenn man versucht, ein Full-Backup zu machen und dann bei irgendwelchen Sektoren Probleme auftreten und das Einlesen der Karte abgebrochen wird.
Ich hatte mit einer Konfig auch erst nach über einem Jahr Probleme bekommen. Mir ist aufgefallen, sobald ich nen MySQL-Server drauf laufen lasse, verrecken die Karten deutlich schneller.
VG, Thomas
Falsch machen kann eben auch sein, mit SD-Karten das zu machen, was man eben nicht damit macht. Das ist, aus meiner Sicht, unter anderem auch, darauf zu loggen und DB-Server darauf schreiben zu lassen. Hält man sich an ein paar kleine Regeln, sind SD-Karten für viele Anwendungen ein brauchbares Speichermedium.
Aber marvin78, darum geht es doch hier.
Deshalb ja HDD oder SSD. Es sei denn, du hast nen MySQL-Server irgendwo anders gehostet und nicht auf dem Pi und hast evtl. nen Message-Log-Server oder so.
Für minimale Projekte sind SD-Karten natürlich erst mal völlig ausreichend. Aber selbst meine DSLRs die ja eig. nur Fotos darauf ablegen, legen bei einigen RAW-Files (ca. 2%) immer wieder Reperatur-Dateien an.
Daher meine Empfehlung: SD-Karte nur zum booten verwenden und fürs System eine SSD die für den 24/7 Betrieb ausgelegt ist.
Auch wenn ich eher entsprechende WD Red/Gold Platten empfehlen würde, man kann sich bei der Green Serie auch per wdidle3 behelfen:
https://forums.freenas.org/index.php?threads/hacking-wd-greens-and-reds-with-wdidle3-exe.18171/
Zitat von: Wernieman am 28 November 2017, 13:21:00
Wenn man weiß, das ein copy eines gemounteten Dateisystems korrupt sein kann, bzw. weiß, wie man so etwas behebt, dann ist so ein Backup gut ;o)
Allerdings würde ich Dir empfehlen, mehr als eine Version aufzubewahren. Ansonsten ist gerade die Copy auch defekt.
Leider hattest Du Recht.... :-[
Sonntag Abend ist der neue BananaPi-M2Berry erneut heftig abgeschmiert (Exakt 2 Wochen + 2h nach dem letzten Absturz, sehr verdächtig)
"Backups" hatte ich wie folgt gemacht:
1)
RootFS wurde auf von SD auf SSD kopiert.
Dadurch liegt das urspüngliche RootFS auf der SD-Karte "brach".
Dann hatte ich SD-Root nach /media/sd-karte gemountet.
Per Copy-Cron habe ich /opt/fhem stündlich nach /media/sd-karte/opt/fhem kopiert.
Das hat auch alles funktioniert.
Im Falle eine Crashs wollte ich die Bootsequenz wieder von SSD auf SD-Karte ändern, hätte somit also auch ein aktuelles FHEM gehabt.
Da der BPI Sonntag abend noch nichtmal mehr von der SSD booten wollte, habe ich also die Bootsequenz auf SD zurückgedreht.
BPi startet noch immer nicht..., kann ihn zwar anpingen, komme aber weder per SSH drauf, noch startet FHEM.
2.
Ich mache per Skript ein tägliches Vollbackup vom BPi auf einen USB-Stick an der Fritzbox.
Also habe ich meine SSD genommen, gelöscht, neu formatiert und Backup eingespielt. (Das hatte zum Test eine Woche vorher noch geklappt).
Platte angeschlossen, BPi bootet nicht, gleiches Spiel
3.
Von meinem ErsatzBPiPro (der 2 Jahre lang lief) hatte ich die Root-FS-SSD per USB an den neuen BPI-M2Berry gehangen, und die Partition nach /media/ssd-alt gemountet.
Auch da per Cron ein stündliches "Copy" von /opt/fhem.
Also SSD an den alten BPi gehangen.... gleiches Spiel.... bootet nicht mehr.
Den konnte ich allerdings durch einspielen des Komplettbackups (2Wochen alt) wieder aktivieren.
Aber das der neue exakt nach 2 Wochen komplett aussteigt finde ich sehr komisch. Auch das keinerlei Backup funktioniert.
Ein paar Stunden vor beiden Abstürzen hatte ich allerdings einen NFS-Server installiert. Kann aber kaum glauben, das der die Absturzursache war.
Haben die Profis noch ne Idee ? Könnte die Hardware des neuen BPi defekt sein ? Oder irgendeine Inkompabilität ? Ich muss dazusagen, der Software-Support des Herstellers ist bei diesem Modell nicht besonders lobenswert. Lediglich ein "stabiles" Image habe ich gefunden. (DebianStretchLite). https://bananapi.gitbooks.io/bpi-m2-ultra-open-source-single-board-computer/content/linuxsoftware.html
Auch beim booten des Gerätes mit angeschlossenem Bildschirm weist dieser eine Menge "Errors" auf
Zitatweist dieser eine Menge "Errors" auf
Genau diese währen interessant gewesen.
Was mich wundert, anpinkbar, fhem lief .. aber kein ssh?
Diese Errors kann ich bei Bedarf nachliefern... irgendwas mit sunxi..... ?
Sieht jedenfalls "komisch" aus gegenüber den Bootvorgängen mit nem Raspi oder meinem alten BananaPi.
Habe den Einduck das das OS auf die schnelle zusammengew****t wurde.
Das Board wird auch nicht von alternativen OS wie z.B. ARMBIAN unterstützt, wahrscheinlich nicht ohne Grund.
Ping ja, ssh + fhem nein...