Test Adapter ioBroker.backitup v3.1.x

[simatec]

@Holzlenkrad

Könntest du mal testen, ob es jetzt mit gesetzten Häckchen bei zigbee trotzdem läuft und auch beendet wird?
Installation über Github:

https://github.com/simatec/ioBroker.backitup/tarball/dev

Den Link direkt in der Katze unter Adaptern einfügen.

Am besten auch mal die debug Ausgaben hier posten

[JB_Sullivan]

Hallo zusammen - ist die Meldung etwas worüber man sich Gedanken machen muss?
Es steht zwar nicht kritisch, aber trotzdem ist es ein Fehler.

[simatec]

@JB_Sullivan
Nein musst du dir keine Gedanken machen.
Glaube das wurde in einem der neuen js-controller Versionen auch gefixt.

[JB_Sullivan]

@simatec
Naja, neuer als 3.1.4 geht glaube ich nicht und den habe ich drauf

[simatec]

@JB_Sullivan
OK ... wie gesagt, ich dachte das wurde geändert.
Aber wie die Meldungen auch aussagen, ist das nicht kritisch

[JB_Sullivan]

@simatec - OK Danke für die Info.

[Holzlenkrad]

@simatec
Zigbee war wohl die richtige Spur. Wenn ich das Zigbee-Backup deaktiviere, dann läuft das Backup richtig durch.

Mit der Version von Github funktioniert das Backup auf mit aktiviertem Zigbee, im Log steht dann:
[DEBUG] [zigbee] - undefined backup done

Allerdings ist mir aufgefallen, dass der Datenpunkt backitup.0.history.iobrokerLastTime den Wert "Error: Datum Uhrzeit" hat, und unter .html steht, dass nur ein lokales Backup gemacht wurde. Reicht das schon aus, dass ein Error geworfen wird?
Bei mir kümmert sich ein Cronjob auf dem Host-System darum, dass die Backup-Files entsprechend extern gesichert werden... Also eigentlich ist das so aus meinen Augen ein fehlerfreies Verhalten.

Außerdem ist mir aufgefallen, dass nach Änderungen der Adapter-Einstellungen unter dem Tab "Wiederherstellen" nach "Backups abrufen" keine vorhandenen Backups angezeigt werden. Man muss dann erst einmal die Konfiguration von Backitup schließen und neu öffnen, dass die Liste der Backups geladen wird.

[smartysmart]

Weiss jemand warum die mysql Datei nur als "." (PUNKT) in der zip gespeichert wird ?
Es ist nicht weiter schlimm, weil ich sie beim Entpacken umbenennen muss dann kann ich die Datei öffnen und hab alle Daten aber "just nice to know" ob man das fixen kann.

[simatec]

@smartysmart
Ist so gewollt und gür den Restore mit Backitup gedacht

[smartysmart]

@simatec sagte in Test Adapter Backitup v1.5.x:

@smartysmart
Ist so gewollt und gür den Restore mit Backitup gedacht

Achso, der Import macht dann keine Probleme? Ja dann ist ja eh super. Dachte das wird beim Import Probleme machen.

Top ... danke

[Jan1]

@simatec
Gestern kam die Frage auf warum eigentlich mit CIFS arbeiten wenn doch auch NFS zur Verfügung steht. Ich konnte mich dran erinnern, dass in der Adapter Doku dazu mal ein Vergleich gestanden hatte und da ich mich weder mit dem einen noch mit dem anderen ausgekannt hatte, hab ich mich nach dem Lesen dieses Vergleich für CIFS entschieden, nur finde ich besagten Vergleich im Zusammenhang mit dem Backitup Adapter nicht mehr.
Lange Rede kurzer Sinn, was ist denn nun die bessere Wahl wenn man von IOBroker der unter Linux läuft ein Backup auf ein NAS (in meinem Fall die Fritz) der auch unter Linux läuft sichern möchte?
SMB sprich CIFS ist ja eigentlich ne Windows Geschichte, was dann eher für NFS sprechen würde wenn man das unter Linux macht. Gibts hier überhaupt große Unterschiede oder Vor- und Nachteile?

[simatec]

@Jan1
Grundsätzlich finde ich NFS die bessere Wahl.
Allerdings unterstützen nicht alle NAS Laufwerke NFS. Daher gibt es beide Varianten.
Ich glaube die Fritzbox unterstützt nur CIFS.
Es sei denn, du hast sie gepatcht und Freetz drauf laufen

[deMarvin]

Hi,
bin etwas ratlos, mein SQL-Restore will einfach nicht.
Meine Daten:

• Node.js v12.18.0
• js-controller 3.14
• NPM v6.14.4

Mit Backitup 1.4.5 und auch 1.5.8 getestet.

[DEBUG] [mysql] Start mysql Restore ...
[ERROR] [mysql] Error: EPERM: operation not permitted, utime '/opt/iobroker/backups/mysql_restore_backupiobroker.sql'
[ERROR] [mysql] mysql Restore not completed
[EXIT] undefined **** Restore completed successfully!! ****

Den Fixer hab ich schon mehrfach ausgeführt. System ist ganz frisch und auf dem neusten Stand. MariaDB-User hat alle Rechte.
Weiß jemand weiter?

[simatec]

@deMarvin
Hast du mysqldump installiert und in Backitup den Pfad zur mysqldump angegeben?

[deMarvin]

@simatec
Nein und um ehrlich zu sein weiß ich auch nicht wo. Dumme Frage: Wo find ich das?

[edit1]
Ist wohl doch installiert, wie bekommt der User iobroker jetzt Rechte dafür?
Das Backup macht er übrigens Problemlos.

[edit2]
Hab mal den Pfad noch eingetragen, auch kein Erfolg. Selber Fehler wenn ich die Datenbank wiederherstellen will.

pi@iobroker:~ $ ls -la /usr/bin/mysqldump
-rwxr-xr-x 1 root root 3593164 Feb  2 14:33 /usr/bin/mysqldump

Jeder User hat aber Rechte zum ausführen.

[simatec]

@deMarvin
schau mal bitte was mysql für rechte hat
mysql und nicht mysqldump ist für die restore zuständig.

Kann es selber gerade nicht testen

[deMarvin]

@simatec
Für mysql hat auch jeder die Rechte zum ausführen:

pi@iobroker:~ $ ls -la /usr/bin/mysql
-rwxr-xr-x 1 root root 3692872 Feb  2 14:33 /usr/bin/mysql

Alle Rechte was mysql executables betrifft:

pi@iobroker:~ $ ls -la /usr/bin/ | grep mysql
lrwxrwxrwx  1 root root           5 Feb  2 14:33 mariadb -> mysql
lrwxrwxrwx  1 root root          10 Feb  2 14:33 mariadb-check -> mysqlcheck
-rwxr-xr-x  1 root root        1446 Feb  2 14:33 msql2mysql
-rwxr-xr-x  1 root root     3692872 Feb  2 14:33 mysql
-rwxr-xr-x  1 root root      111922 Feb  2 14:33 mysqlaccess
-rwxr-xr-x  1 root root     3556544 Feb  2 14:33 mysqladmin
lrwxrwxrwx  1 root root          10 Feb  2 14:33 mysqlanalyze -> mysqlcheck
-rwxr-xr-x  1 root root     3738136 Feb  2 14:33 mysqlbinlog
-rwxr-xr-x  1 root root     3520668 Feb  2 14:33 mysqlcheck
-rwxr-xr-x  1 root root        4217 Feb  2 14:33 mysql_convert_table_format
-rwxr-xr-x  1 root root       24714 Feb  2 14:33 mysqld_multi
-rwxr-xr-x  1 root root       30290 Feb  2 14:33 mysqld_safe
-rwxr-xr-x  1 root root     3263360 Feb  2 14:33 mysqld_safe_helper
-rwxr-xr-x  1 root root     3593164 Feb  2 14:33 mysqldump
-rwxr-xr-x  1 root root        8242 Feb  2 14:33 mysqldumpslow
-rwxr-xr-x  1 root root    15645464 Feb  2 14:33 mysql_embedded
-rwxr-xr-x  1 root root        3290 Feb  2 14:33 mysql_find_rows
-rwxr-xr-x  1 root root        1250 Feb  2 14:33 mysql_fix_extensions
-rwxr-xr-x  1 root root       34942 Feb  2 14:33 mysqlhotcopy
-rwxr-xr-x  1 root root     3511772 Feb  2 14:33 mysqlimport
-rwxr-xr-x  1 root root       19839 Feb  2 14:33 mysql_install_db
lrwxrwxrwx  1 root root          10 Feb  2 14:33 mysqloptimize -> mysqlcheck
-rwxr-xr-x  1 root root     3301148 Feb  2 14:33 mysql_plugin
lrwxrwxrwx  1 root root          10 Feb  2 14:33 mysqlrepair -> mysqlcheck
-rwxr-xr-x  1 root root       51235 Jan 29 06:38 mysqlreport
-rwxr-xr-x  1 root root       12527 Feb  2 14:33 mysql_secure_installation
-rwxr-xr-x  1 root root       17482 Feb  2 14:33 mysql_setpermission
-rwxr-xr-x  1 root root     3510828 Feb  2 14:33 mysqlshow
-rwxr-xr-x  1 root root     3529044 Feb  2 14:33 mysqlslap
-rwxr-xr-x  1 root root     3304956 Feb  2 14:33 mysql_tzinfo_to_sql
-rwxr-xr-x  1 root root     3373796 Feb  2 14:33 mysql_upgrade
-rwxr-xr-x  1 root root     3292456 Feb  2 14:33 mysql_waitpid
-rwxr-xr-x  1 root root        7878 Feb  2 14:33 wsrep_sst_mysqldump

[simatec]

@deMarvin
Ich denke da muss ich etwas umbauen ... Hatte ich beim Backup damals schon gemacht, aber beim Restore bisher nicht, da noch keine Probleme hatte.
Wird in der nächsten Version sein ... dann kannst du das nochmal testen

[simatec]

@deMarvin
habe da mal was zum testen für dich geändert ...
Versuche mal bitte mit der Version 1.5.9 aus dem Githublink.

https://github.com/simatec/ioBroker.backitup/tarball/dev

[deMarvin]

@simatec
Immer noch der gleiche Fehler.
Mir ist noch ein Bug aufgefallen. Wenn der Restore nicht funktioniert bleibt eine mysql_restore_backupiobroker.sql über, und Backitup findet keine Backups mehr. Erst wieder wenn man die Datei löscht.