Test Adapter ioBroker.backitup v3.1.x

[firebowl]

@simatec Ähh sorry, ja ist drauf.

[firebowl]

@simatec Proxmox und VM weil ich bei LXC den ConBee II nicht sauber zum laufen bekomm.

[simatec]

@firebowl Laut der Log Ausgabe würde ich daruf tippen, dass dein Mount-Point bereits belegt ist.
Also einfach mal alle Systeme inkl. NAS neustarten

mount error(16): Device or resource busy

[firebowl]

@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 neustarten

mount error(16): Device or resource busy

Hat 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] 0

Scheinbar kann er ja den alten Temp Ordner löschen und auch neu anlegen...

[simatec]

@firebowl Da dein mount ja nicht funktioniert kann das auch nicht funktionieren.
Er hat ja kein Backup für den restore

Mache mal folgendes

iobroker stop
iobroker fix
iobroker start

Dann deine Backups für den restore lokal in den Ordner /opt/iobroker/backups mit 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

[fu_zhou]

@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 < *.sql

wieder 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]

@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 restore

Mache mal folgendes

iobroker stop
iobroker fix
iobroker start

Dann deine Backups für den restore lokal in den Ordner /opt/iobroker/backups mit 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 done

Wurde jetzt was restored oder nicht?
Die DB hat aber garantiert nicht existiert vorher, hab influxdb vorhin ganz frisch installiert.

[fila612]

@fu_zhou
ja der Restore hat bei mir nicht direkt vom NAS geklappt. Hab daher die Files ins lokale Backup-Verzeichnis kopiert und von dort den Restore gemacht. Ist zwar nicht perfekt, aber ein akzeptabler Workaround.

[simatec]

@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.

https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#delete-a-database-with-drop-database

[firebowl]

@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.

https://docs.influxdata.com/influxdb/v1.8/query_language/manage-database/#delete-a-database-with-drop-database

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]

@firebowl Dann hat deine Datenbank noch existiert ... Der Fehler sagt es ja eindeutig

[simatec]

@firebowl

Bitte mal folgendes aus der Konsole zeigen:

influx
show databases
drop database "dein-DB-Name"
show databases
exit

Bitte unbedingt vorher den Influx Adapter und andere Systeme, die auf diese DB schreiben stoppen

[firebowl]

@simatec

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]

@firebowl Genau nun das Backup zurückspielen

[firebowl]

@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 done

Ein 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]

@firebowl Zeige doch mal bitte die Einstellungen in Backitup

[firebowl]

@simatec Vom Adapter der sichert oder von dem der wiederherstellen soll?
Letzterer is ja noch sehr leer.

[firebowl]

@simatec Hab's hinbekommen....
Hab jetzt noch mal die DB geleert und im Adapter den Haken gesetzt für Datenbank vorm Restore löschen.
Vielen Dank für deine ausdauernde Hilfe!

[ub.privat]

@simatec
@Thomas-Braun

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] 0

Bei 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.

[Thomas Braun]

@ub-privat sagte in Test Adapter Backitup v2.2.x:

mysqldump not found

Da 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.