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