Hallo!
Da der Schreibzugriff auf die SD-Karte des FHEM Raspi immer mehr zunimmt, will ich die logs auslagern. Möglichkeiten: Ein USB-Stick lokal oder auf ein NAS.
USB-Stick ist auch ein Flash-Medium (Verschleiss), aber billiger als die Festplatten im NAS (müssen ja dann auch 24h am Tag rödeln). Außerdem ist die Frage: was passiert, wenn das NAS mal rebootet und nicht für einen Schreibvorgang zu erreichen ist? Bockt dann FHEM oder stürzt gar ab?
Theoretisch kommt auch eine billige SSD mit SATA-USB-Adapter in Frage...
Wer kann denn aus seiner Erfahrung mit ausgelagerten Logs Geschichten beitragen, die die Entscheidung erleichtern?
Hallo Claudio,
Zitat
Außerdem ist die Frage: was passiert, wenn das NAS mal rebootet und nicht für einen Schreibvorgang zu erreichen ist? Bockt dann FHEM oder stürzt gar ab?
Kommt darauf an welches Logging du benutzt.
Solltest du DbLog im asynchronen Modus benutzen, passiert nichts. d.h. FHEM läuft normal weiter und schreibt die zwischenzeitlich aufgelaufenben Events in die DB wenn die NAS/DB wieder verfügbar ist.
Das ist in meiner Umgebung Standard.
Zitat...aber billiger als die Festplatten im NAS (müssen ja dann auch 24h am Tag rödeln)
In meinem NAS befinden sich Serverplatten (WB red). Die sind für den 24x7 Dauerbetrieb ausgelegt und deswegen ist dieser Betriebsmodus (für solche Platten) auch unkritisch. Tun schon ein paar Jahre ihren Dienst zuverlässig.
Grüße,
Heiko
Ich nutze auch einen USB Stick zum Logging in Dateien. Da wird manchmal das Dateisystem zerschossen und dann stürzt fhem ab.
Danke für die Antworten!
@DS-Starter
WD-red hier auch, aber im 24/ sind die nach 3-4 Jahren hinüber, wenn nicht ständig in Betrieb werden es auch mal 6 Jahre.
Deine Art Logging ist nicht der Standard, oder? Gibt es einen Thread/Wiki zum Thema? :-)
@guhu
Was ist denn "manchmal"? Alle 2 Jahre? Eine Idee, warum das FS leidet? Kenne ich sonst eigentlich nicht...
ZitatWD-red hier auch, aber im 24/ sind die nach 3-4 Jahren hinüber
Kann ich jetzt bei mir nicht bestätigen, aber wenn du diese Erfahrung gemacht hast wäre es wohl ein Thema für die Qualitätssicherng von WD. ;)
ZitatDeine Art Logging ist nicht der Standard, oder? Gibt es einen Thread/Wiki zum Thema? :-)
Also wenn du den asynchronen Modus im DbLog meinst, dann ist er nicht Standard nach dem Define von DbLog. Kann aber leicht mit asynchMode=1 umgestellt werden und wird von sehr vielen genutzt wenn meine Wahrnehmung richtig ist. Das hat historische Gründe, früher gab es diesen Modus nicht.
Hinweise gibt es dazu mit Sicherheit viele, angefangen bei der Commandref ;). Aktuell wären vllt. diese Threads etwas für dich um solche Fragen zu erörten:
https://forum.fhem.de/index.php/topic,65860.0.html
https://forum.fhem.de/index.php/topic,107201.0.html
Grüße,
Heiko
Ich habe in der Vergangenheit viele WD red 2.5" (in Buffalo Linkstations) gehabt. Kann mit der Größe zusammenhängen, auch werden die Platten in den Buffalos gut gebraten.
Ich werde mal abwarten, ob noch mehr Meinungen eintrudeln. Vielleicht probier ich's mit einem 64 GB USB-Stick mit einer 50 GB NTFS Partition. Die Heizung hat in ein paar Tagen schon 16 MB zusammengeloggt. Ich habe einen Thread gesehen, wie man nur "neue" Werte loggen kann, mit dummy und Gedöns. Vielleicht ist das auch noch eine Überlegung wert?
Ja. klar.
Aber auch lokal kann/wird es sich lohnen den asynchMode einzuschalten wenn du das noch nicht kennst. Dadurch kannst du auch zumindest die Anzahl bzw. zeitlichen Intervalle über das Attribut synchInterval optimieren. Vielleicht hilft es.
Bei mir laufen die logs derzeit einfach in Textfiles in /opt/fhem/log. Also müsste ich als erste Maßnahme mal das hier aktivieren:
https://commandref.fhem.de/#DbLog
...da geht's schon los. MariaDB? Oder SQlite? Oder...? Mein hauseigener Nerd ist derzeit nicht zu sprechen. Aber in's Blaue rein, will ich solche Entscheidungen nicht treffen.
Schwierig...
Ich bin selbst nicht unvoreingenommen und würde MariaDB nehmen weil mir diese DB "liegt" und sehr stabil läuft.
Aber sie braucht auf jeden Fall RAM Ressourcen, also nichts für minimalistische Systeme.
Vielleicht mal hier ansprechen:
https://forum.fhem.de/index.php/topic,65860.0.html
LG,
Heiko
Zitat64 GB USB-Stick mit einer 50 GB NTFS
Dein FHEM läuft doch auf einem PI mit Linux? Warum dann unbedingt ntfs?? Willst Du es Dir unbedingt schwer machen??
Besser währen native Fileysteme wie ext3/4 ....
Allerdings bin ich persöhnlich kein Freund von USB-Sticks. Beine persönliche Erfahrung ist eher, das schlechter als SD-Cards ....
Edit:Und Logs reduzieren, d.h. nur as unbedingt notwendig (und fürs Debugging Sinnvoll)
Zitat von: claudio-fhem am 11 Januar 2020, 14:01:46
@guhu
Was ist denn "manchmal"? Alle 2 Jahre? Eine Idee, warum das FS leidet? Kenne ich sonst eigentlich nicht...
Unregelmäßig, derzeit ca. 3x im Jahr. Wahrscheinlich ist der USB-Stick irgendwann mal hinüber.
@guhu
NTFS kennt keine user Rechte und fragmentiert, was für Flash-Speicher eher ein Vorteil sein dürfte ;-)
EXT4 ist auch kein Problem.
Was schreibt denn dein Log so im Monat an GBs, damit du in 3 Monaten einen USB-stick himmelst? :-O
@DSStarter
MariaDB ist halt eine grooooooße Baustelle auf einem Raspi2. SQL light soll (laut einheimischem Nerd, ich haben ihn mit Apfelkuchen aus seinem Stall gelockt...) nur ein advanced Fileformat sein, ohne großen Überbau. Vielleicht erstmal sowas?
ZitatSQL light soll (laut einheimischem Nerd, ich haben ihn mit Apfelkuchen aus seinem Stall gelockt...) nur ein advanced Fileformat sein, ohne großen Überbau. Vielleicht erstmal sowas?
Ja, so ist es. Passt schon. SQLite hat eben wegen seiner Architektur ein paar Eigenheiten. Es verkraftet parallele Schreibprozesse nicht so gut. Aber um mit der DB Materie erstmal etwas warm zu werden ist das schon gut. Außerdem ist es ein sehr weit verbreitetes DB-System und werkelt auch. Bei mir auf Testsystemen wegen der Modulentwicklung und rennt ...
SQLite sollte man nach meinen Erfahrungen aber nicht auf gemounteten Netzwerklaufwerken anlegen. Dabei kam es häufig zu Korruptionen.
Apropos Kurruptionen ... im DbRep-Modul gibt es mit repairSQLite eine Reparaturmöglichkeit wenn man doch mal eine SQLite Korruption hat (Erfolg nicht garantiert)
EDIT: Ebenfalls im DbRep gibt es Routinen zum Backup/Restore der DB im laufenden Betrieb. Nicht ganz unwichtig ;)
Näheres im Wiki: https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#Backup.2FRestore_einer_SQLite_Datenbank_im_laufenden_Betrieb
Grüße,
Heiko
Im Zweifelsfall ist mir lieber, ich mache alle 6 Monate eine frische SD-Karte (oder USB-Stick), als mir eine Instabilität anzulachen. Ich bin manchmal recht weitläufig unterwegs und kann nicht (manuell) auf das System zugreifen, nur via ssh.
"Unbedingte Voraussetzung für Zuverlässigkeit ist absolute Unkompliziertheit"
(könnte von mir sein, isses aber nicht...)
...mal weiter drüber nachdenken...
Zitat von: claudio-fhem am 11 Januar 2020, 16:18:44
NTFS kennt keine user Rechte und fragmentiert, was für Flash-Speicher eher ein Vorteil sein dürfte ;-)
Bist Du Dir da sooo sicher?
https://de.wikipedia.org/wiki/NTFS
Das ich USB-Sticks nicht so mag liegt bei mir nicht am PI, sondern ich hatte berufsmäßig mal einen Server mit so etwas, zum Glück gespiegelt. Mindestens 1mal im Jahr mussten wir tauschen (lassen). Hatte es hier im Forum schon mal erwähnt.....
Speziell beim PI kommt noch hinzu, das USB dort aus Hardwaregründen nicht so ... sicher (sicher im Sinne von stabil, zuverlässig etc.). Linux mag es nicht, wenn ein Datenträger ohne unmounten entfernt wird .... in Summe (nach meiner Meinung) also unsicher als reine SDCard.
Habe übrigens (persönlich) auf keinen PI die SDCard zerschossen, obwohl ich viele PIs verwende (persönlich zum Basteln/Testen und beruflich als Monitoringsysteme). Allerdings läuft hier FHEM auf einem ZOTAC
@Werniemann:
NTFS: fragmentieren, ja sicher, was meinst du sonst? :-)
Ich habe mal "zum Spaß" eine openSUSE ca. 13 Monate auf einem USB-Stick als Bootmedium in einem Notebook laufen lassen, täglich lief derFirefox drauf, sonst nichts. Nach der Zeit ging dann der Stick in read-only und es war vorbei.
Mit normalem Betrieb (Raspis mit Raspbian) habe ich in 5-6 Jahren noch keine SD-Karte im Betrieb verloren, tausche die Dinger aber auch nach ca. 1-2 Jahren durch (frisches Betriebssystem, Kosten: 5-8 Euro für eine SanDisk Ultra 16GB). Aber bei diesen Installationen loggt auch nichts ständig auf die Karte (so wie jetzt das KM200 Modul der Heizungsanlage). Ich bin unsicher, wie lange die SD-Karte den Dauerbeschuss aushält...
Ich bezog mich auf "user Rechte" und nicht "fragmentiert" .. habe zu viel Zitiert ...
Also wenn ich einen NTFS-stick in Linux mounte, kennt der keine Probleme mit Linux-Userrechten. Bei EXT4 kann es immer etwas murksig sein, bis alle Verzeichnisse vom richtigen User erstellt, oder von Hinz und Kunz les-/schreibbar sind. Meine Erfahrung. Aber ich bin kein Experte...
NTFS ist ein Dateisystem für Windows, d.h. für Linux ist so etwas IMMER Problembehaftet.
oder von Hinz und Kunz les-/schreibbar sind
Lies Dich bitte mal bezüglich user rechten durch .. ist übrigens (wenn Du auch ACL betrachtet) wie bei Windows ;o)
Also ist ein Wissen über User/Gruppen-Rechte niemals verkehrt ....
Zitat von: claudio-fhem am 11 Januar 2020, 14:01:46
WD-red hier auch, aber im 24/ sind die nach 3-4 Jahren hinüber, wenn nicht ständig in Betrieb werden es auch mal 6 Jahre.
In wie weit ist das relevant? Wenn man eine NAS "ernsthaft" betreibt, fährt man die HDD als RAID und tauscht defekte Platten im "hot swap" aus. Davon kriegt FHEM überhaupt nichts mit, denn das RAID läuft auch mit einer defekten Platte weiter.
Bei mir loggt FHEM schon Jahre direkt auf die NAS, auch Backups laufen nur auf die NAS, so dass ich quasi nur Lesezugriffe auf der SD Karte habe.
Viele Grüße
Jörn
ZitatWenn man eine NAS "ernsthaft" betreibt, fährt man die HDD als RAID und tauscht defekte Platten im "hot swap" aus. Davon kriegt FHEM überhaupt nichts mit, denn das RAID läuft auch mit einer defekten Platte weiter.
Genauso betreibe ich das NAS Plattensystem bei mir.
Jooo, ganz entspannt, alls RAID1 hier! Bei der Lebensdauer geht es nur um die Kosten für neue Platten. Klar, dass das NAS nicht einfach durch eine kaputte Platte verschwindet. Aber manchmal muss man ja auch ein NAS mal booten (Kernelupdate) oder es fällt mal der Strom aus und die USV fährt runter oder oder oder.
Auf jeden Fall will ich nicht, dass das NAS die FHEM Installation abschiessen kann und da ich bisher zu wenig von dem Zusammenspiel FHEM und Schreibort für Logs verstehe, will ich vor einer Änderung wissen, wie man's richtig macht... :-)