[Gelöst] Seit Auslagerung DBlog auf anderen Rechner attr dumpFilesKeep ohne Fkt.

[Rewe2000]

Hallo,

bin aktuell dabei mein Fhem und meine MariaDB, welche bisher gemeinsam auf einem Raspi4 gelaufen sind zu trennen. Auf meinen Testsystemen läuft alles so weit ganz gut, lediglich ein Fehler ist mir bisher aufgefallen.
Ich kann im DBRep Device das attr dumpFilesKeep setzen, es löscht jedoch nicht die überzähligen Dumpfiles am SQL-Server. Die Dumpfiles werden jedoch problemlos mit "dumpMySQL serverSide" geschrieben , halt nur nicht automatisch wieder entfernt.

Mein Fhem-Server und mein SQL-Server läuft jeweils auf einem Raspi4 mit aktuellem Fhem und Linux.
Ich will die dumpfiles eigentlich im Backup Verzeichnis am SQL-Server speichern und nicht im Verzeichnis am Fhem-Server. Das klappt ja auch bei der Erstellung prima, nur das löschen über "dumpFilesKeep" läuft irgendwie ins leere, ohne eine erkennbare Meldung in der Fhem Logdatei unter verbose 4.

Sicherlich ist dies irgendwie ein Rechteproblem unter Linux, wenn mir da von euch jemand einen Tipp geben könnte.


Ich hänge mal das list von meinem Reportdevice mit an, solltet Ihr noch irgendweche Infos benötigen, bitte kurz Bescheid geben, damit ich diese noch liefern kann.

Code Auswählen Erweitern

Internals:
   CFGFN     
   DATABASE   fhem
   DEF        DBLogging
   FUUID      63a850e6-f33f-cfbe-71b9-5a1c1da943c35fb5
   FVERSION   93_DbRep.pm:v8.50.8-s26882/2022-12-21
   LASTCMD    dumpMySQL serverSide
   MODEL      Client
   NAME       DBReport_Datenbanksicherung
   NOTIFYDEV  global,DBReport_Datenbanksicherung
   NR         87
   NTFY_ORDER 50-DBReport_Datenbanksicherung
   ROLE       Client
   STATE      WARNING - dump finished, but message after command appeared
   TYPE       DbRep
   UTF8       1
   eventCount 51
   HELPER:
     DBLOGDEVICE DBLogging
     IDRETRIES  3
     PACKAGE    main
     VERSION    8.50.8
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1671975142.58032
           VALUE      initialized
   OLDREADINGS:
   READINGS:
     2022-12-25 16:56:58   DumpFileCreated /opt/fhem/backup/fhem_history_2022_12_25_16_56.csv
     2022-12-25 16:56:58   DumpFileCreatedSize
     2022-12-25 16:56:58   DumpFilesDeleted
     2022-12-25 16:56:58   DumpRowsCurrent n.a.
     2022-12-25 16:56:58   DumpRowsHistory 9563
     2022-12-25 16:56:58   after_dump_message Reopen executed.
     2022-12-25 16:56:58   background_processing_time 0.1361
     2022-12-25 16:56:58   state           WARNING - dump finished, but message after command appeared
Attributes:
   DbLogExclude .*
   comment    Mit dem Befehl "dumpMySQL serverSide" kann die ordnungsgemäße Datenbanksicherung als CSV-Datei getestet werden.
   devStateIcon connected:Restart .*disconnect:message_attention .*done:StandBy
   dumpDirLocal /opt/fhem/backup
   dumpDirRemote /opt/fhem/backup
   dumpFilesKeep 6
   executeAfterProc set DBLogging reopen
   executeBeforeProc set DBLogging reopen 3600
   fastStart  1
   group      Hardware
   icon       system_backup
   room       Logging
   showproctime 1

Die Rechte im Backup-Verzeichnis meines SQL-Servers sehen aktuell so aus (könnte natürlich auch falsch sein):

Code Auswählen Erweitern

reinhard@SQL-Bullseye-SSD:/opt/fhem/backup $ ls -lh
insgesamt 12M
-rw-rw-rw- 1 fhem  dialout 405K 24. Dez 22:14 fhem_history_2022_12_24_13_41.csv
-rw-rw-rw- 1 fhem  dialout 9,1K 24. Dez 22:10 fhem_history_2022_12_24_22_10.csv
-rw-rw-rw- 1 fhem  dialout 479K 25. Dez 04:05 fhem_history_2022_12_25_04_05.csv
-rw-rw-rw- 1 fhem  dialout 734K 25. Dez 16:02 fhem_history_2022_12_25_16_02.csv
-rw-rw-rw- 1 fhem  dialout 735K 25. Dez 16:05 fhem_history_2022_12_25_16_05.csv
-rw-rw-rw- 1 fhem  dialout 736K 25. Dez 16:06 fhem_history_2022_12_25_16_06.csv
-rw-rw-rw- 1 fhem  dialout 736K 25. Dez 16:07 fhem_history_2022_12_25_16_07.csv
-rw-rw-rw- 1 fhem  dialout 736K 25. Dez 16:08 fhem_history_2022_12_25_16_08.csv
-rw-rw-rw- 1 fhem  dialout 737K 25. Dez 16:09 fhem_history_2022_12_25_16_09.csv
-rw-rw-rw- 1 fhem  dialout 739K 25. Dez 16:12 fhem_history_2022_12_25_16_12.csv
-rw-r--r-- 1 mysql mysql   740K 25. Dez 16:16 fhem_history_2022_12_25_16_16.csv
-rw-r--r-- 1 mysql mysql   743K 25. Dez 16:21 fhem_history_2022_12_25_16_21.csv
-rw-r--r-- 1 mysql mysql   744K 25. Dez 16:23 fhem_history_2022_12_25_16_23.csv
-rw-r--r-- 1 mysql mysql   750K 25. Dez 16:32 fhem_history_2022_12_25_16_32.csv
-rw-r--r-- 1 mysql mysql   756K 25. Dez 16:41 fhem_history_2022_12_25_16_41.csv
-rw-r--r-- 1 mysql mysql   765K 25. Dez 16:54 fhem_history_2022_12_25_16_54.csv
-rw-r--r-- 1 mysql mysql   767K 25. Dez 16:56 fhem_history_2022_12_25_16_56.csv


Schöne Feiertage
Gruß Reinhard

[DS_Starter]

Hallo Reinhard,

vermutlich liegt es an dem Attr "dumpDirLocal=/opt/fhem/backup".
Zitat aus ComRef:

...
Soll die interne Versionsverwaltung und die Dumpfilekompression des Moduls genutzt, sowie die Größe des erzeugten Dumpfiles ausgegeben werden, ist das Verzeichnis "dumpDirRemote" des MySQL-Servers auf dem Client zu mounten und im Attribut "dumpDirLocal" dem DbRep-Device bekannt zu machen.

Das bedeutet, du müstest das entfernte Verzeichnis "/opt/fhem/backup" lokal mounten. Den lokalen Mountpoint gibst du dann
im Attr dumpDirLocal an.
Wenn z.B. der lokalen Mount "/Backups" wäre, dann:

dumpDirLocal=/Backups

DbRep weiß dadurch wo es die ganzen Backup lokal findet um zu agieren. Physikalisch liegen sie natürlich weiterhin remote bei
Ausführung von dumpMySQL serverSide.

LG,
Heiko

[Rewe2000]

Hallo Heiko,

vielen Dank für die schnelle Antwort.

Das habe ich befürchtet!
Hast du oder ein anderer User eventuell eine Anleitung oder Quelle (wenn möglich in Deutsch) wo ich Step by Step nachlesen kann wie ich das Laufwerk unter Debian mounten kann?

Ich habe schon einige Stunden ohne Erfolg damit verbracht, aber irgendwie nichts zielführendes und vor allem (für mich) verständliches gefunden.
Liegt aber vermutlich nicht an den Quellen sondern an mir

Gruß Reinhard

[DS_Starter]

Ich habe die Schritte im Wiki:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#serverSide_Backup_Option

Abschnitt dumpDirLocal beschrieben.
Ich hoffe ich habe nichts vergessen bzw. alles soweit richtig beschrieben. Ich nutze Synology als Fileserver. Da läuft manches anders, d.h. über grafische GUI.

Es gibt hier auch ein Server-Forum. Da bekommst du sicherlich noch fundiertere Hilfe für solche Debian-Fragen.

[Rewe2000]

Hallo Heiko,

vielen Dank für deine Hilfe.

Deine Anleitung hat mir sehr geholfen, jetzt klappt auch das mounten und somit werden auch die überzähligen Backup-Files durch DBrep wieder, gemäß attr dumpFilesKeep gelöscht.
Ich musste für meinen Raspi4 noch das Paket "sudo apt-get install nfs-kernel-server" nachinstallieren, ohne dieses gab es keine Datei  "/etc/exports". Könnte sein, dass dieses Paket auf einem NAS-Laufwerk schon standardmäßig vorhanden ist.

Zumindest läuft es jetzt problemlos bei mir.
Ich werde noch einen Tag beobachten, alles sauber dokumentieren und dann mein laufendes System umziehen.

Nochmals danke und einige ruhige Tage.
Gruß Reinhard

[DS_Starter]

Hallo Reinhard,

freut mich.
Ja, auf Synology ist manches anders.

Ich ergänze im Wiki noch die Installation von nfs-kernel-server.
Dann passt das und ist komplett.

LG

[Wernieman]

Sichertheitsmäßig .. wie hast Du in export konfiguriert? Darf nur Dein FHEM-Server oder "alle" im Netz?

[Rewe2000]

Hallo Wernieman,

mein Eintrag in /etc/exports sieht wie folgt aus:

Code Auswählen Erweitern

/opt/fhem/backup 192.168.50.33/24(rw,sync,no_subtree_check)

Ich dachte es reicht aus, den Zugriff nur von einer IP zu erlauben.
Als Anfänger bin ich davon ausgegangen, dass 192.168.50.0/24 den gesamten IP Bereich von 192.168.50.1 bis 192.168.50.255 frei gibt.

Ich stelle es jedoch gerne um, sollte meine "Freigabe" fehlerhaft oder unsicher sein, ich bin da dankbar für jeden Hinweis.

Hintergrund:
Da mein Raspi3 mit Fhem und MariaDB immer nach einer längeren Laufzeit abgeschmiert ist, nachdem ich größere SVG Plots geöffnet hatte, habe ich auf Raspi4 4GB umgestellt, da hatte ich aber das gleiche Problem nur nach etwas mehr Laufzeit. Deshalb bin ich deinem Rat (https://forum.fhem.de/index.php/topic,125637.msg1203186.html#msg1203186) gefolgt und habe MariaDB auf einen anderen Raspi ausgelagert, ein NAS deswegen anzuschaffen wäre für meinen Anwendungsfall mit Kanonen auf Spatzen zu schießen.

Erst durch die Auftrennung von Fhem und SQL-Datenbank gab und gibt es für mich einige Hürden mit Userrechten in Linux, das gestehe ich ein, da habe ich noch gewaltig Nachhohlbedarf. Ich vermute, da wirst du noch auf einige Beiträge von mir stoßen, wo ich nur auf euere Geduld mit Anfängern hoffen kann.

Gruß Reinhard

[Wernieman]

- Wenn dort nur ein Server zugreifen soll, warum schränkst Du es dann nicht nur auf eine IP ein?
- wirklich sync? Würde persönlich async nehmen. Oder brauchst Du wirklich "Echtzeit-Syncronisation"?
- würde einbauen: root_squash .. oder greifst DU mit einem root-Akkount zu?

Gute Doku dazu:
https://wiki.ubuntuusers.de/NFS/

[Rewe2000]

Hallo Wernieman,

vielen Dank für deine hilfreichen Tipps.
Ich habe die von dir empfohlene Doku gelesen und meinen Eintrag in der /etc/exports nun wie folgt umgestellt.

Code Auswählen Erweitern

/opt/fhem/backup 192.168.50.33(rw,root_squash,async,no_subtree_check)

Ich denke damit sollte es jetzt passen, das mounten funktioniert prima.

Ich würde fast meinen es wäre nicht verkehrt wenn Heiko dies als "exports" Eintrag (für einen Raspi) in die DBRep Wiki mit aufnehmen könnte, da werde ich sicherlich nicht der einzige und letzte Anfänger sein, welcher diese "Fehler" begeht.

Gruß Reinhard

[DS_Starter]

Moin,

Ich würde fast meinen es wäre nicht verkehrt wenn Heiko dies als "exports" Eintrag (für einen Raspi) in die DBRep Wiki mit aufnehmen könnte, da werde ich sicherlich nicht der einzige und letzte Anfänger sein, welcher diese "Fehler" begeht.

Na klar, mache ich.

@Werner, könnte das "async" evtl. Probleme bereiten wenn der Dump durch ist (aber noch keine Bestätigung vom Filesystem gekommen ist) und Perl beginnt schon mit gzip die Kompression des Files ?

[Wernieman]

im Normalfall eigentlich nicht ... eher wenn der Client beim schreiben abstürzt und deshalb der "cache" nicht weggeschrieben werden kann ....

[DS_Starter]

Ok, danke