Test Adapter ioBroker.backitup v3.1.x

[simatec]

@thomas-braun

[simatec]

Ab sofort steht die Version 2.3.2 auf Github und in Kürze auch im latest zur Verfügung.

Changelog

2.3.2 (2022-02-13)

• (simatec) Bugfix Restore Interface for http
• (simatec) Fix json history

[simatec]

@einstein67 Restore sollte via http und https in 2.3.2 wieder tun

[Einstein67]

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

Restore sollte via http und https in 2.3.2 wieder tun

Danke! Das werde ich testen

EDIT: Test war zu 100% erfolgreich!

Gesichtert habe ich: Iobroker, Influx, Grafana, Scripte und Zigbee

Wiederhergestellt: Grafana, Influx und Iobroker (mehr brauchst ja nicht)

... und hat alles perfekt funktioniert.

[crunchip]

@simatec bin gerade zwar erst von 2.3.0 auf 2.3.1, hatte jedoch diese Meldungen beim update
ich habe Hosttyp: single
Objects type: jsonl
States type: jsonl

2022-02-13 17:06:27.572 - info: backitup.0 (15941) Terminated (START_IMMEDIATELY_AFTER_STOP): Without reason
2022-02-13 17:06:28.086 - error: backitup.0 (15941) Connection is closed.
2022-02-13 17:06:28.089 - error: backitup.0 (15941) Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch().
2022-02-13 17:06:28.090 - error: backitup.0 (15941) unhandled promise rejection: States DB is not allowed to start in the current Multihost environment
2022-02-13 17:06:28.092 - error: backitup.0 (15941) Error: States DB is not allowed to start in the current Multihost environment
at Redis. (/opt/iobroker/node_modules/@iobroker/db-states-redis/lib/states/statesInRedisClient.js:579:23)
at processTicksAndRejections (internal/process/task_queues.js:95:5)
2022-02-13 17:06:28.093 - error: backitup.0 (15941) States DB is not allowed to start in the current Multihost environment
2022-02-13 17:06:33.341 - info: backitup.0 (16133) starting. Version 2.3.1 in /opt/iobroker/node_modules/iobroker.backitup, node: v14.19.0, js-controller: 4.0.8
2022-02-13 17:06:33.540 - info: backitup.0 (16133) [iobroker] backup was activated at 05:30 every 1 day(s)

[simatec]

@crunchip Welche js-controller Version läuft?

[crunchip]

@simatec 4.0.8

[simatec]

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

@simatec 4.0.8

Dann melde den Fehler mal bitte dort im Thread

[Josh]

@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 denied

Auf 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?

[simatec]

@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

[simatec]

@josh Die nächsten Tage kommt dazu ne Doku.
Im Moment ist 2.3.x noch Beta

[Josh]

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

[simatec]

@josh influx-cli muss in den iobroker
Im influx lxc stört sie aber auch nicht. Damit kannst du über cli Administrationen durchführen

[Thomas Braun]

@josh

Sauber installiert würden die hier liegen:

echad@chet:/opt/iobroker $ which influx influxd
/usr/bin/influx
/usr/bin/influxd

Paketnamen wären:

apt policy influxdb
influxdb         influxdb2        influxdb2-cli    influxdb-client  influxdb-python

[simatec]

@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

[Thomas Braun]

@simatec

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

InfluxDB-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.list

Nach einem abschließenden

sudo apt update

kann 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

[simatec]

@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

[Thomas Braun]

@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/status

Hinweis am Rande: Influxdb2 benötigt ein 64bit-Betriebssystem.

[crunchip]

@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

[apollon77]

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