Autor Thema: [Gelöst] DbRep mit dumpCompress: erzeugte dump Datei wird nicht komprimiert  (Gelesen 494 mal)

Offline alkazaa

  • New Member
  • *
  • Beiträge: 49
Hallo!
Ich möchte für meine dbLog Datenbank backups mit Hilfe des Moduls dbRep erstellen. Mit etwas Mühe und viel Wiki- und Forums-Wühlerei habe ich es auch im Prinzip hingekriegt: mit einem serverSide dump erzeuge ich eine .csv Datei mit den Inhalten der history-Tabelle auf dem gleichen remote server, auf dem auch die Datenbank läuft (eine Mysql DB mit MariaDB 10 Server auf einer Synology NAS)

Was nicht funktioniert, ist die anschließende Kompression der Datei. Hier das Protokoll der log Datei (mit verbose 3):
2020.11.04 16:23:12 3: DbRep logdbDump - ################################################################
2020.11.04 16:23:12 3: DbRep logdbDump - ###             New database serverSide dump                 ###
2020.11.04 16:23:12 3: DbRep logdbDump - ################################################################
2020.11.04 16:23:12 3: DbRep logdbDump - execute command before dump: 'set logdb reopen 3600'
2020.11.04 16:23:12 2: DbLog logdb: Connection closed until 17:23:12 (3600 seconds).
2020.11.04 16:23:12 3: DbRep logdbDump - Searching for tables inside database fhem....
2020.11.04 16:23:12 3: DbRep logdbDump - Size of database fhem before optimize (MB): 191.50
2020.11.04 16:23:12 3: DbRep logdbDump - Optimizing tables
2020.11.04 16:23:12 3: DbRep logdbDump - Optimizing table `current` (INNODB). It will take a while.
2020.11.04 16:23:13 3: DbRep logdbDump - Table 1 `current` optimized successfully.
2020.11.04 16:23:13 3: DbRep logdbDump - Optimizing table `history` (INNODB). It will take a while.
2020.11.04 16:24:04 3: DbRep logdbDump - Table 2 `history` optimized successfully.
2020.11.04 16:24:04 3: DbRep logdbDump - 2 tables have been optimized.
2020.11.04 16:24:04 3: DbRep logdbDump - Size of database fhem after optimize (MB): 191.50
2020.11.04 16:24:04 3: DbRep logdbDump - Starting dump of database 'fhem', table 'history'
2020.11.04 16:24:14 3: DbRep logdbDump - compress file ./log/fhem_history_2020_11_04_16_24.csv
2020.11.04 16:24:14 2: DbRep logdbDump - gzip of ./log/fhem_history_2020_11_04_16_24.csv failed: input file './log/fhem_history_2020_11_04_16_24.csv' does not exist
2020.11.04 16:24:14 3: DbRep logdbDump - Number of exported datasets: 1011144
2020.11.04 16:24:14 3: DbRep logdbDump - Finished backup of database fhem - total time used (hh:mm:ss): 00:01:01
2020.11.04 16:24:14 3: DbLog logdb: Reopen requested.
2020.11.04 16:24:14 3: DbLog logdb - Creating Push-Handle to database mysql:database=fhem;host=schlossnas;port=3307 with user fhemuser
2020.11.04 16:24:14 3: DbLog logdb - Push-Handle to db mysql:database=fhem;host=schlossnas;port=3307 created
2020.11.04 16:24:14 3: DbLog logdb - UTF8 support enabled
2020.11.04 16:24:14 2: DbRep logdbDump - command message after dump: "Reopen executed."
2020.11.04 16:24:14 3: DbRep logdbDump - Database dump finished successfully
Hier das listing meiner dbRep-Instanz:
Internals:
   DATABASE   fhem
   DEF        logdb
   FUUID      5fa22fc3-f33f-a50b-746c-5f2fea88b8fd5ddd
   FVERSION   93_DbRep.pm:v8.40.8-s22817/2020-09-21
   LASTCMD    dumpMySQL serverSide
   MODEL      Client
   NAME       logdbDump
   NOTIFYDEV  global,logdbDump
   NR         109
   NTFY_ORDER 50-logdbDump
   ROLE       Client
   STATE      Warning - dump finished, but command message after dump appeared
   TYPE       DbRep
   UTF8       1
   HELPER:
     DBLOGDEVICE logdb
     GRANTS     SELECT,INSERT,DELETE,CREATE ROUTINE,ALTER,UPDATE,USAGE,EXECUTE,CREATE VIEW,CREATE,DROP,CREATE TEMPORARY TABLES,ALTER ROUTINE,INDEX,SHOW VIEW,TRIGGER,EVENT
     IDRETRIES  2
     MINTS      2019-10-08 09:03:13
     PACKAGE    main
     SQLHIST   
     VERSION    8.40.8
     DBREPCOL:
       COLSET     1
       DEVICE     64
       EVENT      512
       READING    64
       TYPE       64
       UNIT       32
       VALUE      128
   OLDREADINGS:
   READINGS:
     2020-11-04 16:24:14   DumpFileCreated /volume1/@database/mariadb10/fhem/dbRep_dumps/./log/fhem_history_2020_11_04_16_24.csv
     2020-11-04 16:24:14   DumpRowsCurrent n.a.
     2020-11-04 16:24:14   DumpRowsHistory 1011144
     2020-11-04 16:24:14   afterdump_message Reopen executed.
     2020-11-04 16:24:14   background_processing_time 61.6026
     2020-11-04 16:24:14   state           Warning - dump finished, but command message after dump appeared
Attributes:
   devStateIcon connected:10px-kreis-gelb .*disconnect:10px-kreis-rot .*done:10px-kreis-gruen .*Dump.*is.*running.*:remotecontrol/black_btn_PLAYgreen Database.*backup.*finished.*:remotecontrol/black_btn_GREEN tn_GREEN error.*:remotecontrol/black_btn_RED
   dumpCompress 1
   dumpDirRemote /volume1/@database/mariadb10/fhem/dbRep_dumps
   dumpFilesKeep 1
   event-on-update-reading state
   executeAfterProc set logdb reopen
   executeBeforeProc set logdb reopen 3600
   fastStart  1
   optimizeTablesBeforeDump 1
   room       Logging

Die .csv Datei wird, wie schon gesagt, im Verzeichnis /volume1/@database/mariadb10/fhem/dbRep_dumps erzeugt. Das gzip erwartet sie aber anscheinend in ./log/fhem_history_2020_11_04_16_24.csv

Was mache ich (oder was läuft) hier falsch?

Danke im Voraus!

-Franz
« Letzte Änderung: 04 November 2020, 22:09:19 von alkazaa »

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7485
Hallo Franz,

du machst ein serverSide Backup, d.h. das Dump-File entsteht auf dem remoten MariaDB Server (Synology nehme ich an).
Das bedeutet auch, dass der FHEM Prozess keinen direkten Zugriff auf das Zielverzeichnis hat um eine Komprimierung oder auch Versionsverwaltung durchzuführen.

Man muß das remote Verzeichnis am FHEM Server mounten und dem DbRep Device mit dem Attribut "dumpDirLocal" bekannt machen.

Das Verfahren ist in der Commandref und auch im Wiki beschrieben:
https://wiki.fhem.de/wiki/DbRep_-_Reporting_und_Management_von_DbLog-Datenbankinhalten#serverSide_Backup_Option

Speziell der Abschnitt c) weißt darauf hin:

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. Gleiches gilt wenn der FTP-Transfer nach dem Dump genutzt werden soll (Attribut "ftpUse" bzw. "ftpUseSSL").

Im Beispiel läuft der MySQL-Server auf einer Synology Diskstation und die Dump-Files werden dort im Verzeichnis

      /volume1/ApplicationBackup/dumps_FHEM

angelegt. Dieses Verzeichnis wird auf dem FHEM-Server als Verzeichnis "/sds1/backup/dumps_FHEM" gemountet. Dazu wird ein Eintrag in /etc/fstab erstellt:

     sds1.<fqdn>:/volume1/ApplicationBackup /sds1/backup nfs auto,defaults,tcp,intr 0 0

In diesem Verzeichnis existiert das Directory "dumps_FHEM", in dem die Backup-Files gespeichert werden sollen. Das Attribut wird entsprechend gesetzt auf:

     attr Rep.fhemtest.Dump.ServerSide dumpDirLocal /sds1/backup/dumps_FHEM


Hinweis:
Läuft der MySQL-Server mit FHEM lokal auf dem gleichen Server, zeigen die Attribute dumpDirRemote und dumpDirLocal auf das identische Verzeichnis. Trotzdem sind beide Attribute zu definieren.

Das hast du wahrscheinlich übersehen durchzuführen.

Grüße,
Heiko
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

Offline alkazaa

  • New Member
  • *
  • Beiträge: 49
Hallo Heiko,
danke für die schnelle Antwort.
Den passus hatte ich in der Tat übersehen. Ich dachte naiverweise, dass dumpDirLocal nicht relevant war bei einem serverSide backup auf einem remote System (in der Tat ein Syno).
Ich werd's morgen testen.

Beste Grüße,
Franz

Offline alkazaa

  • New Member
  • *
  • Beiträge: 49
Sorry,
jetzt muss ich doch noch mal nachfragen: ich kriegs nicht hin, den <fqdn> bei
Zitat
sds1.<fqdn>:/volume1/ApplicationBackup /sds1/backup nfs auto,defaults,tcp,intr 0 0
korrekt anzugeben.

Meine Konfiguration: FHEM läuft auf einem raspi (unter dem user 'fhem', vermute ich), und ich möchte als Ziel für den mount das Laufwerk /volume1/homes/fhem/backups auf einem Synology NAS einrichten, das unter 192.168.188.xxx im lokalen Netz erreichbar ist. Auf dem Nas habe ich dazu vorher den user 'fhem' eingerichtet. Als passwort für user 'fhem' habe ich das gleiche gewählt, mit dem ich auch per SSH auf den raspi als 'fhem' zugreife.

Klappt aber so nicht...

Wo hakt mein Verständnis?

-Franz

Offline DS_Starter

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7485
Hallo Franz,

das für steht full qualified domain name, also z.B. so:

sds1.myds.me:/volume1/ApplicationBackup /sds1/backup nfs auto,defaults,tcp,intr 0 0

Der Name "sds1.myds.me" muß natürlich deiner DS entsprechen, wie sie im Netz per Namensauflösung erreichbar ist !
Wenn du mit einer IP arbeiten möchtest, dann so:

192.168.188.xxx:/volume1/ApplicationBackup /sds1/backup nfs auto,defaults,tcp,intr 0 0

Geht genauso.

Grüße,
Heiko
« Letzte Änderung: 08 November 2020, 20:55:49 von DS_Starter »
ESXi 6.5 @NUC6i5SYH mit FHEM auf Debian 10, DbLog/DbRep mit MariaDB auf VM
Maintainer: SSCam, SSChatBot, SSCal, SSFile, DbLog/DbRep, Log2Syslog, SolarForecast,Watches, Dashboard
Kaffeekasse: https://www.paypal.me/HMaaz
Contrib: https://svn.fhem.de/trac/browser/trunk/fhem/contrib/DS_Starter

 

decade-submarginal