NEWS
Test Adapter ioBroker.backitup v3.1.x
-
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl Laut der Log Ausgabe würde ich daruf tippen, dass dein Mount-Point bereits belegt ist.
Also einfach mal alle Systeme inkl. NAS neustartenmount error(16): Device or resource busyHat nicht geholfen:
Started restore ... [DEBUG] [influxDB] - Try deleting the old InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB old tmp directory was successfully deleted [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/influxDBtmp/' [ERROR] [influxDB] - infuxDB Restore not completed [EXIT] 0Scheinbar kann er ja den alten Temp Ordner löschen und auch neu anlegen...
@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restoreMache mal folgendes
iobroker stop iobroker fix iobroker startDann deine Backups für den restore lokal in den Ordner
/opt/iobroker/backupsmit einen SFTP Tool (z.B. Filezilla) legen und den Restore lokal starten.Wenn alle Restores durchgelaufen sind, würde ich mal komplett die Einstellungen an deinem NAS prüfen und die Einstellungen zu deinen alten PI vergleichen. Eventuell hat der NUC mit neuer IP keine Rechte auf deinem NAS und der alte PI mit seiner IP schon
-
danke dir, jedoch kann ich da gar nicht so viel prüfen bzw. sollte das passen.
Ich habe eine Synology DS918+ auf welcher ich extra einen User iobroker angelegt habe.
In dessen Home-Verzeichnis werden die Backups geschrieben, was auch mit der root Haken wunderbar funktioniert.
ich vermute grad, dass der umount nicht sauber läuft:
vorhin konnte ich lokal wieder restoren und konnte beobachten, dass während des Backups der Ordner "backups" laut Anzeige root:root zugeordnet war (passt ja auch wegen dem mount) und die hintergundfarbe des Ordners grün war.
Danach war diese Farbe weg und die Zuordnung war iobroker:iobroker => auch richtig.Dann habe ich nochmals eine Sicherung angestoßen und nun ist Ordner backups immer nicht grün und root:root.
Auch ein manueller umount zeigt folgendes an:
@fila612 hast du das mit den Rechten auf dem NAS hinbekommen? Ich kriege das nicht hin, bei mir ist und bleibt der CIFS-gemountete Ordner unter /opt/iobroker/backups beim Benutzer root und damit funktioniert das Wiederherstellen vom NAS nicht. Der mysql-dump wird zwar entpackt aber nicht wieder hergestellt, wobei ich den entpackten Dump manuell mit
mysql -u iobroker -p iobroker < *.sqlwieder herstellen kann.
Ich behelfe mir im Moment damit, die .gz-Backups vom NAS nach lokal (opt/iobroker/backups) zu kopieren und dann restore von lokal.Hast du eine Lösung?
-
@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restoreMache mal folgendes
iobroker stop iobroker fix iobroker startDann deine Backups für den restore lokal in den Ordner
/opt/iobroker/backupsmit einen SFTP Tool (z.B. Filezilla) legen und den Restore lokal starten.Wenn alle Restores durchgelaufen sind, würde ich mal komplett die Einstellungen an deinem NAS prüfen und die Einstellungen zu deinen alten PI vergleichen. Eventuell hat der NUC mit neuer IP keine Rechte auf deinem NAS und der alte PI mit seiner IP schon
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restoreMache mal folgendes
iobroker stop iobroker fix iobroker startDann deine Backups für den restore lokal in den Ordner
/opt/iobroker/backupsmit einen SFTP Tool (z.B. Filezilla) legen und den Restore lokal starten.Wenn alle Restores durchgelaufen sind, würde ich mal komplett die Einstellungen an deinem NAS prüfen und die Einstellungen zu deinen alten PI vergleichen. Eventuell hat der NUC mit neuer IP keine Rechte auf deinem NAS und der alte PI mit seiner IP schon
Hab das Backup jetzt "lokal" abgelegt und versucht wiederherzustellen:
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 11:27:07 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore doneWurde jetzt was restored oder nicht? ;)
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert. -
@fila612 hast du das mit den Rechten auf dem NAS hinbekommen? Ich kriege das nicht hin, bei mir ist und bleibt der CIFS-gemountete Ordner unter /opt/iobroker/backups beim Benutzer root und damit funktioniert das Wiederherstellen vom NAS nicht. Der mysql-dump wird zwar entpackt aber nicht wieder hergestellt, wobei ich den entpackten Dump manuell mit
mysql -u iobroker -p iobroker < *.sqlwieder herstellen kann.
Ich behelfe mir im Moment damit, die .gz-Backups vom NAS nach lokal (opt/iobroker/backups) zu kopieren und dann restore von lokal.Hast du eine Lösung?
-
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restoreMache mal folgendes
iobroker stop iobroker fix iobroker startDann deine Backups für den restore lokal in den Ordner
/opt/iobroker/backupsmit einen SFTP Tool (z.B. Filezilla) legen und den Restore lokal starten.Wenn alle Restores durchgelaufen sind, würde ich mal komplett die Einstellungen an deinem NAS prüfen und die Einstellungen zu deinen alten PI vergleichen. Eventuell hat der NUC mit neuer IP keine Rechte auf deinem NAS und der alte PI mit seiner IP schon
Hab das Backup jetzt "lokal" abgelegt und versucht wiederherzustellen:
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 11:27:07 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore doneWurde jetzt was restored oder nicht? ;)
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB. -
@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB.@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB.Bringt leider nix.
Hab die VM noch mal zurückgesetzt auf einen Stand vor der Influx Installation.
Dann hab ich folgendes gemacht:- influxdb installiert
- admin und normalen User mit CREATE USER angelegt
- Datenbank mit CREATE DATABASE angelegt
- dem User Rechte auf die DB gegeben
- Influx Adapter im ioBroker installiert
- Adapter angehalten und Datenbank mit DROP DATABASE geleert
- Backup eingespielt bzw. es versucht, der Fehler bleibt gleich
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 12:54:54 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done
Mod-Edit: Code in </> Code-Tag gepackt!
-
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB.Bringt leider nix.
Hab die VM noch mal zurückgesetzt auf einen Stand vor der Influx Installation.
Dann hab ich folgendes gemacht:- influxdb installiert
- admin und normalen User mit CREATE USER angelegt
- Datenbank mit CREATE DATABASE angelegt
- dem User Rechte auf die DB gegeben
- Influx Adapter im ioBroker installiert
- Adapter angehalten und Datenbank mit DROP DATABASE geleert
- Backup eingespielt bzw. es versucht, der Fehler bleibt gleich
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 12:54:54 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done
Mod-Edit: Code in </> Code-Tag gepackt!
-
@simatec sagte in Test Adapter Backitup v2.2.x:
@firebowl sagte in Test Adapter Backitup v2.2.x:
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.
Wenn du den Influx Adapter installierst und und konfigurierst, wird durch den Adapter die DB angelegt
Also vorher den Adapter stoppen und die DB löschen. Influx kann leider kein kompletten Restore in eine bestehende DB.Bringt leider nix.
Hab die VM noch mal zurückgesetzt auf einen Stand vor der Influx Installation.
Dann hab ich folgendes gemacht:- influxdb installiert
- admin und normalen User mit CREATE USER angelegt
- Datenbank mit CREATE DATABASE angelegt
- dem User Rechte auf die DB gegeben
- Influx Adapter im ioBroker installiert
- Adapter angehalten und Datenbank mit DROP DATABASE geleert
- Backup eingespielt bzw. es versucht, der Fehler bleibt gleich
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 12:54:54 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore done
Mod-Edit: Code in </> Code-Tag gepackt!
-
Bitte mal folgendes aus der Konsole zeigen:
influx show databases drop database "dein-DB-Name" show databases exitBitte unbedingt vorher den Influx Adapter und andere Systeme, die auf diese DB schreiben stoppen
mike@iobroker:~$ influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > show databases name: databases name ---- _internal ioBroker > drop database ioBroker > show databases name: databases name ---- _internal >Nach dem droppen is die DB weg.
Adapter ist weiterhin gestoppt und ich spiel das Backup ein, richtig? -
mike@iobroker:~$ influx Connected to http://localhost:8086 version 1.8.10 InfluxDB shell version: 1.8.10 > show databases name: databases name ---- _internal ioBroker > drop database ioBroker > show databases name: databases name ---- _internal >Nach dem droppen is die DB weg.
Adapter ist weiterhin gestoppt und ich spiel das Backup ein, richtig? -
@simatec Leider genau das gleiche.
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 13:28:53 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore doneEin show database zeigt keine DB an und wenn ich den Adapter starte dann wird wieder die DB angelegt.
Wurde jetzt was zurückgespielt oder hat der Adapter einfach ne leere DB angelegt?EDIT: Ist ne leere DB /var/lib/influxdb/data/ sind 88KB und auf dem alten System sind es 75MB.
Mod-Edit: Code in </> Code-Tag gepackt!
-
@simatec Leider genau das gleiche.
Started restore ... [DEBUG] [influxDB] - Created tmp directory [DEBUG] [influxDB] - Start infuxDB Restore ... [ERROR] [influxDB] - 2021/12/02 13:28:53 error updating meta: DB metadata not changed. database may already exist restore: DB metadata not changed. database may already exist [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - infuxDB Restore completed successfully [EXIT] influxDB restore doneEin show database zeigt keine DB an und wenn ich den Adapter starte dann wird wieder die DB angelegt.
Wurde jetzt was zurückgespielt oder hat der Adapter einfach ne leere DB angelegt?EDIT: Ist ne leere DB /var/lib/influxdb/data/ sind 88KB und auf dem alten System sind es 75MB.
Mod-Edit: Code in </> Code-Tag gepackt!
@firebowl Zeige doch mal bitte die Einstellungen in Backitup
-
Nachdem ich nun die fast 1500 Beiträge gelesen/überflogen habe, muss ich um eure Unterstützung bitten.
Als ich den Adapter eingerichtet habe und einmalig manuell das Backup erstellt wurde, sah alles super aus! Freude war groß...3 Tage mit viel probieren sind vorbei, die automatischen Backups liefern nur Datein mit einer Größe von 0kB ???
So schaut der Vorgang aus:Started iobroker ... [DEBUG] [mount] - noserverino option: false [DEBUG] [mount] - cifs-mount command: "sudo mount -t cifs -o username=Uwe,password=****,rw,file_mode=0777,dir_mode=0777,vers=3.1.1 //192.168.178.20/300_SMARTHOME/310_BACKUP/IOB_1 /opt/iobroker/backups" [DEBUG] [mount] - mount successfully completed [DEBUG] [mount] - done [DEBUG] [iobroker] - host.raspberrypi 15813 states saved [DEBUG] [iobroker] - host.raspberrypi 18592 objects saved [DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2021_12_14-16_59_04_backupiobroker.tar.gz [DEBUG] [iobroker] - done [DEBUG] [influxDB] - InfluxDB-Backup started ... [DEBUG] [influxDB] - Start InfluxDB Backup ... [DEBUG] [influxDB] - InfluxDB Backup tmp directory created [DEBUG] [influxDB] - Backup created: /opt/iobroker/backups/influxDB_2021_12_14-16_59_23_backupiobroker.tar.gz [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - InfluxDB-Backup for is finish [DEBUG] [influxDB] - done [DEBUG] [mysql] - MySql-Backup started ... [ERROR] [mysql] - [IGNORED] Error: Command failed: mysqldump -u ioBroker -p**** iobroker -h 192.168.178.20 -P 3307 > /opt/iobroker/backups/mysql_2021_12_14-16_59_27_backupiobroker.sql /bin/sh: 1: mysqldump: not found [DEBUG] [historyDB] - compress from historyDB started ... [ERROR] [historyDB] - [IGNORED] Backitup cannot found source "undefined" for compress! [DEBUG] [grafana] - Start Grafana Backup ... [DEBUG] [grafana] - Created grafana_tmp directory: "/opt/iobroker/backups/grafana_tmp" [DEBUG] [grafana] - Created dashboard directory [DEBUG] [grafana] - Created dashboards_manually_restore directory [DEBUG] [grafana] - Created datasource directory [DEBUG] [grafana] - start Grafana request ... [DEBUG] [grafana] - Grafana is available ... Status: 200 [DEBUG] [grafana] - Error on Grafana Dashoard Request: Error: Request failed with status code 401 [DEBUG] [grafana] - start Grafana backup compress ... [DEBUG] [grafana] - Try deleting the Grafana tmp directory: "/opt/iobroker/backups/grafana_tmp" [DEBUG] [grafana] - Grafana tmp directory "/opt/iobroker/backups/grafana_tmp" successfully deleted [DEBUG] [grafana] - cannot found Grafana Backup files [DEBUG] [grafana] - done [DEBUG] [ftp] - FTP connected. [DEBUG] [ftp] - Send iobroker_2021_12_14-16_59_04_backupiobroker.tar.gz [DEBUG] [ftp] - Send influxDB_2021_12_14-16_59_23_backupiobroker.tar.gz [DEBUG] [ftp] - Send mysql_2021_12_14-16_59_27_backupiobroker.tar.gz [ERROR] [ftp] - File "/opt/iobroker/backups/mysql_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [DEBUG] [ftp] - Send historyDB_2021_12_14-16_59_27_backupiobroker.tar.gz [ERROR] [ftp] - File "/opt/iobroker/backups/historyDB_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [DEBUG] [ftp] - done [DEBUG] [cifs] - done [DEBUG] [googledrive] - Google Drive: Copy iobroker_2021_12_14-16_59_04_backupiobroker.tar.gz... [DEBUG] [googledrive] - Google Drive: Copy influxDB_2021_12_14-16_59_23_backupiobroker.tar.gz... [ERROR] [googledrive] - Google Drive: File "/opt/iobroker/backups/mysql_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [ERROR] [googledrive] - Google Drive: File "/opt/iobroker/backups/historyDB_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [DEBUG] [googledrive] - done [ERROR] [clean] - Backup files not deleted from /opt/iobroker/backups because some errors. [DEBUG] [clean] - done [DEBUG] [email] - done [DEBUG] [historyHTML] - new history html values created [DEBUG] [historyHTML] - done [DEBUG] [historyJSON] - new history json values created [DEBUG] [historyJSON] - done [DEBUG] [umount] - mount activ, umount is started ... [DEBUG] [umount] - umount successfully completed [DEBUG] [umount] - done [EXIT] 0Bei allen Sicherungsquellen wird das Backup mit 0kB abgelegt.
Hier sieht man, am 10.12. lief alles super, konnte auch einwandfrei rückspielen. An den anderen Tagen nur 0kB Datein.
Mir ist bewußt, dass einige ERROR's stehen, aber leider für mich nicht verständlich, daher meine Bitte nach Hilfe!
Danke schon mal vorab. -
Nachdem ich nun die fast 1500 Beiträge gelesen/überflogen habe, muss ich um eure Unterstützung bitten.
Als ich den Adapter eingerichtet habe und einmalig manuell das Backup erstellt wurde, sah alles super aus! Freude war groß...3 Tage mit viel probieren sind vorbei, die automatischen Backups liefern nur Datein mit einer Größe von 0kB ???
So schaut der Vorgang aus:Started iobroker ... [DEBUG] [mount] - noserverino option: false [DEBUG] [mount] - cifs-mount command: "sudo mount -t cifs -o username=Uwe,password=****,rw,file_mode=0777,dir_mode=0777,vers=3.1.1 //192.168.178.20/300_SMARTHOME/310_BACKUP/IOB_1 /opt/iobroker/backups" [DEBUG] [mount] - mount successfully completed [DEBUG] [mount] - done [DEBUG] [iobroker] - host.raspberrypi 15813 states saved [DEBUG] [iobroker] - host.raspberrypi 18592 objects saved [DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2021_12_14-16_59_04_backupiobroker.tar.gz [DEBUG] [iobroker] - done [DEBUG] [influxDB] - InfluxDB-Backup started ... [DEBUG] [influxDB] - Start InfluxDB Backup ... [DEBUG] [influxDB] - InfluxDB Backup tmp directory created [DEBUG] [influxDB] - Backup created: /opt/iobroker/backups/influxDB_2021_12_14-16_59_23_backupiobroker.tar.gz [DEBUG] [influxDB] - Try deleting the InfluxDB tmp directory [DEBUG] [influxDB] - InfluxDB tmp directory was successfully deleted [DEBUG] [influxDB] - InfluxDB-Backup for is finish [DEBUG] [influxDB] - done [DEBUG] [mysql] - MySql-Backup started ... [ERROR] [mysql] - [IGNORED] Error: Command failed: mysqldump -u ioBroker -p**** iobroker -h 192.168.178.20 -P 3307 > /opt/iobroker/backups/mysql_2021_12_14-16_59_27_backupiobroker.sql /bin/sh: 1: mysqldump: not found [DEBUG] [historyDB] - compress from historyDB started ... [ERROR] [historyDB] - [IGNORED] Backitup cannot found source "undefined" for compress! [DEBUG] [grafana] - Start Grafana Backup ... [DEBUG] [grafana] - Created grafana_tmp directory: "/opt/iobroker/backups/grafana_tmp" [DEBUG] [grafana] - Created dashboard directory [DEBUG] [grafana] - Created dashboards_manually_restore directory [DEBUG] [grafana] - Created datasource directory [DEBUG] [grafana] - start Grafana request ... [DEBUG] [grafana] - Grafana is available ... Status: 200 [DEBUG] [grafana] - Error on Grafana Dashoard Request: Error: Request failed with status code 401 [DEBUG] [grafana] - start Grafana backup compress ... [DEBUG] [grafana] - Try deleting the Grafana tmp directory: "/opt/iobroker/backups/grafana_tmp" [DEBUG] [grafana] - Grafana tmp directory "/opt/iobroker/backups/grafana_tmp" successfully deleted [DEBUG] [grafana] - cannot found Grafana Backup files [DEBUG] [grafana] - done [DEBUG] [ftp] - FTP connected. [DEBUG] [ftp] - Send iobroker_2021_12_14-16_59_04_backupiobroker.tar.gz [DEBUG] [ftp] - Send influxDB_2021_12_14-16_59_23_backupiobroker.tar.gz [DEBUG] [ftp] - Send mysql_2021_12_14-16_59_27_backupiobroker.tar.gz [ERROR] [ftp] - File "/opt/iobroker/backups/mysql_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [DEBUG] [ftp] - Send historyDB_2021_12_14-16_59_27_backupiobroker.tar.gz [ERROR] [ftp] - File "/opt/iobroker/backups/historyDB_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [DEBUG] [ftp] - done [DEBUG] [cifs] - done [DEBUG] [googledrive] - Google Drive: Copy iobroker_2021_12_14-16_59_04_backupiobroker.tar.gz... [DEBUG] [googledrive] - Google Drive: Copy influxDB_2021_12_14-16_59_23_backupiobroker.tar.gz... [ERROR] [googledrive] - Google Drive: File "/opt/iobroker/backups/mysql_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [ERROR] [googledrive] - Google Drive: File "/opt/iobroker/backups/historyDB_2021_12_14-16_59_27_backupiobroker.tar.gz" not found [DEBUG] [googledrive] - done [ERROR] [clean] - Backup files not deleted from /opt/iobroker/backups because some errors. [DEBUG] [clean] - done [DEBUG] [email] - done [DEBUG] [historyHTML] - new history html values created [DEBUG] [historyHTML] - done [DEBUG] [historyJSON] - new history json values created [DEBUG] [historyJSON] - done [DEBUG] [umount] - mount activ, umount is started ... [DEBUG] [umount] - umount successfully completed [DEBUG] [umount] - done [EXIT] 0Bei allen Sicherungsquellen wird das Backup mit 0kB abgelegt.
Hier sieht man, am 10.12. lief alles super, konnte auch einwandfrei rückspielen. An den anderen Tagen nur 0kB Datein.
Mir ist bewußt, dass einige ERROR's stehen, aber leider für mich nicht verständlich, daher meine Bitte nach Hilfe!
Danke schon mal vorab.@ub-privat sagte in Test Adapter Backitup v2.2.x:
mysqldump not foundDa fehlt wohl was. Welche Datenbank? mariadb? mariadb-client dann installiert?
Dann würde ich auch nicht per ftp agieren sondern mit smb/cifs oder nfs.
-
@ub-privat sagte in Test Adapter Backitup v2.2.x:
mysqldump not foundDa fehlt wohl was. Welche Datenbank? mariadb? mariadb-client dann installiert?
Dann würde ich auch nicht per ftp agieren sondern mit smb/cifs oder nfs.
Danke für die schnelle Antwort.
Ja eine MariaDB ist auf der Syno DS216P installiert. Diese wird auch aktiv angesprochen.
Einen Client habe ich auf dem Raspi definitiv nicht installiert (weiß leider nicht wie!).
FTP habe ich nur als alternitves Sicherungsziel verwendet, kann also kurzfrisitg weg.
-
Danke für die schnelle Antwort.
Ja eine MariaDB ist auf der Syno DS216P installiert. Diese wird auch aktiv angesprochen.
Einen Client habe ich auf dem Raspi definitiv nicht installiert (weiß leider nicht wie!).FTP habe ich nur als alternitves Sicherungsziel verwendet, kann also kurzfrisitg weg.
@ub-privat
Auf dem Raspi muss ein Paket wie
mariadb-client-XXX
installiert sein. Wobei XXX für die Version steht.
Persudo apt update apt policy mariadb-client<TAB-Taste><TAB-Taste>kannst du schauen was da verfügbar ist.
-
@ub-privat
Auf dem Raspi muss ein Paket wie
mariadb-client-XXX
installiert sein. Wobei XXX für die Version steht.
Persudo apt update apt policy mariadb-client<TAB-Taste><TAB-Taste>kannst du schauen was da verfügbar ist.
-
mariadb-client-10.0 mariadb-client-10.3 mariadb-client-core-10.0 mariadb-client-core-10.3
@ub-privat
Und auf der anderen Kiste läuft welche Version? Ich würde da möglichst nah herangehen mit der Nummer.
Support us
483
Online32.5k
Benutzer81.6k
Themen1.3m
Beiträge