UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Thomas Braun]

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

Und dann habe ich einen neuen gemeinsamen Ordner erstellt.

Mit den Leerzeichen drin? Das schreit auch nach Komplikationen.

[haselchen]

@thomas-braun

Nüscht Probleme.
Hab ein Backup aus dem Ordner zum Test schon eingespielt.

[Thomas Braun]

@haselchen

Ich wollt's nur sagen. Leerzeichen in Pfaden sind ein steter Quell für Trouble. Sollte man tunlichst vermeiden. Ebenso wie Umlaute oder sonstigen Sonderzeichenkram.

[haselchen]

@thomas-braun

Okay, zur Vorsicht kann ich den Ordner ja schnell umbenennen :)

[Siggi0904]

@simatec wäre es möglich den Adapter vom System-mysqldump unabhängig zu machen?
Wie denkst du darüber? Ich weiß nicht wie das unter Windows ist, aber das könnte einiges erleichtern.

Z.B. einige Wege siehe: https://stackoverflow.com/questions/30921435/nodejs-backup-mysql-database

oder:
https://www.npmjs.com/package/database-and-server-backup
https://www.npmjs.com/package/mysql-backup

[simatec]

@siggi0904 Naja am Ende dreht es sich bei dem ersten Link um genau die Methode von backitup.
Bei den möglichen NPM Paketen geht leider immer nur das erstellen des dumps und kein restore.

Aber was hast du für Probleme? mysqldump gibt es doch unter Windows

[Siggi0904]

@simatec Naja, ich suche noch immer die Resourcensparenste Methode für die Installation unter Debian Buster.

Ich weiß noch nicht, welches Paket unter Buster mysqldump mitbringt ohne zu viel overhaed.

Danke.

[Thomas Braun]

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

mysqldump

https://packages.debian.org/search?suite=buster&arch=any&mode=filename&searchon=contents&keywords=mysqldump

Ich würde mal sagen mysql-common dann.

[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 :angry:) 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 :confused:) oder liegt es am Adapter?

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

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