Test Adapter ioBroker.backitup v3.1.x

[Siggi0904]

@thomas-braun hm, Thomas, ich würde sagen das sind nur die Konfigurationsdateien.
Siehe: https://packages.debian.org/buster/all/mysql-common/filelist

Ich denke, es könnte mariadb-client-10.3 sein.
Daran stört mich aber die Versionszahl. Die wird hoffentlich aktualisiert, wenn es was höheres gibt.

Die Idee war von mir, ob das nicht über npm verteilt werden könnte.
Dann wär es immer dabei und man müsste nichts separat installieren.

[Thomas Braun]

@siggi0904

/usr/bin/mysqldump mariadb-client-10.3

Daran stört mich aber die Versionszahl. Die wird hoffentlich aktualisiert, wenn es was höheres gibt.

Nicht bei Debian. Einmal veröffentlichte Versionen werden da nie erhöht. Wegen Stabiltät usw.

Die Idee war von mir, ob das nicht über npm verteilt werden könnte.

Nein, npm ist der NODE Package Manager. Das hat zum Glück mit dem Betriebssystem nichts zu tun.

[Siggi0904]

@thomas-braun sagte in Test Adapter Backitup v2.3.x:

Nein, npm ist der NODE Package Manager. Das hat zum Glück mit dem Betriebssystem nichts zu tun.

Jo, daher hatte ich ein Paket von dort vorgeschlagen.
Siehe https://forum.iobroker.net/post/778285

[Thomas Braun]

@siggi0904

Aber da wird doch auch mysqldump aufgerufen. Das muss also auf dem System schon vorhanden sein.

[simatec]

@siggi0904 Was spricht gegen mysqldump? Das ist ein kleine sehr schlankes Tool, was keine Ressourcen benötigt

[Siggi0904]

@simatec da spricht nichts dagegen. Ich suche nur ein Paket, was so schmal wie möglich ist.
Und falls NPM was hätte, wär das vielleicht auch nicht schlecht.

@thomas-braun sagte in Test Adapter Backitup v2.3.x:

Aber da wird doch auch mysqldump aufgerufen. Das muss also auf dem System schon vorhanden sein.

Achso, ich dachte, das bringt was eigenes mit.

[simatec]

@siggi0904 sagte in Test Adapter Backitup v2.3.x:

Achso, ich dachte, das bringt was eigenes mit.

Nein da wird die mysqldump nur per exec oder spawn gestartet.
Nix anderes macht backitup

[ullrjo]

@diwoma said in Test Adapter Backitup v2.3.x:

Hi,
Diesen Post habe ich auch schon in "ioBroker allgemein", weil den Thread erst jetzt entdeckt habe, sorry.
Aber ich glaube, hier ist er richtiger aufgehoben.

Ich habe Mitte des vorigen Jahres für BackItUp eine App auf Dropbox definiert und den Token eingetragen um das Backup gleich in die Cloud zu machen. Läuft auf dem Master in einem LXC auf Proxmox.

Jetzt habe ich einen Conbee2 auf einem Raspberry laufen und wollte die Zigbee-Daten ebenfalls auf die Dropbox senden.
Also eine neue App definiert (den alten Token habe ich mir natürlich nicht irgendwo gesichert ) und auf dem Pi eine Instanz des Adapters erstellt, der im Master als Backitup.1 erscheint.

Allerdings gibt es beim Upload Probleme:

Started iobroker ...
[DEBUG] [iobroker] - host.pi-broker 8389 states saved

[DEBUG] [iobroker] - host.pi-broker 9078 objects saved

[DEBUG] [iobroker] - Backup created: /opt/iobroker/backups/iobroker_2022_03_12-12_44_04_backupiobroker.tar.gz

[DEBUG] [iobroker] - done
[DEBUG] [zigbee] - found zigbee database: zigbee.0
[DEBUG] [zigbee] - done
[DEBUG] [ftp] - FTP connected.
[DEBUG] [ftp] - Send iobroker_2022_03_12-12_44_04_backupiobroker.tar.gz
[DEBUG] [ftp] - Send zigbee.0_2022_03_12-12_44_24_backupiobroker.tar.gz
[DEBUG] [ftp] - done
[DEBUG] [dropbox] - Dropbox: Copy iobroker_2022_03_12-12_44_04_backupiobroker.tar.gz...
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - Dropbox: Copy zigbee.0_2022_03_12-12_44_24_backupiobroker.tar.gz...
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - done
[DEBUG] [clean] - done
[DEBUG] [historyHTML] - new history html values created
[DEBUG] [historyHTML] - done
[DEBUG] [historyJSON] - new history json values created
[DEBUG] [historyJSON] - done
[EXIT] 0

Ich glaube mich zu erinnern, dass sich an der API in Dropbox was getan hat, zumindest bekam ich mal Mails dafür.
Ich kenne die Api und die Auswahl dazu nicht, könnte mir aber vorstellen, dass aufgrund des Token die neue API angesprochen wird und es da einen Fehler gibt.
Die alte Version im LXC läuft weiterhin ohne Probleme.

Aktuell auf beiden Rechnern laufende Adapter-Version: v2.3.5
Dass vor dem Upload ein FTP-Send zu sehen ist, liegt daran, dass ich das Backup, solange es nicht auf die Dropbox kommt auf ein NAS sichere.

Kann das ein Konfigurationsfehler meinerseits sein (was ich nicht glaube, weil bei 3 Einstellungen sollte man doch wenig Fehler machen können ) oder liegt es am Adapter?

Hab das gleiche Problem.
Denke auch es liegt an den Änderungen von Dropbox. (Mail hab ich auch bekommen )

Konntest du es schon lösen?
Oder hat vll sonst jemand eine Idee?

Vielen Dank

[simatec]

@ullrjo
In der Doku steht Schritt für Schritt beschrieben, wie Dropbox eingerichtet werden muss.

https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md#dropbox

[qqolli]

@haselchen

Hallo und danke. Die Einstellungen kannte ich bereits, mir geht es um die Einstellungen auf der NAS. Welche Einstellungen hast Du gewählt (s. unten)? Bekomme es noch nicht zum laufen

[haselchen]

@qqolli

Erstmal PCR Test , dann Arzt , dann bin ich für Dich da
Melde mich .

[diwoma]

@simatec said in Test Adapter Backitup v2.3.x:

In der Doku steht Schritt für Schritt beschrieben, wie Dropbox eingerichtet werden muss.
https://github.com/simatec/ioBroker.backitup/blob/master/docs/de/backitup.md#dropbox

Hi, daran habe ich mich auch gehalten, im vorigen Jahr und jetzt auch, aber es hat sich anscheinend im Untergrund was geändert, im Webinterface für Apps in Dropbox sehe ich z.B. kein "Access token expiration"

Aber was mir jetzt aufgefallen ist, im Log steht eine Error-Meldung:

backitup.1	2022-03-18 09:07:30.979	error	(13336) Dropbox: "missing_scope/..."
backitup.1	2022-03-18 09:07:30.978	error	(13336) Dropbox: "missing_scope/..."
backitup.1	2022-03-18 09:07:30.585	error	(13336) [iobroker] chmod for Backup directory could not be completed: Error: EPERM: operation not permitted, chmod '/opt/iobroker/backups'Please run "iobroker fix"!!

Ist das "missing_scope/..." eine fehlerhafte Einstellung im Adapter oder in der Dropbox?
Die Meldung mit dem chmod verstehe ich nicht ganz, ein "iob fix" hat nichts gebracht, die Rechte der Files und Verzeichnisse in '/opt/iobroker/backups' sind aber '777' also keine Einschränkungen bei Zugriffen, wie ich glaube.

Und das ist noch die DEBUG-Ausgabe betreff Dropbox:

[DEBUG] [dropbox] - Dropbox: Copy iobroker_2022_03_18-09_07_30_backupiobroker.tar.gz...
[DEBUG] [dropbox] start with {"type":"storage","source":"local","debugging":true,"deleteOldBackup":true,"accessToken":"****","ownDir":false,"dir":"/Slave/","dirMinimal":"/backupDir/iobroker","ignoreErrors":false,"deleteBackupAfter":0}
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - Dropbox: Copy zigbee.0_2022_03_18-09_07_41_backupiobroker.tar.gz...
[ERROR] [dropbox] - upload Dropbox: {"code":400,"text":"Error in call to API function \"files/upload\": Bad HTTP \"Content-Type\" header: \"application/gzip\".  Expecting one of \"application/octet-stream\", \"text/plain; charset=dropbox-cors-hack\"."}
[DEBUG] [dropbox] - done

[simatec]

@diwoma sagte in Test Adapter Backitup v2.3.x:

im Webinterface für Apps in Dropbox sehe ich z.B. kein "Access token expiration"

Gibt es wohl nicht mehr.

Ich habe aber gerade nach der Step by Step Anleitung aus der Doku eine neue App erstellt und in Backitup eingerichtet.
Lief sofort und die Backups liegen in der Dropbox

Vielleicht erstellst du mal eine neue App und generiest den Token aber wirklich erst nachdem du alle Einstellungen korrekt gesetzt hast.

[diwoma]

@simatec said in Test Adapter Backitup v2.3.x:

Ich habe aber gerade nach der Step by Step Anleitung aus der Doku eine neue App erstellt und in Backitup eingerichtet.
Lief sofort und die Backups liegen in der Dropbox
Vielleicht erstellst du mal eine neue App und generiest den Token aber wirklich erst nachdem du alle Einstellungen korrekt gesetzt hast.

Habe ich gemacht, neue App, alles eingestellt, Token generiert und geht trotzdem nicht.
Werde wohl am Slave auf Dropbox verzichten müssen?

[simatec]

@diwoma Ob Master oder Slave ist für Backitup egal.
Aber jetzt mal ne andere Frage… warum nimmst du nicht die APP vom Master? Brauchst doch nur einen Unterordner anlegen

[Siggi0904]

@simatec ich habe nun mysqldump über das Paket "mariadb-client-core-10.5" installiert.
Das ist das aktuell gültige Paket für Debian Bullseye. mysqldump verweist darin auf die Datei mariadbdump. Es ist also eigentlich alles bei Debian Bullseye auf MariaDB.

Der Backup-Lauf der MySQL-Datenbank lief auch sauber durch.
Was mir nur auffiel, dass die SQL-Datei im Archiv nicht benannt wird.
Im Archiv ist die Datei mit dem richtigen Inhalt vorhanden, hat nur keinen Namen und Endung.
Siehe:

Wo kann man im Backup-Adapter den Namen mitgeben?
Oder ist das ein genereller Bug, da auch die .sql Endung fehlt?

Danke.

[simatec]

@siggi0904 Das ist so gewollt ... Die Backudatei ist so korrekt und kann problemlos mit Backitup wiederhergestellt werden

[Siggi0904]

@simatec okay. Dank dir für die Info.

[diwoma]

@simatec
Das habe ich zuerst ja probiert, da hat es den Fehler dann gegeben.
Ich habe das dann auf eine geänderte API geschoben und gedacht, ich probiere es mit einer neuen App

[simatec]

@diwoma Ändere mal die Berechtigungen und speichere diese. Im Anschluss dann den Token neu generieren ... In meinen Test lief es immer ohne Probleme.