Vermeidung Systemausfall durch SD-Kartenausfall

Begonnen von FhemPiUser, 18 Oktober 2020, 16:42:56

Vorheriges Thema - Nächstes Thema

FhemPiUser

Mein Fhem läuft auf einem RPI 3B mit SD-Karte und ich logge ziemlich viel. Bisher ist mein System auch nach mehreren Jahren noch nicht durch eine kaputte SD-Karte ausgefallen. Aber ganz wohl fühle ich micht nicht damit, dass mein System und das Logging auf eine SD-Karte (Sandisk Ultra) stattfindet. Alle paar Jahre tausche ich zwar proaktiv die SD Karte, aber vermutlich ist es nur eine Frage der Zeit, wann ich mal einen Systemausfall aufgrund kaputter SD Karte bekomme. Ich überlege daher, was man vorsorglich dagegen tun kann (über tägliche Backups hinaus. Die werden natürlich gemacht).

Ich weiß, dass das Thema "Logging auf NAS" schon mehrfach im Forum diskutiert wurde. Ich möchte jedoch einen unabhängigen Betrieb inkl. Logging vom NAS, da der auch mal aus sein darf.

Daher stelle ich mir folgende Fragen:

  • Welche Karte hält am längsten? Bisher war ich mit der Sandisk Ultra ganz zufrieden. Oder hält eine Sandisk Extreme Pro oder eine Sandisk High Endurance länger durch?
  • Kann man irgendwie einen Ausfall der SD-Karte automatisiert und halbwegs verlässlich vorhersagen quasi als zusätzlicher Schutz bzw. Frühwarnsystem, z.B. durch regelmäßige Suche nach defekten Sektoren oder so etwas wie S.M.A.R.T. / smartctl bei Festplatten oder wenigstens durch Auslesen der Betriebsstunden?
  • Was passiert genau mit fhem falls das Log-Verzeichnis aufgrund defekter SD-Karte kaputt bzw. nicht beschreibbar ist? Fällt fhem dann aus?

Falls die Antwort auf die letzte Frage "nein" ist, dann könnte man einen USB-Kartenleserstick mit einer zweiten SD Karte in den Raspberry stecken und das System auf SD Karte Nr 1 und das Logging auf SD Karte Nr 2 laufen lassen. Die System-SD-Karte wird geschont, da kein Logging, und bei defekter Logging-SD-Karte wird man benachrichtigt (fragt sich noch wie das erkannt werden kann) und tauscht dann die nur die Logging-Karte während des Betriebes aus.

Macht das Sinn? Hat das mal jemand getestet?

betateilchen

Das Thema "SD-Karten-Ausfall bei FHEM" habe ich schon vor Jahren unter "Esoterik" abgelegt.

Ja, eine SD-Karte kann kaputtgehen.
Ja, ein FHEM System kann ausfallen.

Aber wenn man sich im Vorfeld entsprechende Gedanken für ein Desaster-Szenario gemacht (und diese auch durch Ausprobieren "geübt") hat, hat man spätestens nach 30 Minuten wieder ein funktionierendes System.

Die Frage 1 "welche Karte hält am längsten" läßt sich nicht beantworten. In Serbien läuft eines meiner unbeaufsichtigen FHEM auf einem Raspberry seit 7 Jahren 24/7 auf der gleiche NoName-SD-Karte und es gab noch nie ein Problem (trotz der Tatsache, dass auch das Logging auf die gleiche Karte läuft). Vom Hersteller scheint also die Lebensdauer nicht abhängig zu sein.

zu Frage 2: nein

zu Frage 3: probier es doch einfach aus. Setze die Rechte auf das Logverzeichnis auf 000 und beobachte, was passiert. Ansonsten kann ich nur empfehlen, das Logging nach DbLog zu verlegen und diese Logdatenbank regelmäßig automatisiert zu sichern.

-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JF Mennedy

Meine Haussteuerung (fhem & iobroker) läuft in einer virtuellen Maschine (Debian Buster) auf einem HP Proliant Server mit 128 GB RAM und 8 GB Festplattenspeicher im RAID Verbund. Für die virtuelle Maschine sind 16 GB RAM reserviert. Ich erstelle wöchentlich ein Snapshot der vm und monatlich ein komplett Backup auf meinem NAS ebenfalls mit gespiegelten Festplatten. Sollte die vm dahinsein (ist auch schon vorgekommen) wird sie ausgetauscht gegen das letzte Backup, das ich zur Not, falls der Server hin ist, auch auf nem nuk betreiben könnte. Maximaler System Ausfall bei mir 15 Minuten durch zu viel Spielerei/Experimente, wodurch ich mein Debian geschrottet habe ;-) OK vom Stromverbrauch (durchschnittlich 260Watt} nicht vergleichbar mit einem raspi, aber der Server läuft bei mir sowieso 24/24...

FhemPiUser

Zitat von: betateilchen am 18 Oktober 2020, 16:58:34
Aber wenn man sich im Vorfeld entsprechende Gedanken für ein Desaster-Szenario gemacht (und diese auch durch Ausprobieren "geübt") hat, hat man spätestens nach 30 Minuten wieder ein funktionierendes System.

...

zu Frage 3: probier es doch einfach aus. Setze die Rechte auf das Logverzeichnis auf 000 und beobachte, was passiert. Ansonsten kann ich nur empfehlen, das Logging nach DbLog zu verlegen und diese Logdatenbank regelmäßig automatisiert zu sichern.

Zum Wiederherstellen: Ja, das geht schnell, wenn man da ist und Zeit hat: Letztes Backup-Image suf SD-Karte brennen und reinstecken (logs können danach zusammengeführt werden). Das Problem ist nur, wenn man nicht da ist oder keine Zeit hat (Arbeit, Urlaub,...). Dann kann das Stunden oder Tage dauern und wäre ein problem...

Zu 3) Habs versucht ein Logfile mit chmod 000 auf nicht schreibbar gestellt. Komischerweise konnte fhem trotzdem in das log schreiben, selbst nachdem ich es per chown noch einem anderen user gegeben habe. Gelten die Rechte nur nach Neustart/Neu öffnen des Files? Oder wie kann ich das testen?

rudolfkoenig

ZitatGelten die Rechte nur nach Neustart/Neu öffnen des Files?
Ja.
Es gibt ein "set FileLog reopen" Befehl.

MadMax-FHEM

#5
Zitat von: FhemPiUser am 20 Oktober 2020, 12:15:03
Zum Wiederherstellen: Ja, das geht schnell, wenn man da ist und Zeit hat: Letztes Backup-Image suf SD-Karte brennen und reinstecken (logs können danach zusammengeführt werden). Das Problem ist nur, wenn man nicht da ist oder keine Zeit hat (Arbeit, Urlaub,...). Dann kann das Stunden oder Tage dauern und wäre ein problem...

Das ist meiner Meinung nach keine gute Strategie (auch wenn sie einfach und sinnvoll wirkt).

Weil:

wenn du das Image gezogen hast wo die Fehler schon im Dateisystem sind (du es aber noch nicht weißt) -> Schrott

wenn du es während dem Betrieb ziehst -> meist/oft "unbrauchbar" (open Files/Inkonsistenzen)

wenn du auf eine neue OS-Version willst: was dann?

wenn beim Abziehen kein entsprechendes "Tool" verwendet wird: viel zu viel Platzverschwendung (und oft das Zurückspielen auf kleinere SD "unmöglich" und selbst auf gleiche Größe oft "problematisch", wenn dann doch das eine oder andere Byte fehlt ;) )

Mir reicht ein fhem-Backup und meine Notizen...

Damit komme ich von 0 auf 100 in ungefähr einer halben Stunde...
Fast egal ob auf selbe OS-Version oder andere (gut außer es hat sich OS-seitig etwas relevantes geändert aber dann würde es ja u.U. auch einen "Upgrade" betreffen)...
...und auch die SD-Größe ist "egal" (gut Platz für die Daten muss nat. schon sein ;)  )...

EDIT: und ich trenne mich bei so einem Umzug (neue OS-Version z.B.) von Dingen, die ich nicht (mehr) brauche... ;)


Allerdings laufe ich wegen SD-Vorbeugung mittlerweile auf SSD.
(Jaja, ich weiß: PI und USB ist Mist/Kacke/... aber läuft bislang gut. / Obwohl ich SD-Ausfall nur einmal [evtl. 2x] hatte, auf 4 Systemen innerhalb von über 6 Jahren)
EDIT: 4 fhem Systeme (eins inzwischen schon länger auf SSD). In Summe habe ich ca. 10 PIs laufen (ja vielfach nur "Spielsysteme" aber trotzdem ohne SD-Ausfall, wobei von den "Spielsystemen" inzwischen auch 3 mit SSD laufen)...

Wenn du ganz Ausfallsicher sein willst, dann: Cluster-System mit HW-Anbindung über Netzwerk inkl. redundanten Switchen etc. und selbst dann hast du bei einigen Systemen ein Problem, z.B. ZWave (und ZigBee, evtl. auch EnOcean), weil da die angelernten Geräte nicht nur in fhem "stehen" (wie bei Homematic "Classic" / CUL_HM) sondern auch im "Funkmodul"...

Aber für "Notfallzwecke" läuft bei mir "Grundfunktionalität" komplett "autark": direkte Kopplung von Geräten (also ein Lichtschalter direkt mit dem Lichtaktor etc.). fhem ist zuständig für Komfort und das Aufzeichnen von Daten etc.

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

FhemPiUser

ja, fhem rsync backup über nas habe ich zusätzlich auch und ja, neuaufsatz ist sauberer, dauert aber länger zur Wiederherstellung. mein test mit wiederherstellen eines während des betriebs gezigenen sd image hat bei mir geklappt. vorteil der sd images im betrieb ist, dass man sie automatisiert regelmäßig (in mehreren versionen) erstellen kann. wenn dateien kaputt gehen sollten wegen image erstellung im betrieb dann sollten es hoffentlich wenn überhaupt logdateien sein und die kann man aus dem rsync backup wieder herstellen.

Aber Grundproblem bleibt, wenn man nicht da ist hat läuft das system für längere zeit nicht.

sicherste Lösung wäre sicher ein zweiter rpi, der bei ausfall übernehmen kann, aber das ist sicher aufwändig und es gibt auch da probleme wie du schreibst.

ich probiere es nochmal mit dem set filelog reopen und wenn möglich mit einer dedizierten log sd karte.

MadMax-FHEM

Beim Image ziehen im Betrieb geht es nicht nur um "kaputte" Dateien (wegen offen/inkonsistenz) sondern das Dateisystem kann "durcheinander" kommen.

Es kann dazu führen, dass der PI gar nicht mehr bootet...

Aber wenn es bei dir/für dich klappt: gut.

Viel Erfolg, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

FhemPiUser


MadMax-FHEM

Raid0!?

Bringt doch nix bzgl. Aufallsicherheit...
...wenn dann Raid1.

https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_0

https://en.wikipedia.org/wiki/Standard_RAID_levels#RAID_1

Weiß nicht, ob der PI das kann (wäre ja SW und wenn die "spinnt": naja)...

EDIT: und bzgl. Ausfall wenn keiner da -> möglichst autarker Betrieb... Also alle wichtigen Funktionen OHNE fhem ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

FhemPiUser

ähh ja, raid1 meinte ich natürlich.

ja. mache auch möglichst viel autark und besonders die kritischen Dinge wie heizung etc

Tedious

Auch wenn ich von Raspis schon lange weg bin und auf x86 setze - ggf. könnte ein BananaPi M2/3 (Ultra) eine Lösung sein. Fhem und Co auf die 8 GB eMMC des BPI brennen und die SD nur noch als Logging-Laufwerk verwenden. Damit sollte ein Ausfall der SD nur die historischen Daten betreffen. Oder halt direkt ne SSD dran betreiben, die haben SATA.

Alternativ als schmale Lösung halt nen USB-Stick einstecken, mounten und denn denn fürs Logging und Co verwenden, sind ja nur eine Hand voll Pfande anzupassen.

Btw, ein Brix mit SSD braucht im Mittel 7 Watt, ein Nuc mit i3 rund 10W. Kann viel Nerven schonen und ist bezüglich des Stromverbrauchs billig erkauft.
FHEM auf Proxmox-VM (Intel NUC) mit 4xMapleCUN (433,3x868) und Jeelink, HUE, MiLight, Max!, SonOff, Zigbee, Alexa, uvm...

FhemPiUser

#12
ja, aber statt usb stick oder banana ginge auch am rpi mit einem usb sd kartenleser. das war die ursprüngliche idee. von der leistung her reicht mein rpi3b für fhem...

oder ein günstiges 2bay raid gehäuse wie z.b. https://www.amazon.de/ICY-BOX-Externes-Festplatten-Aluminium/dp/B01BHR3VPA/ref=mp_s_a_1_5?dchild=1&keywords=icy+box+raid+1&qid=1603197007&sprefix=icybox+ra&sr=8-5 mit zwei günstigen ssds. wären knapp 100€, allerdings auch ca 10 watt mehr stromverbrauch...

FhemPiUser

#13
Eine alternative Idee wäre die SD-Karte zu schonen durch Auslagerung von /opt/fhem/log (und evtl. auch /var/log) in eine Ramdisk und z.B. nur 1xtäglich auf SD-Karte zu schreiben. Bei mir werden ca. 40MB pro Tag geloggt in den o.g. Verzeichnissen. Das sollte locker ins RAM des RPI3 passen.

Dazu gibt es mehrere Artikel bezogen auf Ramdisk für /var/log eines RPI:

https://domoticproject.com/extending-life-raspberry-pi-sd-card/
https://forum-raspberrypi.de/forum/thread/4046-var-log-in-eine-art-ramdisk-auslagern-weitere-optimierungen-bezgl-logs/
https://github.com/azlux/log2ram/
https://github.com/StuartIanNaylor/zram-config

Hat mal jemand damit Erfahrungen gemacht?

betateilchen

Das ist doch alles sinnfreier Voodoo-Zauber.... *kopfschüttel*
Dafür ist mir sogar mein Popcorn zu schade.

Wenn ich ein ausfallsicheres System haben will, denke ich doch nicht in Spielzeugkategorien wie Pi oder ähnlichem.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!