Der grüne Tod: WD Elements am Raspberry

[Dr. Boris Neubert]

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:

Code Auswählen Erweitern

  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 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, 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

[FranzB94]

Hi Boris!

...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

Gruß Franz

[marvin78]

Falls der Jordan als Bach durch geht...

[helmut]

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

[Wernieman]

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)

[Dr. Boris Neubert]

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:

Code Auswählen Erweitern

  9 Power_On_Hours          0x0032   073   073   000    Old_age   Always       -       19852
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       482

Und drei Seagate Barracuda Green (AF) als Datenspeicher:

Code Auswählen Erweitern

  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.

-> Nichts geht über ein ordentliches Backup ;o)

Jede Nacht! 

Fehlt noch das Cold Stand-By. Der Raspberry liegt schon hier 

Viele Grüße
Boris

[Wernieman]

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 ...

[Hollo]

Dann will ich mal "Vergleichswerte" von meinem Debian-Server beisteuern...

2.5" Systemplatte:

Code Auswählen Erweitern

  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:

Code Auswählen Erweitern

  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.

[sku]

Es kommt auch darauf an, wie man sein Speichermedium behandelt. Ich habe meine fstab folgendermaßen angepasst:

Code Auswählen Erweitern

/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.

[Christoph Morrison]

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?

[Wernieman]

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 ....

[Bartimaus]

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

[ToM_ToM]

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

[Wernieman]

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.

[Bartimaus]

@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.

Code Auswählen Erweitern

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

[ToM_ToM]

warum 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

[Tom111]

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!!

[ToM_ToM]

Meine 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

[marvin78]

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.

[ToM_ToM]

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.

[gerhardg]

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/

[Bartimaus]

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

[Wernieman]

weist dieser eine Menge "Errors" auf

Genau diese währen interessant gewesen.

Was mich wundert, anpinkbar, fhem lief .. aber kein ssh?

[Bartimaus]

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...