Test Adapter ioBroker.backitup v3.1.x
-
@amg_666 Kannst du mal die Config der historyDB zeigen?
-
@einstein67 sagte in Test Adapter Backitup v2.3.x:
@simatec Gerade mal getestet:
Beim Restore kam beim Wiederherstellen von VIS-1.4.8 ein Fehler. (Ich muss den Versuch nochmal machen und die Fehlermeldung kopieren). Nach manueller installation des Adapters hat alles funktioniert.
Da schein ein problem mit VIS zu sein. Die Installation erfolgt ja nach dem restore.
Backup von Grafana funktioniert wieder aber beim Restore kommt leider:
Sehr gut ...
[DEBUG] [grafana] - Grafana dashboard restore not possible: TypeError: Cannot read property 'data' of undefinedDas bedeutet, dass deine Sourcequelle nicht lesbar ist. Eventuell mal die rechte prüfen. Hast du einen lokalen restore gemacht oder vom NAS oder irgendeiner Cloud?
Am besten mal lokal testen und die Rechte des Backupverzeichnisses prüfen.Das Statusfenster ist GENIAL, und funktioniert SUPER!
Danke dir ...
-
@simatec Hmm, da ist kein Speicherverzeichnis (mehr?) angegeben, ich hab den History eigentlich ewig nicht mehr angefasst:
-
@amg_666 Und was steht in Backitup für ein Pfad??
Backitup ist in version 2.3.0 nun strenger mit Fehlern.
Eventuell hast du es nie mitbekommen -
@simatec sagte in Test Adapter Backitup v2.3.x:
Pfad?
Bingo
Danke für den Hinweis, habe jetzt konsistente Pfade sowohl bei History als auch bei backitup eingetragen, jetzt läuft es durch. -
@simatec said in Test Adapter Backitup v2.3.x:
Das bedeutet, dass deine Sourcequelle nicht lesbar ist. Eventuell mal die rechte prüfen. Hast du einen lokalen restore gemacht oder vom NAS oder irgendeiner Cloud?
Es war ein Backup von einem Synology-NAS.
Hab dann schnell ein Downgrade auf BackitUp 2.2.3 gemacht und damit Grafana wiederhergestellt (problemlos funktioniert). Also sollten die Quelle oder die Rechte nicht das Problem sein.
Das Problem mit VIS hat sich mit Controler 4.0.8 erledigt. Restore läuft damit perfekt durch.
-
@einstein67 OK checke ich nochmal
-
Hallo zusammen,
Eine Frage bzgl. Backup Influxdb:
Wenn ich iobroker und influxdb in separaten Docker Containern laufen haben, dann kann ich influxdb zwar via Iobroker nutzen (influxdb Adapter ist grün und Daten werden erfasst), aber ein Backup ist nicht möglich, da der Haken im Backitup-Adapter nicht anwählbar ist.
Ich habe gelesen, dass auf dem System, auf welchem iobroker läuft auch influxdb installiert sein muss.
Das habe ich dann nachgeholt und im iobroker Container manuell influxdb installiert und gestartet (läuft).Leider ändert das nichts an dem "toten" Influxdb Button im Backitup Adapter
Mach da noch etwas falsch, habe ich evtl. etwas übersehen oder einen Denkfehler?
Oder kann ich so gar nicht influxdb sichern? -
@fila612 Also BackitUp sichert lokale sowie auch remote Influx-DBs. Hast du die Einstellungen im InfluxDB Reiter gemacht. Dann sollte die Checkbox auswählbar sein.
-
@einstein67 ,
ich war der Meinung das der Reiter erst auftaucht wenn ich den Haken gesetzt habe.
Und diesen Haken kann ich leider nicht auswählen:
Adapterversion BackitUp ist 2.3.0
-
@fila612 said in Test Adapter Backitup v2.3.x:
ich war der Meinung das der Reiter erst auftaucht wenn ich den Haken gesetzt habe.
Sorry, da hast du natürlich Recht! Hab ich in die falsche Richtung dedacht ....
-
@fila612 Das liegt dann wohl daran:
Nein aktuell nicht, da im Dockercontainer des iobroker kein influx laufen sollteHat simatec weiter oben geschrieben. Vielleicht ist es (für Docker-Container) deshalb nicht auswählbar.
-
Hallo,
ich habe mir eben eine Tabelle für meine Visualisierung gebaut um den Backupverlauf anzuzeigen.
Verwende für die Tabelle die json die der Adapter anlegt.
Dabei ist mir aufgefallen, dass er in der json unter errors immer none anzeigt. Auch wenn es einen gab (in meinem Fall war der ftp Speicher voll und das Backup konnte nicht kopiert werden.)
Ist das ein Bug oder bezieht sich die Ausgabe wirklich nur darauf, dass das Backup erfolgreich am Dateisystem angelegt wurde?
Würde gerne auch sehen, wenn ein Backup nicht zu Google, ftp etc gesichert werden konnte.
-
@david-g In Version 2.3.0 ist das Error Handling strikter
-
Sehr cool,
werde ich mal testen.
Ggf, kann man bei bei Sorge ja auch noch Leerstellen rein machen. Sieht was schöner aus als alles aneinander.
EDIT
Läuft die 2.3 soweit rund? -
@david-g sagte in Test Adapter Backitup v2.3.x:
Hallo,
ich habe mir eben eine Tabelle für meine Visualisierung gebaut um den Backupverlauf anzuzeigen.Hi, kannst du die hier mal posten, würde mich interessieren wie du das gelöst hast
-
War mal mutig und hab dir 2.3 installiert. Hoffe läuft soweit ^^.
In der json steht noch immer unter "errors" ein "none" , obwohl ftp fehlgeschlagen ist.Per Telegram kommt der Fehler über den Adapter.
So sieht sie bei mir aus. Allerdings ist immer alles grün, da eben die Info in der json noch fehlt. Sollte eigentlich rot werden bei Fehlern.
Für VIS muss man sie ggf was anpassen. Als Visu nutze ich Lovelace.
Die Buttons gehören nicht zur Tabelle.Das ist das Blockly:
-
Ab sofort steht die Version 2.3.1 im latest zur Verfügung.
Changelog
2.3.1 (2022-02-12)
- (simatec) Bugfix Grafana
- (simatec) Bugfix Restore for Docker System
- (simatec) Restore Interface with https Support
- (simatec) use iobroker SSL Certificates for https
-
@simatec Danke für das Update!
Grafana funktioniert perfekt!
Leider funktioniert bei mir das ioBroker-Restore (über http) nicht mehr. Das neue Restore Interface erscheint auch nicht mehr. Nur dieses Bild:
Im Log steht auch nicht viel drinnen. Iobroker ist nach dem Restore-Versuch gestoppt, kann wieder gestartet werden. Aber es läuft kein Restore.
2022-02-13 06:34:00.249 - info: host.iob14ig received SIGTERM 2022-02-13 06:34:00.251 - info: backitup.0 (11496) cleaned everything up... 2022-02-13 06:34:00.255 - info: admin.0 (11481) terminating http server on port 8081 2022-02-13 06:34:00.256 - info: host.iob14ig stopInstance system.adapter.admin.0 (force=false, process=true) 2022-02-13 06:34:00.257 - info: host.iob14ig stopInstance system.adapter.backitup.0 (force=false, process=true) 2022-02-13 06:34:00.271 - info: admin.0 (11481) Got terminate signal TERMINATE_YOURSELF 2022-02-13 06:34:00.272 - info: backitup.0 (11496) Got terminate signal TERMINATE_YOURSELF 2022-02-13 06:34:00.284 - info: host.iob14ig stopInstance system.adapter.admin.0 send kill signal 2022-02-13 06:34:00.287 - info: admin.0 (11481) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2022-02-13 06:34:00.287 - info: host.iob14ig stopInstance system.adapter.backitup.0 send kill signal 2022-02-13 06:34:00.322 - info: backitup.0 (11496) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2022-02-13 06:34:00.856 - info: host.iob14ig instance system.adapter.admin.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP) 2022-02-13 06:34:00.889 - info: host.iob14ig instance system.adapter.backitup.0 terminated with code 156 (START_IMMEDIATELY_AFTER_STOP) 2022-02-13 06:34:00.890 - info: host.iob14ig All instances are stopped. 2022-02-13 06:34:01.094 - info: host.iob14ig terminated ernst@iob14ig:~$ iob startHat das möglicherweise mit: "(simatec) Restore Interface with https Support" zu tun? Über "https" hab ich noch nicht getestet.
EDIT: Über "https" funktioniert das Restore wie früher
-
@einstein67 danke für den Hinweis. Hat sich bei der Einbindung der https Unterstützung ein Fehler eingeschlichen. Update kommt
