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.
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):
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
Hallo Reinhard,
vermutlich liegt es an dem Attr "dumpDirLocal=/opt/fhem/backup".
Zitat aus ComRef:
Zitat
...
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
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
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.
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
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
Sichertheitsmäßig .. wie hast Du in export konfiguriert? Darf nur Dein FHEM-Server oder "alle" im Netz?
Hallo Wernieman,
mein Eintrag in /etc/exports sieht wie folgt aus:
/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 (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
- 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/
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.
/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
Moin,
Zitat
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 ?
im Normalfall eigentlich nicht ... eher wenn der Client beim schreiben abstürzt und deshalb der "cache" nicht weggeschrieben werden kann ....
Ok, danke