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

[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