DBRep-MySQL Backup produziert bei mir viele Fhem Hänger

[Rewe2000]

Hallo,

nachdem meine DBlog Datenbank, auf dem Raspi3 in der letzten Zeit gewachsen ist, bemerke ich beim nächtlichen Backup sporadisch viele Fhem Hänger, während das Backup läuft. Eigentlich sollten doch, wenn ich keine Einstellungsfehler gemacht habe, die Datenbankzugriffe nichtblockierend ausgeführt werden.

Kann ich da noch etwas optimieren, oder muss ich mich ggf. mit einer anderen Hardware, bei der Datenbankgröße beschäftigen?
Oder könnten die Hänger doch von etwas Anderem verursacht werden, während das Backup läuft.
DBLog ConfigCheck jedenfalls erkennt bei mir keine Mängel.

Datenbankgröße derzeit ca. 350 MB, 1,9 Mio. Datensätze

Auszug aus dem Log:

Code Auswählen Erweitern

2020.05.03 03:11:36 1: Perfmon: possible freeze starting at 03:11:33, delay is 3.505
2020.05.03 03:13:07 1: Perfmon: possible freeze starting at 03:13:03, delay is 4.798
2020.05.03 03:14:00 1: Perfmon: possible freeze starting at 03:13:52, delay is 8.494
2020.05.03 03:14:43 1: Perfmon: possible freeze starting at 03:14:37, delay is 6.977
2020.05.03 03:15:00 1: Perfmon: possible freeze starting at 03:14:57, delay is 3.333
2020.05.03 03:15:43 1: Perfmon: possible freeze starting at 03:15:39, delay is 4.825
2020.05.03 03:15:43 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 DC 00 00 00 06] 00 01 42 DC 00 08
2020.05.03 03:16:00 1: Perfmon: possible freeze starting at 03:15:48, delay is 12.58
2020.05.03 03:16:07 1: Perfmon: possible freeze starting at 03:16:01, delay is 6.563
2020.05.03 03:16:10 1: Perfmon: possible freeze starting at 03:16:08, delay is 2.618
2020.05.03 03:16:44 1: Perfmon: possible freeze starting at 03:16:43, delay is 1.408
2020.05.03 03:17:31 1: Perfmon: possible freeze starting at 03:17:29, delay is 2.54
2020.05.03 03:17:31 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 CC 00 00 00 06] 00 01 42 CC 00 08
2020.05.03 03:18:00 1: Perfmon: possible freeze starting at 03:17:59, delay is 1.303
2020.05.03 03:18:18 1: Perfmon: possible freeze starting at 03:18:16, delay is 2.765
2020.05.03 03:18:22 1: Perfmon: possible freeze starting at 03:18:19, delay is 3.105
2020.05.03 03:19:05 1: Perfmon: possible freeze starting at 03:19:02, delay is 3.183
2020.05.03 03:19:19 1: Perfmon: possible freeze starting at 03:19:17, delay is 2.298
2020.05.03 03:20:29 1: Perfmon: possible freeze starting at 03:20:25, delay is 4.017
2020.05.03 03:22:17 1: Perfmon: possible freeze starting at 03:22:07, delay is 10.82
2020.05.03 03:22:31 1: Perfmon: possible freeze starting at 03:22:18, delay is 13.364


Mein at Aufruf von DBRep:

Code Auswählen Erweitern

defmod at_DBLog_Backup at *03:05:55 set DBReport dumpMySQL clientSide
attr at_DBLog_Backup DbLogExclude .*
attr at_DBLog_Backup comment Dieses at startet täglich in der Nacht ein Backup der SQL Datenbank (Dump).
attr at_DBLog_Backup group Hardware
attr at_DBLog_Backup icon system_backup
attr at_DBLog_Backup room Logging


Das DBRep Device:

Code Auswählen Erweitern

defmod DBReport DbRep DBLogging
attr DBReport DbLogExclude .*
attr DBReport DbLogInclude INFO_history.data_index_length_MB.*,INFO_history.number_of_rows.*
attr DBReport comment Dies ist das aktuelle Reportdevice der aktuellen DbLog SQL-Datenbank, mit diesem Devise können Datenbankbefehle und Reports ausgeführt werden.
attr DBReport devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
attr DBReport dumpDirLocal /opt/fhem/backup
attr DBReport dumpFilesKeep 8
attr DBReport group Hardware
attr DBReport icon system_backup
attr DBReport optimizeTablesBeforeDump 1
attr DBReport room Logging
attr DBReport showTableInfo %history%,%current%
attr DBReport showproctime 1
attr DBReport timeDiffToNow d:32
attr DBReport timeOlderThan d:30
attr DBReport verbose 2

DBlog selbst:

Code Auswählen Erweitern

defmod DBLogging DbLog /opt/fhem/contrib/dblog/db.conf .*:.*
attr DBLogging DbLogExclude .*
attr DBLogging DbLogSelectionMode Exclude/Include
attr DBLogging DbLogType History
attr DBLogging asyncMode 1
attr DBLogging bulkInsert 1
attr DBLogging comment Dieses ist das aktuelle Logdevice, welches die Daten in die SQL-Datenbank schreibt.
attr DBLogging devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
attr DBLogging group Hardware
attr DBLogging icon system_backup
attr DBLogging room Logging
attr DBLogging verbose 2

Die vielen Hänger treten nicht täglich auf, sondern ich beobachte diese nur an einigen Tagen pro Monat.
Über Hinweise und Anregungen wäre ich dankbar.

Gruß Reinhard

[DS_Starter]

Hallo Reinhard,

das verwendete  dumpMySQL clientSide ist relativ speicherintentensiv.
Es könnte sein, dass unter ungünstigen Umständen bei dir der Speicher aufgebraucht ist und die Maschine beginnt zu swappen was zu den Hängern führen könnte.
Du kannst mit den Attributen "dumpMemlimit" und "dumpSpeed" das Speicher- und auch Laufzeitverhalten beeinflussen.
Musst du versuchen damit zu experimenrieren.

Andere Varainte wäre auf dumpMySQL serverSide umzustellen. Das Verfahren nutzt eine andere Technologie und braucht weniger Speicher.
Meistens reicht dieses Backup aus, wir braucehn üblicherweise die SQLs nicht um die Tabellen zu erstellen. Das können wir vorher manuell machen im Bedarfsfall.

Weitere Variante wäre zu schauen was zu der Zeit noch läuft und den Speicher in Summe zu sehr auslastet.
Die Datenbankprozesse an sich sind non-blocking.

Grüße,
Heiko

[Rewe2000]

Hallo Heiko,

vielen Dank für die schnelle Antwort.
Da bin ich schon beruhigt, ich hatte schon befürchtet, ich hätte da in den Konfiguration etwas übersehen.
Das was du vermutest wird es wahrscheinlich sein, ich hatte mal verbose 4 eingestellt, da war aber auch nicht viel mehr zu erkennen. Swappen ist ja für Linux und Fhem kein Fehler.

So wie ich die Commandref interpretiere sind als Standard für dumpMemlimit 100000 Zeichen und für dumpSpeed 10000 Zeilen voreingestellt. Mit welchen Einstellungen würdest du anfangen zu experimentieren?

Wenn ich nun jeweils die Werte halbiere, wirkt sich dies wahrscheinlich auf die Ausführungszeit des Backups aus, das wäre aber nicht so tragisch, wenn dadurch die Hänger verschwinden. Ich beginne mal mit dumpSpeed 5000 und beobachte auf Hänger.

Zum Thema Umstellen auf dumpMySQL serverSide:
Dies würde ich eventuell angehen, wenn mit den beiden Attributen keine Verbesserung erreicht wird.

Gruß Reinhard

[DS_Starter]

Ich würde dumpMemlimit erstmal auf 10000 reduzieren. Halbieren wäre vermutlich zuviel des Guten.
Die Attribute haben Abhängigkeit voneinander. Aber das wird vom Modul geprüft.

LG,
Heiko

[Rewe2000]

Hallo Heiko,

mein Problem mit den Hängern lässt sich mit den Attributen dumpMemlimit und dumpSpeed nicht lösen. Ich habe nun beide Werte auf bis zu 25% reduziert, der Dump dauert nun mehrere Stunden, aber die Hänger treten unverändert, nur während des Dumps auf. Bin jetzt wieder auf die Standardeinstellungen zurück.

Andere Varainte wäre auf dumpMySQL serverSide umzustellen. Das Verfahren nutzt eine andere Technologie und braucht weniger Speicher.
Meistens reicht dieses Backup aus, wir braucehn üblicherweise die SQLs nicht um die Tabellen zu erstellen. Das können wir vorher manuell machen im Bedarfsfall.

Ich würde nun den Versuch machen wollen und mein dump auf "serverSide" umstellen. Dabei ändert sich aber vermutlich die Widerherstellungsprodzedur der gesicherten Datenbank grundlegend. Die Wiederherstellung vom "clientSide" Dump hatte ich schon mehrmals erfolgreich durchgeführt. 
Bei mir läuft Fhem und MariaDB auf dem gleichen Raspi3 auf einer SD-Card (tausche ich regelmäßig und Backups werden auf anderen Rechner ausgelagert).

So wie ich es in der Commandref verstanden habe, muss ich nur unter dumpMySQL clientSide gegen serverSide tauschen. Das eingestellte Verzeichnis unter dumpDirLocal sollte immer noch gültig bleiben. Habe ich da noch etwas überlesen, was ich bei der Umstellung beachten muss?

In jedem Fall möchte ich das Restore vor einem echten Problem mal durchführen, hast du da einen Link wo die Vorgehensweise auch für nicht geübte SQL-Profis beschrieben ist.

Gruß Reinhard

[DS_Starter]

Hallo Reinhard,

So wie ich es in der Commandref verstanden habe, muss ich nur unter dumpMySQL clientSide gegen serverSide tauschen. Das eingestellte Verzeichnis unter dumpDirLocal sollte immer noch gültig bleiben. Habe ich da noch etwas überlesen, was ich bei der Umstellung beachten muss?

Soweit richtig, nur das Attr dumpDirRemote musst du noch setzen, auch wenn der MySQL Server eigentlich lokal läuft. Die Angabe teilt dem Server mit wohin er das File schreiben soll.

Ich erstelle im Wiki eine Anleitung für Backup / Restore mit dieser Option. Das verdeutlicht vieles denke ich.

LG,
Heiko

[DS_Starter]

Hallo Reinhard,
ich habe eine Anleitung für die serverSide Option im Wiki hinterlegt.
Grüße,Heiko

[Rewe2000]

Hallo Heiko,

vielen dank für die ausführliche Anleitung im WIKI.
Obwohl du die Anleitung sehr umfangreich erstellt hast, wird es dazu von meiner Seite noch die eine oder andere Frage geben.

Das Ziel sollte nicht nur sein Backups zu erstellen, sondern auch das Restore zu testen, damit im Fehlerfall die Hektik nicht um sich greift

Nochmals Danke für dein Arbeit (und deine unermüdliche Geduld mit uns Usern).

Gruß Reinhard

[DS_Starter]

Moin Reinhard,
gerne doch. 

Obwohl du die Anleitung sehr umfangreich erstellt hast, wird es dazu von meiner Seite noch die eine oder andere Frage geben.

Kein Problem, einfach fragen. Ggf. wird der Wiki-Beitrag noch ergänzt.

Das Ziel sollte nicht nur sein Backups zu erstellen, sondern auch das Restore zu testen, damit im Fehlerfall die Hektik nicht um sich greift

Vollkommen richtig. Man sollte restore auch mal geübt haben. Restore ist ja auch mit beschrieben.Wenn du Lust hast, erstellst du dir einfach eine neue DB zum Üben, mit einem DbLog und DbRep. Dort kannst du nach Belieben dumpen und restoren. Du kannst dir auch ein serverSide-Backup deiner produktiven DB reinladen.Wie das geht, sage ich dir falls du mal an diesen Punkt kommen solltest.

LG,Heiko

[DS_Starter]

Hallo Reinhard,

eine Bitte ... kannst du mal bei Gelegenheit den Threadtitel ändern zum Beispiel in

"DBRep-MySQL Backup produziert viele Fhem Hänger"

Ich möchte nicht, dass unbedarfte Anfänger glauben das DbRep-Modul arbeitet blockierend, produziert per se freezes und bei der nächsten Gelegenheit wird auf diesen Thread verwiesen und ich muß es wieder gerade rücken

Danke und LG,
Heiko

[DS_Starter]

Herzlichen Dank Reinhard ... das hat mich wirklich sehr gefreut !!!   
Ich versuche weiterhin wo es geht zu helfen wenn ich kann und auch die Module weiter zu verbessern/auszubauen.

Im Sommer geht FHEM ein bisschen auf Sparflamme wegen der Gartenarbeit und den Naturerlebnissen. 

schönen Tag !

LG,
Heiko

[Rewe2000]

Hallo Heiko,

ich habe das Dump bei mir nun auf serverSide umgestellt.
Ich beobachte nun aber viele Hänger während der Tabellenoptimierung (war aber auch die vergangenen Tage unter "clientSide" so:

Code Auswählen Erweitern

2020.05.17 10:10:32 3: DbRep DBReport - ################################################################
2020.05.17 10:10:32 3: DbRep DBReport - ###             New database serverSide dump                 ###
2020.05.17 10:10:32 3: DbRep DBReport - ################################################################
2020.05.17 10:10:32 3: DbRep DBReport - execute command before dump: 'set DBLogging reopen 3600'
2020.05.17 10:10:32 2: DbLog DBLogging: Connection closed until 11:10:32 (3600 seconds).
2020.05.17 10:10:32 3: DbRep DBReport - Searching for tables inside database fhem....
2020.05.17 10:10:32 3: DbRep DBReport - Size of database fhem before optimize (MB): 348.33
2020.05.17 10:10:32 3: DbRep DBReport - Optimizing tables
2020.05.17 10:10:32 3: DbRep DBReport - Optimizing table `current` (INNODB). It will take a while.
2020.05.17 10:10:32 3: DbRep DBReport - Table 1 `current` optimized successfully.
2020.05.17 10:10:32 3: DbRep DBReport - Optimizing table `history` (INNODB). It will take a while.
2020.05.17 10:11:30 1: Perfmon: possible freeze starting at 10:11:29, delay is 1.974
2020.05.17 10:11:36 1: Perfmon: possible freeze starting at 10:11:31, delay is 5.404
2020.05.17 10:13:45 1: Perfmon: possible freeze starting at 10:13:44, delay is 1.004
2020.05.17 10:15:14 1: Perfmon: possible freeze starting at 10:15:13, delay is 1.335
2020.05.17 10:15:31 1: Perfmon: possible freeze starting at 10:15:29, delay is 2.569
2020.05.17 10:17:13 1: Perfmon: possible freeze starting at 10:17:08, delay is 5.886
2020.05.17 10:18:08 1: Perfmon: possible freeze starting at 10:17:57, delay is 11.26
2020.05.17 10:18:14 1: Perfmon: possible freeze starting at 10:18:09, delay is 4.968
2020.05.17 10:21:28 1: Perfmon: possible freeze starting at 10:21:13, delay is 15.831
2020.05.17 10:23:21 1: Perfmon: possible freeze starting at 10:23:04, delay is 17.435
2020.05.17 10:24:28 1: Perfmon: possible freeze starting at 10:24:23, delay is 5.067
2020.05.17 10:24:28 3: ModbusTCPServer_Timeout, request: SimpleWrite [42 D9 00 00 00 06] 00 01 42 D9 00 08
2020.05.17 10:25:35 3: DbRep DBReport - Table 2 `history` optimized successfully.
2020.05.17 10:25:35 3: DbRep DBReport - 2 tables have been optimized.
2020.05.17 10:25:35 3: DbRep DBReport - Size of database fhem after optimize (MB): 351.33
Ich denke irgendwann muss ich mich mal mit anderer Hardware als einem Raspi beschäftigen.
Wenn man einen 10 Meter Wohnwagen besitzt, zieht diesen auch nicht ein 500'er Fiat

Irgendwie fehlt mir da komplett das Gefühl, sollte denn eine Datenbankgröße von ca. 350 MB, mit unter 2 Mio. Datensätzen mit SQL auf einem Raspi3 noch zu betreiben sein oder platzt der da aus allen Nähten?
Ich habe auch schon daran gedacht meine SD Speicherkarte zu erneuern (mache ich jährlich).

Ich bin fest der Überzeugung, dass meine Hardware an die Grenzen stößt. Alleine mit Logdateien (ohne DBLog) wäre diese Datenflut sicherlich nicht mehr zu bändigen.

Jetz habe ich aber noch ein Rechteproblem, dazu brächte ich noch deine Hilfe:

Code Auswählen Erweitern

2020.05.17 10:25:35 2: DbRep DBReport - DBD::mysql::st execute failed: Access denied for user 'NAME'@'%' (using password: YES) at ./FHEM/93_DbRep.pm line 7730.

Habe mich eben in meine MariaDB über die Konsole eingeloggt, hier kann ich mich mit dem User "NAME" und dem Kennwort "PASSWORT" problemlos anmelden. Ich habe hier die gleichen Zugangsdaten wie für Fhem auch verwendet, deshalb kann ich mir nicht ganz erklären, was hier noch fehlt. Sollte dies die Schreibrechte für das Backup Verzeichnis betreffen? Wenn ich hier nachsehe, so sind diese auf "fhem dialout" mit allen Rechten eingestellt.

Anbei die RAW Definition meines DBRep Device, welches über ein at mit ServerSide aufgerufen wird:

Code Auswählen Erweitern

defmod DBReport DbRep DBLogging
attr DBReport DbLogExclude .*
attr DBReport DbLogInclude INFO_history.data_index_length_MB.*,INFO_history.number_of_rows.*
attr DBReport comment Dies ist das aktuelle Reportdevice der aktuellen DbLog SQL-Datenbank, mit diesem Devise können Datenbankbefehle und Reports ausgeführt werden.
attr DBReport devStateIcon connected:it_network .*disconnect:control_home .*done:general_ok running:refresh
attr DBReport dumpDirLocal /opt/fhem/backup
attr DBReport dumpDirRemote /opt/fhem/backup
attr DBReport dumpFilesKeep 8
attr DBReport executeAfterProc set DBLogging reopen
attr DBReport executeBeforeProc set DBLogging reopen 3600
attr DBReport group Hardware
attr DBReport icon system_backup
attr DBReport optimizeTablesBeforeDump 1
attr DBReport room Logging
attr DBReport showTableInfo %history%,%current%
attr DBReport showproctime 1
attr DBReport timeDiffToNow d:32
attr DBReport timeOlderThan d:30
attr DBReport verbose 3


Ich habe im DBRep device wie von dir im WIKI unter "Restore" beschrieben:

set  <Name> adminCredentials <Name> <Passwort>
attr <Name> useAdminCredentials 1

versucht, aber leider hier nicht mit dem gewünschten Erfolg.

Code Auswählen Erweitern

SqlResultRow_1 GRANTS FOR USER@%                                                                                            2020-05-17 11:51:34
SqlResultRow_2 GRANT USAGE ON *.* TO 'USER'@'%' IDENTIFIED BY PASSWORD '*...............................' 2020-05-17 11:51:34
SqlResultRow_3 GRANT SELECT, INSERT, UPDATE, DELETE ON `fhem`.* TO 'USER'@'%'                            2020-05-17 11:51:34
SqlResultRow_4 GRANT SELECT, INSERT, UPDATE, DELETE ON `old-fhem`.* TO 'USER'@'%'                      2020-05-17 11:51:34
aftersqlCmd_message Reopen executed.                                                                                                  2020-05-17 11:51:34
background_processing_time 0.0235                                                                                                         2020-05-17 11:51:34
sqlCmd show grants;                                                                                                                                  2020-05-17 11:51:34
sqlResultNumRows 3                                                                                                                                   2020-05-17 11:51:34
sql_processing_time 0.0153                                                                                                                       2020-05-17 11:51:34
state Warning - sqlCmd finished, but command message after sqlCmd appeared                                     2020-05-17 11:51:34

hab noch ein wenig gesucht, in meinem db.conf File steht:

Code Auswählen Erweitern

#
# database configuration file
#
#
## for MySQL
################################################################
%dbconfig= (
connection => "mysql:database=fhem;host=localhost;port=3306",
user => "NAME",
password => "PASSWORD",
utf8 => 1
);
.........

Wobei hier unter user der gleiche user, wie in der DBRep Fehlermeldung und unter "show grants" eingetragen ist.

Gruß Reinhard

[DS_Starter]

Moin Reinhard,

Ich denke irgendwann muss ich mich mal mit anderer Hardware als einem Raspi beschäftigen.
Wenn man einen 10 Meter Wohnwagen besitzt, zieht diesen auch nicht ein 500'er Fiat

Irgendwie fehlt mir da komplett das Gefühl, sollte denn eine Datenbankgröße von ca. 350 MB, mit unter 2 Mio. Datensätzen mit SQL auf einem Raspi3 noch zu betreiben sein oder platzt der da aus allen Nähten?

Ein Raspi ist ganz allgemein keine ideale Hardware für eine MySQL. Aber trotzdem ist die DB-Größe an sich nicht das Problem. Letztendlich ist es erstmal nur eine oder mehrere große Files solange sie sich auf dem Datenträger befinden.
Nur die Verarbeitung der Daten kann Engpässe in CPU-Leistung und RAM verursachen, was man aber versuchen kann zu optimieren.  Meine (Test)DB's sind teilweise 5 GB oder auch 8 GB groß und laufen rund. Allerdings auf einer Synology muss ich gestehen.

Man kann den für den MySQL Server allokierten Speicher generell beschränken. Das passiert in den Parametern des MySQL-Servers, i.A. in der Datei /etc/mysql/my.cnf.

Ein wesentlicher Parameter ist

Code Auswählen Erweitern

innodb_buffer_pool_size

Vielleicht ist der bei dir generell zu groß eingestellt (innodb_buffer_pool_size = 300 M) ?

Alternativ schaltest du die Tabellenoptimierung einfach mal ab für das Backup (optimizeTablesBeforeDump = 0).

Habe mich eben in meine MariaDB über die Konsole eingeloggt, hier kann ich mich mit dem User "NAME" und dem Kennwort "PASSWORT" problemlos anmelden. Ich habe hier die gleichen Zugangsdaten wie für Fhem auch verwendet, deshalb kann ich mir nicht ganz erklären, was hier noch fehlt. Sollte dies die Schreibrechte für das Backup Verzeichnis betreffen? Wenn ich hier nachsehe, so sind diese auf "fhem dialout" mit allen Rechten eingestellt.

Mit den Rechten für das Filesystem hat das nichts zu tun.
Aber in dem "show grants" (super Info  ) sehe ich dass dem User das globale Recht "FILE" fehlt. Das müsstest du ihm geben über deine Userverwaltung) und dann nochmal probieren.

Ich ergänze es noch im Wiki, in der CommandRef steht es drin.

Ich habe im DBRep device wie von dir im WIKI unter "Restore" beschrieben:

    set  <Name> adminCredentials <Name> <Passwort>
    attr <Name> useAdminCredentials 1

versucht, aber leider hier nicht mit dem gewünschten Erfolg.

Die adminCredentials  werden nur für die Abarbeitung von "sqlCmd" verwendet. In dem Wiki Beispiel für den truncate Befehl.
Ich denke mal drüber nach ob es auch Sinn macht diese Möglichkeit für den restore mit vorzusehen. Dadurch könnte man wahrscheinlich das "FILE"-Rechteproblem umgehen.

LG,
Heiko

[Rewe2000]

Hallo Heiko,

ich denke ich habe den Fehler bei mir gefunden.

In der Commandref steht:

Das Zielverzeichnis kann mit dem Attribut "dumpDirRemote" verändert werden. Es muß sich auf dem MySQL-Host gefinden und durch den MySQL-Serverprozess beschreibbar sein.
Der verwendete Datenbankuser benötigt das "FILE"-Privileg.

Nach dem SQL-Befehl  "GRANT FILE ON *.* TO 'BENUTZER'@'%'; " unter mySQL als user  "root" hat der Dump geklappt.

Der Dump ohne "optimizeTablesBeforeDump" läuft nun in weniger als 2 Minuten, ohne einen einzigen Hänger:

Code Auswählen Erweitern

2020.05.17 12:47:07 3: DbRep DBReport - ################################################################
2020.05.17 12:47:07 3: DbRep DBReport - ###             New database serverSide dump                 ###
2020.05.17 12:47:07 3: DbRep DBReport - ################################################################
2020.05.17 12:47:07 3: DbRep DBReport - execute command before dump: 'set DBLogging reopen 3600'
2020.05.17 12:47:07 2: DbLog DBLogging: Connection closed until 13:47:07 (3600 seconds).
2020.05.17 12:47:07 3: DbRep DBReport - Searching for tables inside database fhem....
2020.05.17 12:47:07 3: DbRep DBReport - Starting dump of database 'fhem', table 'history'
2020.05.17 12:48:40 3: DbRep DBReport - Number of exported datasets: 1895104
2020.05.17 12:48:40 3: DbRep DBReport - Size of backupfile: 168.74 MB
2020.05.17 12:48:40 3: DbRep DBReport - Finished backup of database fhem - total time used (hh:mm:ss): 00:01:32
2020.05.17 12:48:40 2: DbRep DBReport - command message after dump: "Reopen executed."
2020.05.17 12:48:40 3: DbRep DBReport - Database dump finished successfully.

Gruß Reinhard

[DS_Starter]

Super Reinhard 

Wiki ergänze ich noch bzgl. FILE Privileg und baue vlt. useAdminCredentials  auch für das Restore ein.
Mal schauen.

LG,
Heiko