Haltbarkeit SD-Karte mit FHEM-Nutzung & Smart-Home?

[Dracolein]

Guten Morgen zusammen,

zunächst wünsche ich allen einen schönen dritten Advent 

Die Suche brachte mir wenig brauchbare Ergebnisse, teils auch schon verjährte Informationen, drum ein neuer Thread mit folgender Frage:

Wie haltbar sind SD-Karten im Raspberry-Pi bei Verwendung des Geräts als Smart-Home Server mit FHEM?

Hintergrundgeschichte:
Ich habe mir vor knapp 3 Wochen einen Raspberry Pi 4 gekauft, um mir ein Smart-Home Dashboard mit FHEM zu basteln. Die Ausbaustufe ist noch im Anfang, d.h. es gibt neben einem ConBee 2 USB-Gateway zwei Osram Steckdosen und 1 Aqara Raumsensor.
Ich logge derzeit den Aqara-Raumsensor sowie die CPU-Temperatur (im 5-Min-Takt). Alles Weitere ist noch default eingestellt. Das Gerät rennt 24/7.
Im Lieferumfang des RPi war eine Sandisk Ultra 32GB Karte, die ich von Beginn an nutzte.
Gestern morgen gab es diverse technische Schwierigkeiten nach weiteren IDeen meinerseits für mein FHEM Projekt. Letztlich entschied ich mich gegen Mittag für ein Backup, fuhr den RPi wie immer herunter, zog die Karte raus und ging zu meinem Windows Rechner, um dort wie immer ein Image zu schreiben.
- Karte in den Leser: keine Reaktion
- dran gewackelt: keine Reaktion
- Windows Neustart: immer noch nichts
- Karte zurück in RPi: bootet nicht (4x blinken der grünen LED)
- Karte in anderen Kartenleser: keine Reaktion
- Karte rein in den Mac: keine Reaktion
- Karte zurück in den Kartenleser am Windows rechner und dran gewackelt: Finger werden heiß!!

Die Karte war also aus dem Nichts plötzlich defekt und muss sogar durch einen internen Kurzschluss richtig heiß geworden sein.
Fazit: neue SD-Karte gekauft, Backup eingespielt, RPi funktioniert wieder.  Danach habe ich mich mit dieser Thematik beschäftigt und diverse Thesen gelesen:
1.) SD-Karte darf nicht zu warm werden
2.) Zuviele Lese-Schreib-Zugriffe schädigen die Karte
3.) defekte SD-Karten im RPi sind keine Seltenheit
4.) ... ?

Nun erhoffe ich mir Klarheit durch Eure Kompetenz und Erfahrungen in dieser Hinsicht.
Ich möchte natürlich für die Zukunft vorbeugen. Worauf sollte man grundsätzlich achten? 

Zu 1.)
habe ich seit gestern einen größere Lüfter im (Plastik-)Gehäuse laufen, die SD-Karte hat einen riesigen AUsschnitt erhalten, CPU-Temperatur bewegt sich im Schnitt bei 45 Grad Celsius.

Zu 2.)
Bin ich noch unsicher, was ich als Laie in FHEM optimieren kann, auch im Hinblick auf meine geplante Erweiterung mit Temperatursensoren, die ich gern alle loggen möchte. In die Logs wird eh nur was geschrieben, wenn der Sensor Änderungen meldet, das kann teils alle paar Sekunden sein, teils passiert 30-60 Minuten gar nichts, je nach Lage. Das FileLog der CPU-Temp habe ich per Attribut auf 5 Minuten (anstelle alle 60 Sek) angepasst.

Zu 3.)
Zumindest spuckt Google einen Haufen Threads wie diesen aus, in dem Leute defekte SD-Karten melden.
Ich persönlich habe allerdings nach jetzt ca. 10 Jahren Digitalfotografie als Hobby noch nie ansatzweise signifikante Probleme mit SD-Karten gehabt. Ich kenne Ausfälle von Flash-Speichermedien eigentlich gar nicht. Natürlich sichere ich dort keine wichtigen Backups drauf, aber Gedanken musste ich mir bis dato nie machen. Eine SD-Karte war aber bei mir auch noch nie als "Hauptfestplatte" im Einsatz, wie es beim RPi der Fall ist.

Zu 4.)
Vielleicht habt Ihr weitere Thesen zum typischen SD-Tot


Vielen Dank für Euer Feedback.

[Dr. Boris Neubert]

Hallo,

Linux loggt viel und das reibt die Karten auf. Ich habe / auf einer SSD, die per USB angeschlossen ist. Das läuft schon 2 Jahre schmerzfrei durch.

Grüße
Boris

[Prof. Dr. Peter Henning]

Logfiles sollten nicht auf die Karte gehen, sondern entweder auf eine externe Platte, eine Ramdisk oder über das Netz auf eine NAS.

Lebensdauer meiner RPi-SD-Karten auf diese Weise > 4 Jahre.

LG

pah

[MadMax-FHEM]

Mein Hauptsystem läuft ohne besondere Maßnahmen auch son seit mehr als 3 Jahren.

Wichtig (aber das würde ich generell tun): regelmäßig Backups!

Und mitnotieren was man so gemacht hat (Pakete installiert, Konfigurationsschritte, etc.)

Alle paar Jahre wechsel ich dann eh das OS und dabei (meist) dann auch gleich die Karte...

Klar hatte ich auch schon mal nen "ungeplanten Wechsel"...

Auch meine Testsysteme (3 Stück) laufen auf SD und prima...

Ich will jetzt niemanden überzeugen auf SD zu gehen/bleiben...
...aber ganz so tragisch ist es dann auch nicht...
...zumindest kann ich das so nicht bestätigen...

Allerdings alles PI2 bzw. mittlerweile getauscht gegen PI3...
PI4 aktuell nur als "Desktop-Rechner", also nicht Dauerbetrieb...

Gruß, Joachim

[KölnSolar]

Ich behaupte: Das Netz verleitet zu viel Irrglaube.

Auch ich hatte mich beim Einstieg mit dem Rpi mit dem interessanten Thema beschäftigt. Ich fand massenhaft Empfehlungen und NoGo's für Kartentypen u. -hersteller. Als Freund des Präsenzhandels habe ich mich dann aber doch für "irgendwelche" Karten entschieden. Keine einzige über die Jahre bisher defekt.

Ich spekuliere, dass es daran liegt, dass ich möglichst nur FHEM installiert habe und FHEM noch die wenigsten Schreibzugriffe verursacht. Ich versuche undurchsichtige npm-,pip-....Geschichten zu vermeiden.

Kürzlich hab ich mir dann pi-hole auf meine 4GB installiert. Da hab ich dann gemerkt, was solche "Fremdinstallationen" an Wahnsinns-traffic auf der SD verursachen. Meine 4GB platzten und ich musste auf 8 GB erweitern.

Ich denke also auch wie Boris u. pah, dass Defekte durch häufige Zugriffe passieren. Die Lösung der beiden ist sicherlich die sicherste/beste Variante. Ich dagegen erspare mir die zusätzlichen Kosten und überlege gewissenhaft, was ich dem Rpi an Anwendungen zumute. Regelmäßige backups von FHEM-Logfiles und config, sowie Kartenimages nach größeren Veränderungen(Systemupdates) lassen mich beruhigt einem SD-Crash entgegensehen.

Grüße Markus
PS: Joachims neuem Beitrag kann ich voll zustimmen.
Edit: Nicht zu vergessen, der sensible Umgang mit FHEM-Logging. Schnell verleitet FHEM zu Schwachsinnsdatensammlungen. Da helfen die Rexexp bei der Filelog-def und die event-on-Attribute. Ich versuche mich bei meinen Modulen auf wenige sinnvolle events zu beschränken. Wer dann in Sonderfällen mehr haben will, kann das mit FHEM-Mitteln bewusst selber machen. Der 08/15-User bleibt aber von Massendaten verschont.

[Dracolein]

Lässt sich die durchschnittliche Häufigkeit von Schreibzugriffen des Gesamtsystems irgendwo nachprüfen? Wäre vielleicht interessant, wenn man sein eigenes System mit einer Empfehlung "geht gerade noch so" bzw. "heftig viel, änder was!" abgleichen könnte.

Logfiles auf einen angeschlossenen USB-Stick loggen:
Verhält sich ein USB Stick anders, als eine SD-Karte im Hinblick auf die Verträglichkeit von Schreibzugriffen?
Denn einen USB-Stick könnte ich problemlos anschließen, wenn das Probleme ersparen würde... (in dem Fall freue ich mich über ein Howto, wie man Filelog-Devices modifizieren muss, um Dateien auf dem Stick zu speichern. Vermutlich müsste ich den Pfad im DEF ändern?)

Achja, ich hatte auch etwas vom Spannungsproblemen gelesen, die bei Verwendung ungeeigneter Netzteile auftreten können. Das sei auch eine THeorie, worunter die SD-Karte leiden könnte. Für mich nicht nachvollziehbar, ob das denkbar wäre.


edit:

Ein tool namens "iotop" gegoogelt ( https://www.pcwelt.de/tipps/Iotop-Belastende-Festplatten-Prozesse-entlarven-9791167.html )

[JoWiemann]

Habe das hier noch gefunden: https://www.elektronikpraxis.vogel.de/zehn-gruende-die-fuer-industrie-sd-karten-sprechen-a-284360/

[claudio-fhem]

- Karten nicht zu klein wählen, dann kann der Controller Fehler mit leeren Blocks kompensieren.

- Wenn irgendwas regelmäßig schreibt (z.B. .jpg oder .mp4) immer auf einen gemounteten USB-Stick oder eine alte Festplatte mit SATA/USB-Adapter.

- Spätestens vor dem nächsten Raspbian/OS Upgrade eine Kopie machen und gut aufheben.

- Ich habe seit 2014 Raspis 24/7 laufen (nicht mit fhem) und bisher noch keine Karte im laufenden Betrieb verloren (Sandisk Ultra 16 GB). Am kritischsten sind Stromverluste (während Schreibzugriffen), daher wichtige Systeme immer an einer USV.

[Wzut]

Logfiles sollten nicht auf die Karte gehen, sondern entweder auf eine externe Platte, eine Ramdisk oder über das Netz auf eine NAS.

Lebensdauer meiner RPi-SD-Karten auf diese Weise > 4 Jahre.

SSD & NAS sind bei mir auch auf allen FHEM Instanzen am Start, die große Lebensdauer kann ich auch bestätigen
Ich hatte aber auch schon ein RPi FHEM Testsystem ohne SSD/NAS das hat im zwei Wochenrythmus die SDs gefressen

[swsmily]

Im Raspi hat sich meine SD-Karte langsam nach rund 3,5 Jahren verabschiedet. Festgestellt hab ich es, dass das System immer wieder kurz hing, es lief also noch, aber nicht mehr zuverlässig (Licht ging durch Bewegungsmelder nicht mehr oder sehr verzögert an).

Ich habe daraufhin mit Win32Diskimager ein Backup der defekten SD-Karte erstellt.
Ein älteres Backup (seit letzter Änderung im Raspi-System) auf eine neue SD-Karte gespielt und FHEM von der defekten SD (Daten liesen sich mit Ext2Explore aus dem Image auslesen) wiederhergestellt, danach lief alles wieder ohne Störungen.

Im Handy hatte ich es dafür einmal, eine Karte gerade mal 3 Wochen alt, wurde plötzlich weder im Handy noch im Notebook erkannt. Zum Glück waren es nicht viele Daten die mir dadurch verloren gingen.


Mein Fazit daraus: Regelmäßige Backups sind sehr wichtig um sich viel Arbeit zu ersparen.

[Wernieman]

Egal auf welchem System ... Backup sind wichtig und werden gerne vergessen ...

[Dracolein]

Logfiles auf einen angeschlossenen USB-Stick loggen:
Verhält sich ein USB Stick anders, als eine SD-Karte im Hinblick auf die Verträglichkeit von Schreibzugriffen?

Hier würde mich Eure Meinung drüber interessieren.

Und eine Frage hinterher geschoben, die mich als Noob derzeit vor Probleme stellt:
Ich habe einen leeren USB-Stick angesteckt. Wie muss ich denn die Syntax des Pfads zur Logdatei ändern, damit dieser Datenträger angewählt wird?

Derzeit sieht mein Beispiel-Log-Def noch so aus:

Code Auswählen Erweitern

./log/Log_RaumsensorFranzi_H-%Y-%m-%d.log RaumsensorFranzi_H|RaumsensorFranzi_H:humidity:.*
Mein FHEM liegt in /opt/fhem/ und dort ist der oben definierte Ordner /log zu finden.

Wenn ich mich richtig erinnere, muss ich zunächst den Stick mounten und dafür ein Verzeichnis auswählen, in den selbiger gemountet werden soll.
Ich würde mich nach dieser Anleitung ( https://www.elektronik-kompendium.de/sites/raspberry-pi/1911271.htm ) entlang hangeln, passt das dann?

btw, es ist wirklich interessant für Windows- & Mac-Nutzer, wie aufwändig alltägliche Prozesse am Raspi sein können 

[MadMax-FHEM]

Egal auf welchem System ... Backup sind wichtig und werden gerne vergessen ...

UND ebenso wichtig: auch mal "üben", ob das Restore mit dem erstellten Backup auch klappt...

(weil sonst ist auch das "beste" Backup "für die Tonne")

Gruß, Joachim

[Wernieman]

Ob es sinnvoll ist, Logfiles auf einen USB-Stick (beim Pi) zu schieben, bin ich mir nicht soooo sicher
- USB-Sticks sind von den Speicherzellen schlechter als (gute) SDCards
- Der USB-Bus vom Pi ... ist sehr speziell

[rcmcronny]

Also meine sterben auch so alle 3-4 Jahre im Durschnitt, etwas geschrieben wird ja immer. Ich mach aber ein ImageBackup und ein Filebackup der Wichtigen Dateien jeweils und so ist es im Fall der Fälle nur ein Rückspielen des Image auf neue SD Karte und weiter gehts. Früher waren es 16GB SDs nun meistens 32GB. Die Images sind ja kompromiert nicht wirklich groß dann

Ronny

[NewRasPi]

Ob es sinnvoll ist, Logfiles auf einen USB-Stick (beim Pi) zu schieben, bin ich mir nicht soooo sicher
- USB-Sticks sind von den Speicherzellen schlechter als (gute) SDCards
- Der USB-Bus vom Pi ... ist sehr speziell

Hallo Forum, hallo Wernieman
liegt der "Vorteil" an den Log-Dateien auf einem USB-Stick zu schreiben nicht mehr da, dass dann diese Schreibzugriffe eben nicht auf der SD-Karte durchgeführt werden? Die Hoffnung wäre eben das dieses weniger schreiben die Lebensdauer der SD-Karte sehr verlängert.
Wenn dann der USB-Stick kolabiert ist wenigstens das Raspian und FHEM System noch da.

@ rcmcronny
Meine Backups der SD-Karten sind immer genau so groß wie die gesammte Speichergröße der Karte. Könntest Du bitte mal einen Hinweis geben, wie man diese Image (mit Win32DiskImager) verkleinern kann. Vor allem wäre das auch von Vorteil wenn man eine laut Angaben gleich große SD-Karte (mit einem Byte weniger) doch fürs Rücksichern verwenden kann.
Vielen Dank für Tipps.
MfG NewRasPi

[Jens_B]

Hallo Forum, hallo Wernieman
liegt der "Vorteil" an den Log-Dateien auf einem USB-Stick zu schreiben nicht mehr da, dass dann diese Schreibzugriffe eben nicht auf der SD-Karte durchgeführt werden? Die Hoffnung wäre eben das dieses weniger schreiben die Lebensdauer der SD-Karte sehr verlängert.
Wenn dann der USB-Stick kolabiert ist wenigstens das Raspian und FHEM System noch da.

@ rcmcronny
Meine Backups der SD-Karten sind immer genau so groß wie die gesammte Speichergröße der Karte. Könntest Du bitte mal einen Hinweis geben, wie man diese Image (mit Win32DiskImager) verkleinern kann. Vor allem wäre das auch von Vorteil wenn man eine laut Angaben gleich große SD-Karte (mit einem Byte weniger) doch fürs Rücksichern verwenden kann.
Vielen Dank für Tipps.
MfG NewRasPi

Ich hänge mich mal dran an den Thread:
Ich selber habe 2  x 32GB SD Karten schon seit mehreren Jahren in meinem "FHEM" PI laufen (die nutze ich im Wechsel, einmal im Jahr tausche ich die Karte zurück, nachdem ich das Backup auf die Karte gespielt habe).
Habe so schon von einem PI2 -> PI3 -> PI3+ -> PI4 gewechselt . Immer ohne größere Probleme.
Ich mache wöchentlich eine Sicherung auf mein Netzlaufwerk per script -> https://www.linux-tips-and-tricks.de/de/raspberry/23-pi-erstellt-automatisch-backups-von-sich-selbst-pi-creates-automatic-backups-of-itself/
Die Sicherung erfolgt als komprimiertes tar Archiv. Die Sicherung ist nur so groß wie der benutzte Speicherplatz auf der SD Karte.
Das heißt man könnte theoretisch die Sicherung auf eine kleinere Karte zurückspielen.

Das hat bisher immer Problemlos geklappt. Das zurückspielen des Backups, mache ich an einem anderen laufendem PI (natürlich geht jeder anderer Linux Rechner auch) über folgenden Befehl:
sudo raspiBackup.sh -d /dev/sda /share/raspberry-backups/raspi-fhem-2/raspi-fhem-2-tar-backup-xxxxxxxx-yyyyyy/

(sda ist die SD Karte die später wieder in den PI kommt, ich nutze dazu einen SD->USB Adapter)

Das wars schon...

[Wernieman]

@NewRasPi

Unix mag es gar nicht, wenn eine Device im laufenden System nicht mehr schreibbar ist. Egal ob log oder root. Wenn der SUB-Stick defekt und damit reagiert Dein System nicht, machst Du (wie ich Dich einschätze) einen reboot und wunderst Dich, das "die Kiste" gar nicht mehr hochkommt.

Wie wahrscheinlich ist, das Du dann auf den Stick tippst?

[Dracolein]

Meine Backups der SD-Karten sind immer genau so groß wie die gesammte Speichergröße der Karte. Könntest Du bitte mal einen Hinweis geben, wie man diese Image (mit Win32DiskImager) verkleinern kann. Vor allem wäre das auch von Vorteil wenn man eine laut Angaben gleich große SD-Karte (mit einem Byte weniger) doch fürs Rücksichern verwenden kann.

Da hänge ich mich ebenfalls an diese Frage dran, denn ich bin Samstag GENAU daran gescheitert!
Ursprungs SD-Karte: Sandisk Ultra 32 GB
Ersatzkarte: Sandisk Ultra 32 GB

Bin dann schnell shoppen gewesen und habe eine Sandisk Extreme 32 GB und eine Sandisk Extreme 64 GB erworben, um am Wochenende wenigstens irgendwie weiterzumachen.
Glücklicherweise funktionierte bereits die 32 GB Variante. Dennoch schaute ich zunächst echt doof.

Und ja, ich mache meine Backups bisher auch alle von Hand auf einem anderen Rechner mittels Win32DiskImager und mülle mir mit den Backup-Files  mein NAS unnötig zu.

[Frank_Huber]

falls (gegen die Empfehlung) das Raspbian mit GUI installiert ist gibt es auch den "SD Card Copier",
dieses Programm erstellt eine 1:1 Kopie der SD Karte im laufenden Betrieb.
die Größe spielt dabei keine Rolle. (der verwendete Platz muss halt scho drauf passen)

damit erstelle ich regelmäßig Kopien meiner produktiven Instanzen.
Das tägliche FHEM Backup geht direkt auf den Fileserver.

[rcmcronny]

Ich speichere per NFS per DD und komprimiere dann per xz.  (und natürlich rückwärts dann auch dd von der Linux shell)

Das klappte bisher immer Problemlos und zur not kann man das Image ja auch mounten und Dateien so wiederherstellen, wenn es nötig ist.
Dein Problem, das er Platz zu klein auf ner neuen SD ist, hatte ich noch nie, sollte sich aber mit verkleinern des Dateisystems auch lösen lassen, solange es nicht randvoll mit Daten ist.

Für die VMs nutze ich da ggf auch teilweise mal zerofree als Tool (http://frippery.org/uml/index.html)

Man kann halt nicht eine generelle "Lösung" geben, die immer perfekt arbeitet, oft gibt es so kleine Problemchen, wo man dann halt etwas Wissen braucht um das zu lösen (daher auch kein Genereller Weg leider).

Ronny

[Dracolein]

Machen meine Anstrengungen eigentlich Sinn, FileLog-Device Einträge auf das Nötigste zu reduzieren, wenn gleichzeitig FHEM und Raspbian im Hintergrund werkeln? Das Logfile von FHEM selbst wird doch nahezu permanent geschrieben, oder?

[Waldmensch]

Ein Backup von der ganzen SD Karte zu machen, halte ich für Unsinn. Ich habe ein altes Synology NAS DS213 mit 2 1TB Platten. Das stellt mit ein NFS Share pi_backup zur Verfügung, welches ich per fstab auf allen pi's nach /media/backup mounte. Im Fall von FHEM packe ich dort nachts per cron ein tar Archiv des opt Verzeichnisses hin. Das ganze überschreibe ich nach 2 Tagen. Ich habe also immer ein Backup von gestern und von vorgestern.
Wenn die SD Karte hin ist, nehme ich eine Neue, ziehe mir ein aktuelles Raspbian, bringe alles auf neuesten Stand + fstab Backup Verzeichnis einbinden. Dann entpacke ich das Backup Archiv und FHEM ist wieder da. Am längsten dauert es, eine SD Karte zu besorgen. Der Rest ist in <1h erledigt. Ich habe 8 Pi's für diverse Aufgaben (one device for one job). Das o.g. Prinzip ist für Alle gleich.


Gesendet von iPhone mit Tapatalk

[Prof. Dr. Peter Henning]

Die Aussage,

Ein Backup von der ganzen SD Karte zu machen, halte ich für Unsinn

zeugt von wenig Verständnis. Das mag noch ok sein, wenn nur FHEM als Anwendung läuft. Ich habe auf meinen Raspberrys aber diverse andere Anwendungen, von der Genealogie bis zum Semantic MediaWiki. Dabei ändern sich Dateien durchaus auch an anderen Stellen, es gibt neue Plugins etc. Diesen Wust auf einem neuen Betriebssystem nachzuinstallieren kostet etliche Stunden - es ist daher viel ökonomischer, in regelmäßigen Abständen ein komplettes Image der SD-Karte zu erzeugen, das sich innerhalb von wenigen Minuten auf eine frische Karte schreiben lässt.

LG

pah

[Waldmensch]

Das Problem ist halt das ,,regelmäßig". Jede Nacht ein komplettes Image wegschreiben, nur weil sich wenige Dateien geändert haben, ist nicht sehr effizient. Kann man aber machen.
Bezüglich Raspi als Server für multiple Dienste: ich Rate davon ab. As said, one device one Job. Wenn so ein Raspi abschmiert ist dann erstmal alles lahmgelegt was darauf läuft. Der FHEM ist bei mir der ,,Ausfaller" schlechthin. Da würde ich nie den PiHole, die MariaDB oder den Mosquitto mit draufpacken.
Es gibt sicher viele Wege nach Rom und man muss letztlich für sich den Richtigen finden. Ich habe FHEM seit mehr als 10 Jahren laufen (kann das wirklich sein? ) Nach 2 maligem Komplettverlust der Config, habe ich für mich das Backup des opt Verzeichnisses für diese Raspi Instanz als optimal erkoren.


Gesendet von iPhone mit Tapatalk

[Prof. Dr. Peter Henning]

Alle Datenbanken liegen auf meiner NAS.

LG

pah

[Dracolein]

Kriege ich es als Laie hin, eine Verbindung zu meiner Synology herzustellen, sodass ich FHEM Logfiles dort abspeichern könnte?

Die entsprechende Konfiguration der Synology habe ich bereits gefunden, aber dem Linux Dateisystem beizubringen, wie es den freigegebenen Ordner der Syno mounten soll, bringt mich vermutlich sofort an meine Grenzen

[Waldmensch]

Du musst auf der Synology einen NFS Share freigeben und diesen auf dem Raspi mounten. Zu beidem liefert Google hunderte Treffer
Bsp. https://www.elektronik-kompendium.de/sites/raspberry-pi/2102211.htm

Gesendet von iPhone mit Tapatalk

[NewRasPi]

@NewRasPi

Unix mag es gar nicht, wenn eine Device im laufenden System nicht mehr schreibbar ist. Egal ob log oder root. Wenn der SUB-Stick defekt und damit reagiert Dein System nicht, machst Du (wie ich Dich einschätze) einen reboot und wunderst Dich, das "die Kiste" gar nicht mehr hochkommt.

Wie wahrscheinlich ist, das Du dann auf den Stick tippst?

Hallo @ Wernieman
Danke für Deine Antwort.
Mal so ein Gedankengang von einem Computer-Laien.
Bei so viel Kompetenz hier im Forum, könnte da nicht mal jemand sich Gedanken machen, ob es eine "Fall- Back- Funktion" für FHEM bei den Log Verzeichnis machbar wäre.
Quasi, liebes FHEM mach die Log-Dateien auf den Pfad xy und wenn dieser Pfad nicht verfügbar ist, dann leg die Log-Dateien ins Standartverzeichnis /opt/fhem/log/fhem-2019.log
Bei einem Programm das ohne seine Log-Datei nicht mehr startet wäre das für mich eine super Funktion.
So nebenbei, ich habs über eine ssh Verbindung mit dem Editieren der fhem.cfg auch schon mal geschaft den Pfad wieder zurück zu biegen und damit meinem FHEM wieder Leben eingehaucht.
Nun bin ich gespannt was die Spezialisten dazu meinen.
MfG NewRasPi

[Dracolein]

Du musst auf der Synology einen NFS Share freigeben und diesen auf dem Raspi mounten. Zu beidem liefert Google hunderte Treffer
Bsp. https://www.elektronik-kompendium.de/sites/raspberry-pi/2102211.htm

Gesendet von iPhone mit Tapatalk

Danke, habs inzwischen hinbekommen, recht problemfrei. Morgen teste ich mal, die Logfiles meiner Sensoren dorthin auszulagern.

[Hadl]

Bei mir ists gerade mal wieder soweit, eine SD Karte gibt so langsam den Geist auf.

Ich hab nun einen Raspi mit FHEM seit 4 Jahren 24/7 im Betrieb und logge auch sehr viele Daten.
Meine sqlite Datenbank wächst dadurch in 6 Monaten auf ca. 15GB

Dadurch passiert es mir, das die SD Karten immer ca. nach 4-12 Monaten defekt werden.
Wenns mal angefangen hat dann hilft es auch nichts das man den Speicherplatz auf der Karte weitgehend freimacht (Datenbank und Logs löscht) und dann mit ner leeren Datenbank wieder anfängt. Diese ist dann nach wenigen Tagen auch wieder korrupt.

Ich hab bisher 64GB Sandisk Ultra karten verwendet, die auch nie mehr als 70% voll waren, trotzdem gab es die Probleme.
Ich habs nun mal in der gleichen Konfiguration laufen lassen und mir sind zwei dieser Karten nach weniger als 6 Monaten defekt geworden.
Der Raspi liegt offen da, und ist auch sonst nicht sehr gestresst... Temperatur sollte also kein Problem sein.

Interessant finde ich das ein reines "anhängen" der Daten sobald zu Speicher Problemen führt.
Warum werden so viele Sektoren überschrieben? Ist die Current Tabelle, der Index,...?

Wie könnte man am loggen für SD Karten optimieren?
Mir fällt ein:
- Weniger Daten loggen / Größere Karte nehmen (Schlauberger Lösung )
- Daten im RAM halten uns seltener schreiben => Weniger Index und Current änderungen auf der Karte, z.b. durch den Asynchron mode
- Index vollständig in den RAM verschieben (keine Ahnung ob sqlite das kann)
- Datenbankformat umstellen so das keine bereits beschriebenen Sektoren wieder geändert werden müssen, sondern nur angehangen werden muss. (DB DateiStruktur optimieren)

[Waldmensch]

Man könnte auch mit ein paar Mausklicks auf einem Synology Nas einen Mariadb Server aufsetzen und dorthin loggen. Dann mit FHEM Bordmitteln die DB regelmässig konsolidieren bzw. Unnötige Daten löschen. Vor allem aber im Voraus Datensätze vermeiden. Niemand interessiert der Batteriestatus eines FHT Devices von vor einem Jahr (symbolisch)


Gesendet von iPhone mit Tapatalk

[Jens_B]

Ein Backup von der ganzen SD Karte zu machen, halte ich für Unsinn. Ich habe ein altes Synology NAS DS213 mit 2 1TB Platten. Das

Ich halte das für keinen Unsinn, um es mal so auszudrücken. Das Vollbackup, dauert rund 8 Minuten auf meinem PI4. Wenn die SD Karte tatsächlich mal ausfällt, oder der PI. Ich habe dann ch innerhalb von max 20 Minuten alles ohne nachdenken wieder am Start, und sogar meine Frau bekommt es hin das Backup auf eine neue SD Karte wieder einzuspielen.

[Waldmensch]

Also macht der Pi jede Nacht aus sich selbst ein Backup, was er auf ein NAS ablegt, damit es auch für Deine Frau erreichbar ist. Im Fall eines Ausfalls wird es mit einem Image Programm manuell auf eine neue SD Karte geschrieben? Wie geht man mit defekten Daten um, die ja mit dd sicher mitkopiert werden? Wieviele Backups hältst Du vor? Beschreib doch mal den kompletten Ablauf.


Gesendet von iPhone mit Tapatalk

[rcmcronny]

Nur weil es für _DICH_ Blödsinn ist, muss es das für andere nicht sein. Man lernt aus Problemen der Vergangenheit (sollte man jedenfalls)
Ich habe tägliche FHEM Backups natürlich und 2x im Monat  (Anfang und Mitte) ein komplettes DD Image. Das reicht für mich problemlos aus, da ich alles so innerhalb kurzer Zeit wiederherstellen kann.
Die Images werden vom Server nochmal (simpel) geprüft und komprimiert mit xz. Das ist noch verbesserungswürdig, aber erstmal ok für mich.

Raspbian Image draufziehen reicht ja nicht, idR hat man viele Packages, die man noch installieren muss, klar kann man die auch als Liste sichern, aber Arbeit macht es trotzdem.

Ronny

[Dracolein]

Guten Morgen zusammen,

Zwischenfrage zum Thema FileLog und dessen Dateipfad:
Kann man den Zielpfad für Logfiles nur global via "attr global logfile" für alle Dateien ändern, oder lassen sich Pfade einzelner FileLog-Devices auch einzeln ändern?

Hintergrund:
Ein freigegebener NFS Pfad zu meiner Synology steht und wird augenscheinlich auch nach reboot des raspi gemountet. Jedoch möchte ich im ersten Schritt ungern gleich alle systemrelevanten Logfiles verschieben, womit ich ggf FHEM abschieße, wenn irgendwas beim mounten doch nicht klappen sollte. Lieber würde ich mit einzelnen FileLog Devices herumprobieren und schauen, ob selbige zuverlässig geschrieben und gelesen werden können.

[Frank_Huber]

...und 2x im Monat  (Anfang und Mitte) ein komplettes DD Image. ...

Hi Ronny,

könntest Du bitte hierzu den "Lösungsweg" posten? Ich mache meine SD Image manuell und daher eher unregelmäßig. :-/

Danke & Grüße
Frank

[Jens_B]

Also macht der Pi jede Nacht aus sich selbst ein Backup, was er auf ein NAS ablegt, damit es auch für Deine Frau erreichbar ist. Im Fall eines Ausfalls wird es mit einem Image Programm manuell auf eine neue SD Karte geschrieben? Wie geht man mit defekten Daten um, die ja mit dd sicher mitkopiert werden? Wieviele Backups hältst Du vor? Beschreib doch mal den kompletten Ablauf.


Gesendet von iPhone mit Tapatalk

Also der PI macht Nachts ein Backup, die Dienste werden dabei vorher angehalten. So vermeide ich das irgendwas weiter auf der SD Karte rumrödelt. Das Backup dauert 8 Minuten.
Zum Backup nehme ich das genannte Script. -> https://www.linux-tips-and-tricks.de/de/raspibackup/

Wenn die Karte defekt sein ist, oder was auch immer die Hardware (ich habe für diese Fälle einen Ersatzpi + SD Karte) kann ich mit dem funktionierendem Raspberry über das Script das Backup auf die Karte zurückspielen.

Dann hat man in 20 Minuten wieder ein funktionierendes System.
Ich halte auf dem "Reserve PI" im Prinzip sogar ein vorkonfiguriertes FHEM mit allem drum und dran vor, was zwar meist nicht ganz aktuell ist (4-5 Monate alt), aber die Standard Definitionen sind dort drauf. Und so oft kommt auf der Server meist nichts neues dazu. Damit kann meine Frau, sollte ich nicht da sein, das Ganze sogar innerhalb von 5-10 Minuten erledigen. Sie braucht ja nur das defekte System gegen das Backup System tauschen.

[Dracolein]

Guten Morgen zusammen,

Zwischenfrage zum Thema FileLog und dessen Dateipfad:
Kann man den Zielpfad für Logfiles nur global via "attr global logfile" für alle Dateien ändern, oder lassen sich Pfade einzelner FileLog-Devices auch einzeln ändern?

Hintergrund:
Ein freigegebener NFS Pfad zu meiner Synology steht und wird augenscheinlich auch nach reboot des raspi gemountet. Jedoch möchte ich im ersten Schritt ungern gleich alle systemrelevanten Logfiles verschieben, womit ich ggf FHEM abschieße, wenn irgendwas beim mounten doch nicht klappen sollte. Lieber würde ich mit einzelnen FileLog Devices herumprobieren und schauen, ob selbige zuverlässig geschrieben und gelesen werden können.

Ich zitiere mich selbst und glaube rausgefunden zu haben, dass absolute Pfadangaben in FileLog Devices möglich sind wie z.B.

Code Auswählen Erweitern

/synology/raspiaufds/Log_RaumtempEG-%Y-%m-%d.log 1wire_Temp1:temperature:.*

Der Pfad /synology/raspiaufds liegt außerhalb der fhem-Installation auf dem raspberry und ist gemountet auf mein NAS. Hier wurde nach der Dev-Änderung auf o.g. Pfad automatisch eine Logdatei angelegt und wird fröhlich mit Inhalt beschrieben.

Macht man dem fhem-System Probleme, wenn man in global den Pfad der logfile ( ./log/fhem-%Y-%m.log) ebenfalls auf einen anderen (externen) Ordner verschiebt?
Was würde u.U. passieren, wenn fhem startet und der Ordner noch nicht gemountet ist? Die statefile (  ./log/fhem.save ) würde lokal verbleiben.

[Prof. Dr. Peter Henning]

Kann ich aus eigener Erfahrung sagen: Dann kann FHEM hängenbleiben. Direktes Schreiben aus FHEM auf eine nicht lokal gepufferte Netzwerkverbindung ist nicht zu empfehlen. Besser die Logs lokal anlegen und nächtlich beim Archivieren auf die NAS schieben.

LG

pah

[claudio-fhem]

...das ist ein Backup, aber senkt nicht die Schreibbelastung der SD-Karte. Daher stopf ich einen USB-stick in den Raspi, z.B. 16 GB, mit einer 8 GB Partition, der Rest unpartitioniert. Darauf dann das Speichern der Daten (hohe Schreibbelastung).

Ich habe bisher einen (!)  guten (Sandisk) USB 3 Stick kaputt geschreiben, indem ich ihn als einzige "Festplatte" in einem Rechner mit einem Linux rolling release verwandt habe, ca. einmal pro Woche das Betriebssystem upgedatet (jeweils ca. 400-1500 Updates) und jeden Tag fleissig Firefox benutzt. Nach ca. 13 Monaten hat er sich in "read-only" geschaltet und es war vorbei.

[Dracolein]

Kann ich aus eigener Erfahrung sagen: Dann kann FHEM hängenbleiben. Direktes Schreiben aus FHEM auf eine nicht lokal gepufferte Netzwerkverbindung ist nicht zu empfehlen. Besser die Logs lokal anlegen und nächtlich beim Archivieren auf die NAS schieben.

LG

pah

Danke für die Einschätzung.


Leider scheint meine Lösung für das mounten des nfs-Laufswerks nicht ganz mit FHEM zu klappen. Nach einem kompletten Restart des Raspis gab es in FHEM sofort Fehlermeldungen am Beispiel:

2019.12.17 18:13:39 1: configfile: Can't open /synology/raspiaufds/Log_RaumsensorFranzi_H-2019-12-17.log: No such file or directory
Please define Log_RaumsensorFranzi_H 5de62896-f33f-4dec-a4ea-6fbf766e84c24cd7 first

Und das für sämtliche FileLog-Devices, dessen Pfade ich heute nachmittag verändert hatte.

Hintergrund:
Ich habe das nfs-Verzeichnis mit autofs gemountet.

Als Ursache glaube ich erkannt zu haben, dass autofs den Pfad erst mountet, wenn dieser am Client erstmals angefragt wird. Vermutlich wartet fhem nicht eine kurze Zeit, sondern gibt bei augenscheinlichem Nichtvorhandensein des Laufwerkspfads diese Fehlermeldung ab.

Ein händischer shutdown restart nur von FHEM behob das Problem prompt und auch meine Prüfung auf Erreichbarkeit im Vorfeld abseits von FHEM war fehlerfrei.
Daher vermute ich, dass ich bei meiner autofs-Konfiguration keine Fehler gemacht habe, sondern vielleicht auf das falsche Pferd setze? Wenn meine Einschätzung stimmt, müsste ich irgendwie vor dem Start von FHEM den Pfad anfragen, damit dieser gemountet wird. Oder ich müsste den Mount unmittelbar zum Systemstart tätigen.
Jedoch fehlen mir für alle Optionen das Wissen 

Über Hilfe, ggf. einige Stichworte für meine Recherchen, wäre ich dankbar und würde mich mit einem virtuellen Glühwein on the rocks bedanken. Angesichts 12°C am 17. Dezember... 

[Wzut]

also ich verwende auch ein nfs der Syno als Log dir , allerdings habe ich es beim mount Befehl bzw in der fstab einfach über /opt/fhem/log gelegt.
D.h. beim Start des Rpi geht vllt noch etwas direkt auf die SD, aber dann wenn der Mount Befehl gegriffen hat nicht mehr.

[Dracolein]

d.h. Dein mount überlagert die anfänglich lokale Ordnerstruktur ? Thats works? 
Ich probiere gerade mit fstab rum, finde aber bisher keine lauffähige Konfiguration. Im rpi config hab ich bereits eingestellt, dass der Bootvorgang auf eine vorhandene Netzwerkverbindung warten muss, damit fstab nicht zu früh ausgelöst wird

[Prof. Dr. Peter Henning]

That(s) works?

Aber ja - warum auch nicht? Ist Unix-Standard.

LG

pah

[Waldmensch]

Ich ziehe das mounten über die fstab grundsätzlich vor. Entweder stell ich mich mit autofs zu bräsig an oder es ist wirklich fragil. Bei mir hat es bisher nur Probleme bereitet. Meist war der Mount nicht da wenn er da sein sollte, oder er war weg wenn man es nicht erwartet hat. Das Resultat ist immer dasselbe, das letztlich auf den mountpoint im lokalen FS geschrieben wurde. Ist mir über die fstab noch nie passiert, solange das Share serverseitig verfügbar war


Gesendet von iPhone mit Tapatalk

[claudio-fhem]

Der NFS-share wird ja grundsätzlich über ein Verzeichnis gemountet, warum nicht über das Originalverzeichnis von fhem?
Solange das NAS nicht gemountet ist, schreibt fhem auf die SD-KArte, sobald der mount steht, auf das NAS.

Was mit Daten passiert, die geschreiben werden sollen, während des mountens: Keine Ahnung :-D

[Dracolein]

Ich habs nun in Kombination hinbekommen
a.) in der raspi-config den Bootvorgang gestoppt, bis eine aktive Netzwerkverbindung vorhanden ist
b.) in der fstab

Code Auswählen Erweitern

192.168.178.10:/volume1/raspiaufds /synology/raspiaufds nfs rw,sync,hard,intr,x-systemd.automount 0 0
eingetragen, womit es funktioniert. Mit den parametern "defaults" o.ä. lief nichts.

Wie gesagt ist das ein gemounteter pfad ausserhalb der fhem Ordnerstruktur, wohin ich derzeit ausschließlich meine wenigen filelog-Logfiles schreiben lasse.

Der NFS-share wird ja grundsätzlich über ein Verzeichnis gemountet, warum nicht über das Originalverzeichnis von fhem?
Solange das NAS nicht gemountet ist, schreibt fhem auf die SD-KArte, sobald der mount steht, auf das NAS.

Was mit Daten passiert, die geschreiben werden sollen, während des mountens: Keine Ahnung :-D

ist ein interessanter Ansatz. So würde auch ein mount-fail-Problem verhindert werden, weil fhem den Fehler gar nicht spürt.
Aber wie prüft man dann, ob derzeit gemountet ist, oder nicht?

[Waldmensch]

Man könnte das Vorhandensein einer Datei überprüfen, die es nur auf dem Share gibt. Zum Beispiel eine Datei mit touch /mein/share/.is_share anlegen und dann mit ls /mein/share/.is_share auswerten. Wenn nicht gemounted liefert ls kein Ergebnis


Gesendet von iPhone mit Tapatalk

[Wzut]

@Dracolein , meine fstab , meine Syno hat die 0.2 :

Code Auswählen Erweitern

192.168.0.2:/volume1/logs/ /opt/fhem/log nfs rw,addr=192.168.0.2 0 0

[Dracolein]

Aber ja - warum auch nicht? Ist Unix-Standard.

LG

pah

Aus Sicht des Dateisystems habe ich keine Zweifel.

Ich dachte primär an die FHEM-Installation. Wenn wir einmal annehmen das System läuft viele Monate stabil durch (=alle aktuellen Files liegen auf dem NAS) und dann wird ein Reboot durchgeführt, bei dem das mounten des NAS minimal später passiert, als der FHEM-Start, dann greift fhem beim Systemstart zunächst auf die lokalen, völlig veralteten Files zu. Ohne tief Ahnung vom System zu haben, könnte ich mir vorstellen, dass dies massenhaft Fehler produziert

[Eisix]

Hallo,

wenn eh ein NAS da ist warum nicht gleich ganz vom Netz booten.


https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md


Gruß
Eisix

[Wzut]

wenn eh ein NAS da ist warum nicht gleich ganz vom Netz booten.

das macht mein uralt RPi auf dem DoorPi läuft, eine kleine SD aus einer alten Kamera nur mit /boot Part.
Läuft so auch schon ein paar Jahre ohne Probleme.

[rudolfkoenig]

Ich hatte 4 Jahre lang FHEM auf einem Rechner betrieben, der sein Root-Filesystem und FHEM auf einem billigen 4GB USB-Stick gehabt hat.
Kaputtgegangen ist nach 4 Jahren das Mainboard.

Ich habe vorher etliche Massnahmen getroffen, damit Schreibzugriffe minimiert werden, Stichwort ist (bzw. war damals) Linux laptop mode.
Mein "HOWTO" von damals (2008):

Code Auswählen Erweitern

echo 3600   > /proc/sys/vm/laptop_mode
echo 360000 > /proc/sys/vm/dirty_writeback_centisecs
echo 360000 > /proc/sys/vm/dirty_expire_centisecs
echo 40     > /proc/sys/vm/dirty_ratio
echo 40     > /proc/sys/vm/dirty_background_ratio
Weiterhin habe ich root mit noatime gemountet, und alle Dienste abgeschaltet, die ich auf dem System nicht gebraucht habe.

Diese Einstellung hat Nachteile (z.Bsp. Datenverlust beim Stromausfall, und manche Programme kommen mit noatime nicht zurecht), die ich aber in Kauf genommen habe.

[fantalin]

Hallo,
hier wurden ja interessante Lösungen angeboten, um die Haltbarkeit einer SD-Karte zu erhöhen...
Bei meiner FHEM - Installation mit großen Log-Dateien und Log-DB's ging eine preiswerte 32GB SD nach ca. 3 Jahren kaputt.
Beim kopieren der SD mit dd traten Lesefehler auf.
Nach dem Studium einiger Heise-Artikel kaufte ich vor knapp drei Jahren die MicroSDHC-Speicherkarte 32GB, Samsung, PRO Endurance. Seitdem keine Fehler/Probleme und eine gute Performance.

Grüße
Jochen

[Sörn]

Um die Liste der Tipps noch ein wenig zu erweitern...

1) Logs in einer Ramdisk ablegen.

Ich speichere logs von FHEM und anderen Diensten (lighttpd, cron) in /mnt/logrd.

Hier ein Beispiel, wie man eine 8M große ramdisk anlegt:

Code Auswählen Erweitern

mkdir /mnt/logrd
echo 'none /mnt/logrd tmpfs nodev,nosuid,noexec,noatime,size=8M 0 0' >> /etc/fstab

8MB sind nicht viel, aber für meine Zwecke ausreichend. Ich reboote das System alle paar Monate, aber spätestens beim Kernel-upgrade. Wenn man besonders verboses debugging möchte, ist die Ramdisk nach wenigen Stunden voll. Bei mir ist's meistens level 1.

Die fhem.cfg muss natürlich auch entsprechend angepasst werden:

Code Auswählen Erweitern


attr global logfile /mnt/logrd/fhem/fhem-%Y-%m.log
attr global statefile /mnt/logrd/fhem/fhem.save
define Logfile FileLog /mnt/logrd/fhem/fhem-%Y-%m.log fakelog
attr autocreate filelog /mnt/logrd/fhem/%NAME-%Y.log
#...
# sowie ggf. weitere modul-logfiles...


Wer die Verzeichnisstruktur übernehmen, sollte sich bewusst sein, dass eine frische Ramdisk leer ist - ergo, das Verzeichnis /mnt/logrd/fhem existiert nicht. Hier hilft ein schnelles

Code Auswählen Erweitern

mkdir /mnt/logrd/fhem
chown fhem:fhem /mnt/logrd/fhem

in der /etc/rc.local


2) Noatime
ext4 und Freunde speichern accesstimes per default. Wer das nicht benötigt, dem lege ich dringend nahe, die option abzuschalten. Hierzu die option "noatime" in der entsprechenden Zeile in der /etc/fstab für das rootfs setzen.

Ein Beispiel:

Code Auswählen Erweitern

PARTUUID=01abcdef-02  /               ext4    defaults,noatime  0       1

[Wernieman]

Nur mal am Rande:
Der Nachteil von Logs im RAM: Bei einem reboot o.Ä. des Systemes gehen diese komplett verloren. manchmal sind fürs debuggen aber gerade diese Logfiles wichtig ...

[Sörn]

Der Nachteil von Logs im RAM: Bei einem reboot o.Ä. des Systemes gehen diese komplett verloren. manchmal sind fürs debuggen aber gerade diese Logfiles wichtig ...

Warum sollte ein Neustart mit FHEM im Zusammenhang stehen?
Mal angenommen der RAM geht zur Neige und FHEM ist Hauptverursacher - dann wird der FHEM Prozess vom OOM killer abgeschossen.

[Wernieman]

Ich hatte nicht nur von FHEM sondern auch von Systemlogs geredet ... bei FHEM-Logs gehen natürlich die Langszeitlogs verloren, wenn  Du bei einem restart diese nicht sicherst (voher)