Test Adapter ioBroker.backitup v3.0.x
-
@simatec 4.0.8
-
@crunchip sagte in Test Adapter Backitup v2.3.x:
@simatec 4.0.8
Dann melde den Fehler mal bitte dort im Thread
-
@simatec Also jetzt ist bei mir die Verwirrung komplett.
Was muss wo installiert oder eingetragen sein? Nochmal zur Erinnerung: Die InfluxDB2 läuft bei mir nicht in ioBroker, sondern in einem separaten Container.
Welcher Pfad wäre der richtige? Hier das Ergebnis meiner Versuche:
Pfad leer lassen = not found
Pfad "/usr/local/bin/influx" eintragen = not found
Pfad "/var/lib/influxdb" = permission deniedAuf welchem System muss die Influx-cli installiert sein? ioBroker-Installation oder Influx-Installation?
Auf welchem System muss der User iobroker der Gruppe influxdb zugeordnet werden?
In der Anleitung finde ich folgende Infos:
Um ein InfluxDB Backup ausführen zu können, muss Influxd auf dem iobroker-System installiert sein. Hierbei ist es egal, ob die Datenbank lokal verwaltet wird oder auf einen anderen Server läuft.Auf meinem ioBroker-System finde ich keine Influxd-Datei. Wo soll die denn sein?
-
@josh wenn bei /usr/local/bin/influx not found kommt, dann hast du bei der Installation etwas falsch gemacht. Prüfe mal ob dort im Pfad was liegt
-
@josh Die nächsten Tage kommt dazu ne Doku.
Im Moment ist 2.3.x noch Beta -
@simatec sagte in Test Adapter Backitup v2.3.x:
@josh wenn bei /usr/local/bin/influx not found kommt, dann hast du bei der Installation etwas falsch gemacht. Prüfe mal ob dort im Pfad was liegt
Auf welchem System muss da was im Pfad liegen? ioBroker oder Influx-LXC?
EDIT:
Ich habe die influx-cli im Influx-LXC installiert. Da ist in dem Pfad auch was drin. Aber in der ioBroker-Installation nicht.Ggf. warte ich auch noch bis zum Release bzw. bis die Doku fertig ist.
-
@josh influx-cli muss in den iobroker
Im influx lxc stört sie aber auch nicht. Damit kannst du über cli Administrationen durchführen -
Sauber installiert würden die hier liegen:
echad@chet:/opt/iobroker $ which influx influxd /usr/bin/influx /usr/bin/influxdPaketnamen wären:
apt policy influxdb influxdb influxdb2 influxdb2-cli influxdb-client influxdb-python -
@thomas-braun Poste mal bitte ne kleine Anleitung, wie de User an die aktuelle Repo kommen und dann mit apt install das ganze sauber installieren können.
Die offizielle Doku von influx ist ja da nicht aktuell
-
Grafana-Repo:
sudo apt-get install -y apt-transport-https sudo apt-get install -y software-properties-common wget wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee -a /etc/apt/sources.list.d/grafana.listInfluxDB-Repo:
sudo apt update sudo apt install -y gnupg2 curl wget wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add - echo "deb https://repos.influxdata.com/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/influxdb.listNach einem abschließenden
sudo apt updatekann dann wie üblich per Paketmanager apt die Software installiert werden.
Nach Wahl:
sudo apt install grafana sudo apt install influxdb influxdb-cli sudo apt install influxdb2 -
@thomas-braun
Also ist auch die aktuelle Repo für influx 2 gültig
Dann schreibe ich mal die nächsten Tage ne Doku für Backitup -
@simatec sagte in Test Adapter Backitup v2.3.x:
Also ist auch die aktuelle Repo für influx 2 gültig
Ja, liegt beides im gleichen Repo:
echad@chet:/opt/iobroker $ apt policy influxdb influxdb2 influxdb: Installed: (none) Candidate: 1.8.10-1 Version table: 1.8.10-1 500 500 https://repos.influxdata.com/debian bullseye/stable arm64 Packages 100 /var/lib/dpkg/status 1.6.7~rc0-1+b5 500 500 http://deb.debian.org/debian bullseye/main arm64 Packages influxdb2: Installed: (none) Candidate: 2.1.1 Version table: 2.1.1 500 500 https://repos.influxdata.com/debian bullseye/stable arm64 Packages 100 /var/lib/dpkg/statusHinweis am Rande: Influxdb2 benötigt ein 64bit-Betriebssystem.
-
@simatec heute update von 2.3.1 auf 2.3.2, mit controller 4.0.9
jetzt wird die config angemeckert und wieder redis server, "meta"...
an der Konfig wurde nichts geändert, sollte so passen und funktioniert auch alles, gesichert wird- iobroker
- javascript
- zigbee
- history
- jarvis
per ftp und nas
2022-02-14 11:29:26.273 - info: backitup.0 (12087) Got terminate signal TERMINATE_YOURSELF 2022-02-14 11:29:26.296 - info: backitup.0 (12087) cleaned everything up... 2022-02-14 11:29:26.298 - info: backitup.0 (12087) terminating 2022-02-14 11:29:26.300 - info: backitup.0 (12087) Terminated (ADAPTER_REQUESTED_TERMINATION): Without reason 2022-02-14 11:30:50.769 - info: backitup.0 (30267) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason 2022-02-14 11:30:51.339 - warn: backitup.0 (30267) Unable to subscribe to evicted Keyspace events from Redis Server: Connection is closed. 2022-02-14 11:30:51.342 - warn: backitup.0 (30267) Unable to subscribe to meta namespace "meta." changes: Connection is closed. 2022-02-14 11:30:51.349 - warn: backitup.0 (30267) redis get system.adapter.backitup.0.alive, error - Connection is closed. 2022-02-14 11:30:51.353 - warn: backitup.0 (30267) redis get system.adapter.backitup.0.sigKill, error - Connection is closed. 2022-02-14 11:30:51.369 - error: backitup.0 (30267) backitup.0 invalid config 2022-02-14 11:30:57.054 - info: backitup.0 (30278) starting. Version 2.3.2 in /opt/iobroker/node_modules/iobroker.backitup, node: v14.19.0, js-controller: 4.0.9 2022-02-14 11:30:57.241 - info: backitup.0 (30278) [iobroker] backup was activated at 05:30 every 1 day(s)nach einem Neustart der Instanz kommt kein Fehler mehr
-
@crunchip Ich mal wieder ... bitte mehr Log von davor ... irgendwie sind da ZWEI backitup Instanzen mit verschiednen prozess IDs ... Um zu sehen was da los ist braucht es bitte mehr log von davor. Sie aus als ob da eine Instanz gestartet wurd die sehr früh wieder gekillt wurde bzw die DB Verbindung weg war.
PS: Es wäre echt cool wenn du für die Controller Beta Tests den Host mindestens auf Loglevel info stellen könntest, sonst raten wir uns nen Wolf
EDIT2: Also am Ende scheint es wohl an sich ok zu sein ... Einmal wurde instanz beendet (wegen dem Update nehme ich an), controller hat Sie neu gestartet. Dann ist irgendwas komisches passiert und die Verbindung zur DB ist gekillt worden (was hattest du? Redis oder jsonl?) Deswegen ist der Adapterstart auf Fehler gelazfen und wurde danach vom Controller neu gestartet was dann tat.
-
@apollon77 bin jetzt unterwegs, komm erst spät abend wieder nach hause.
Mehr log gibts nicht, siehe js controller Thread, die host logstufe steht auf 'warn' ( werde ich fürs nächste mal zurück auf info stellen)
Die letzten drei backitup Updates machten Probleme seit js controller v4, alle anderen updates funktionieren.
Ich verwende jsonl, und das auch schon vor controller v4.
ich hatte auch redis sicher in der Instanz deaktiviert, da die config angemeckert wurde. -
@simatec @thomas-braun Habe die influx-cli nun über den Paketmanager im ioBroker Container installiert und den Pfad zur DB leer gelassen. Läuft jetzt bei mir.
Vielen Dank für die Unterstützung.
-
@apollon77 @simatec habe jetzt host auf info und bin mit backitup zum Test zurück auf 2.3.1 und anschließend wieder hoch auf 2.3.2
downgrade
upgrade
-
@crunchip alles klar. Hab ne Idee. Das Info log war glaube ich Sehr hilfreich
Info: Der Backitup wird gestioppt beim update, dann aber direkt nach dem npm update neu gestartet , dann kommt der "upload" schritt vom Update und der startet dann nochmal neu ... das ist bei dir zu schnell. AN Sich sollte der eine start auch später sein. Sollte bald (laufe heute/heute abend) in der 4.0.10 vom controller gefixt sein
-
Ab sofort steht die Version 2.3.3 auf Github und in kürze auch im latest zur Verfügung.
Changelog
2.3.3 (2022-02-17)
- (simatec) small GUI fixes
- (simatec) Docker restore tunning
-
Ab sofort steht die Version 2.3.4 auf Github und in Kürze auch im latest zur Verfügung.
Changelog
2.3.4 (2022-02-26)
- (simatec) Redis Remote Backup for Docker added
- (simatec) Docu updated
Des Weiteren wurde die Doku für die Version 2.3.x aktualisiert.
Bitte bei Einrichtungsproblemen die Doku lesen.
