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

[dontobi]

Ich bin gerade etwas verwirrt. Bei mir klappt das Backup nicht mehr.

Ich nutze für den ioBroker den Docker Container und habe einen Pfad in den Container gemountet. Auf der Console des Containers kann ich als ioBroker Nutzer Dateien innerhalb dieses Ordners löschen und erstellen.

Im ioBroker habe ich ein Backup angestoßen und erhalte den folgenden Output:

Started ccu ...
[DEBUG] [mount] - done
[DEBUG] [ccu] - CCU-Backup started ...
[DEBUG] [ccu] - CCU Version: 3.61.7
[DEBUG] [ccu] - Requesting backup from CCU
[DEBUG] [ccu] - CCU-Backup for is finish
[DEBUG] [ccu] - done
[ERROR] [cifs] - Path "/mnt/backitup/iobroker" not found

Ich stelle mir die Frage, warum hier CIFS genutzt wird und nicht COPY. Kann es sein, dass dies ein Bug ist? Ich habe kurz auch auf CIFS gestellt und direkt wieder zu COPY geändert. Aber die Ausgabe bleibt die selbe.

Hat jemand eine Idee, was ich noch testen könnte?

[simatec]

@dontobi Ehrlich gesagt verstehe ich deine Frage nicht.
Kannst du bitte mal deine Konfiguration posten und sagen, was jetzt nicht geht oder nicht mehr geht

[haselchen]

@dontobi

Habe ich auch gehabt.
Ich hab ums verrecken kein Backup in einen spezifizierten Ordner bringen können.
Iobroker läuft auf ner Syno.
Entweder permission denied oder dein Fehler.
Passwörter und Brechtigungen stimmen alle.
Kann auch so von aussen auf die Syno zugreifen.

Mach das ganze jetzt per FTP. Das klappt.

Edit: Wenn du Hilfe bei den Einstellungen brauchst, sach Bescheid.

[Dr. Bakterius]

@dontobi Kannst du die Freigabe händisch mounten?

[dontobi]

@haselchen Ich habe mir nun damit geholfen, dass ich die Backups per WebDAV zu meiner nextcloud Instanz schiebe und diese von dort auf einen Lokalen Speicher synchronisiere.

@dr-bakterius Da der ioBroker km Docker Container läuft, wird der Ordner automatisch beim starten in den Container verbunden (per Volume Bind). Ich habe daher per Console mich in den Container verbunden und dort Tests durchgeführt. Ordner und Dateien erstellen, sowie löschen klappt ohne Probleme als User (ioBroker) und auch per sudo. Daran kann es also nicht liegen.

[JB_Sullivan]

Moin zusammen,
ich muss mal eine ganz blöde Frage stellen, bevor ich mir jetzt gleich alles zerschieße.

Also BackitUp liegt als Komplett Sicherung für ioB, InfluxDB, Grafana, und die js-Skripte vor. Dieses Backup beruht auf einer ioB Windows Installation.

Nun habe ich mir einen NUC mit Proxmox und einer Linux VM für ioB aufgebaut. Auch InfluxDB und Grafana laufen auf dieser neuen Maschine in eigenen Containern.

Kann ich bedenkenlos die BackitUp Sicherung des Windows basierenden Systems als Restore Daten für die Linux Version nehmen? Bei InfluxDB und Grafana werde ich nach dem Restore die IP Adressen anpassen müssen, das ist mir soweit klar.

Ich frage deshalb so doof, weil ich ein ähnliches Szenario vor geraumer Zeit schon einmal auf zwei verschiedenen Windows Rechner ausprobiert hatte. Nach dem Restore auf dem neuen Windows Rechner ging jedoch gar nichts mehr und ioB war nicht mehr erreichbar.

Diesen Fehler würde ich mir jetzt gerne ersparen.

[simatec]

@jb_sullivan
Im Prinzip kannst du einen Restore auf ein anderes System ohne Probleme machen.
Wo ich aber immer drauf achten würde, wäre auf die Datenbanken.

Um nicht in Probleme zu laufen, sollten diese auf beiden Systemen identisch sein.
Wenn du also auf deinem Windows jsonl/jsonl hast, dann sollte auf deinem neuen System zum Zeitpunkt des Restores ebenfalls der Typ verwendet werden. Genau so auch mit File oder Redis

[diwoma]

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?

[JB_Sullivan]

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

@jb_sullivan
Im Prinzip kannst du einen Restore auf ein anderes System ohne Probleme machen.
Wo ich aber immer drauf achten würde, wäre auf die Datenbanken.

Um nicht in Probleme zu laufen, sollten diese auf beiden Systemen identisch sein.
Wenn du also auf deinem Windows jsonl/jsonl hast, dann sollte auf deinem neuen System zum Zeitpunkt des Restores ebenfalls der Typ verwendet werden. Genau so auch mit File oder Redis

Hmm - Schade, hätte ja klappen können :disappointed: Leider hat es schon mit dem Restore des Javaskript Backup mit Fehlermeldungen angefangen.

Error: {"errno":-13,"code":"EACCES","syscall":"open","path":"/opt/iobroker/backups/tmpScripts/script.json"}

Unter Windows heißt der Pfad nämlich c:\iobroker\GLT\backups\ vermutlich wird beim "Migartions" Backup von Win10 zu Linux versucht genau in diesen Pfad zurück zu sichern - oder was hat es mit der Meldung auf sich?

Die eigentliche ioB Sicherung habe ich jetzt noch gar nicht angefasst.

[simatec]

@jb_sullivan Das kann nicht passen.
Backitup ermittelt den Pfad aus dem System und nicht hardcoded.
D.h. /opt/iobroker/backups stehen nirgends im Code definiert
Erstelle mal ein Javascript Backup und versuche dies mal wiederherzustellen.

Bitte poste auch mal den kompletten Debuglog

[qqolli]

@haselchen
Hi,

ich habe ähnliche Probleme und komme auch nicht mehr weiter, leider. Ich speichere das ganze ebenfalls auf einer Symo, aber mit der Rechtevergabe habe ich schon vieles ausprobiert, aber nichts geht wirklich.

Könntest Du mir Deine FTP-Einstellungen auf der Syno und dem Adapter geben?

[haselchen]

@qqolli

Huhu,

hier meine Einstellungen

IP der Synology
dann Anmeldedaten (so wie du dich auf der GUI anmelden würdest)

Und dann habe ich einen neuen gemeinsamen Ordner erstellt.

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