Test Adapter ioBroker.backitup v3.0.x
-
@hansjochen sagte in Test Adapter ioBroker.backitup v2.8.x:
@marc-berg
Die Umgebungsvariablen kommen doch an:root@iobroker:/opt/iobroker# env IOB_BACKITUP_EXTDB = true PACKAGES = influxdb2-cliMach mal die Leerzeichen weg. Weiß nicht ob das was bringt aber:
Dein docker-compose enthält:
environment: - USBDEVICES=/dev/ttyACM0 - DEVICE=/dev/ttyACM0 - IOB_BACKITUP_EXTDB = true - PACKAGES = influxdb2-cliAber laut log kommt nur USBDEVICES an. DEVICE gibt es nicht und bei den anderen beiden sind Leerzeichen drin.
-------------------------------------------------------------------------------- ----- Debugging information ----- ----- ----- ----- System ----- ----- arch: x86_64 ----- ----- hostname: iobroker ----- ----- ----- ----- Docker-Image ----- ----- image: v7.0.1 ----- ----- build: 2022-07-05T18:51:52+00:00 ----- ----- ----- ----- Versions ----- ----- node: v16.20.1 ----- ----- npm: 8.19.4 ----- ----- ----- ----- ENV ----- ----- SETGID: 1000 ----- ----- SETUID: 1000 ----- ----- USBDEVICES: /dev/ttyACM0 ----- --------------------------------------------------------------------------------Versuch mal so:
environment: - USBDEVICES=/dev/ttyACM0 - IOB_BACKITUP_EXTDB=true - PACKAGES=influxdb2-cliAlternativ mal sauber compose down, compose up... Damit der Container neu gebaut wird...
MfG,
André -
@andre sagte in Test Adapter ioBroker.backitup v2.8.x:
Weiß nicht ob das was bringt aber:
@HansJochen hatte (warum auch immer) das Image 7.0.1 am Start. Damit war das Setzen der Umgebungsvariablen sowieso für die Katz.
-
@marc-berg In der Tat!
Das habe ich glatt überlesen, bzw. habe ich wirklich v9.0.1 gelesen, was ja aktuell wäre.
Hätte mir aber auch spätestens bei node 16 komisch vorkommen müssen.
Naja, ich schiebe es mal darauf, dass heut Sonntag ist... -
Was für ein image 7.0.1 ist das denn eigentlich? Die Version bezieht sich doch auf das iobroker Image, oder? Ich habe jetzt ein docker-compose down und docker-compose up gemacht, aber es wird wieder diese Version gebaut. Die habe ich aber nirgends explizit angegeben.
Offenbar mache ich da fundamental was falsch.
Service Section sieht jetzt so aus:
services: iobroker: container_name: iobroker image: buanet/iobroker hostname: iobroker restart: unless-stopped ports: - "8081:8081" # IOBroker - "8082:8082" # Jarvis Web Port - "1882:1882" # MQTT Server des Shelly Adapters - "8400:8400" # Jarvis Socket Port volumes: - ./iobroker/data:/sharename - ./iobroker/userscripts:/opt/userscripts - /run/udev:/run/udev:ro devices: - /dev/serial/by-id/usb-dresden_elektronik_ingenieurtechnik_GmbH_ConBee_II_DE2437275-if00:/dev/ttyACM0 environment: - USBDEVICES=/dev/ttyACM0 - IOB_BACKITUP_EXTDB=true - PACKAGES=influxdb2-cli -
Alles klar, jetzt passt es. Selbst mit latest wurde bei mir 7.0.1 gebaut, warum auch immer. Ich habe jetzt explizit 8.0.0 reingeschrieben, das sieht freundlicher aus:
----- image: v8.0.0 ----- ----- build: 2023-04-07T23:45:19+00:00 ----- ----- node: v18.15.0 ----- ----- npm: 9.5.0 ----- ----- ----- ----- Environment Variables ----- ----- IOB_BACKITUP_EXTDB: true ----- ----- PACKAGES: influxdb2-cli ----- ----- SETGID: 1000 ----- ----- SETUID: 1000 ----- ----- USBDEVICES: /dev/ttyACM0 ----- -
@hansjochen
Nachlesen hilft https://hub.docker.com/r/buanet/iobroker
Stichpunktsupported tags
also eherlatest-v9 -
@hansjochen sagte in Test Adapter ioBroker.backitup v2.8.x:
ich habe jetzt ein docker-compose down und docker-compose up gemacht, aber es wird wieder diese Version gebaut.
Mit diesen Befehlen werden übrigens keine neuen Versionen heruntergeladen, sondern einfach die Container neu erstellt mit dem bereits heruntergeladenen Image (so denn das Tag noch das gleiche ist).
Du müsstest vorher noch
docker-compose pullausführen. In diesem Fall hätte Docker das aktuelle "latest" heruntergeladen. Das müsste im Moment die 9.0.1 sein.
-
@marc-berg und alle
vielen Dank für Eure Unterstützung. Dass es den pull braucht, wusste ich nicht. Ich habe mir gestern Abend explizit die latest-v9 gebaut. Damit lief es auf Anhieb sauber durch und auch die Backups funktionieren wieder. Da mir der docker-compose down auch die Influx und auch die Grafana DB gelöscht hat und ich die Influx danach händisch wieder hergestellt habe, bin ich dort jetzt damit am Ringen, die Verbindung zwischen den beiden wieder vernünftig hin zu bekommen. Ich schätze mal, dass da mit den Token auf Grafana-Seite etwas nicht passt. In der Diagramm Darstellung einzelner Objekte im IOBroker bekomme ich vollständige Charts auch über ein ganzes Jahr bis heute angezeigt, insofern sollte da jetzt eigentlich nichts verloren gehen. Denke, das werde ich gelöst bekommen.
-
@hansjochen sagte in Test Adapter ioBroker.backitup v2.8.x:
Da mir der docker-compose down auch die Influx und auch die Grafana DB gelöscht hat
Da hast du dann grundsätzlich was falsch angelegt, aber das wird hier endgültig off topic.
-
@hansjochen Bitte mache dafür einen separaten Thread auf. Das hat nix mehr mit Backitup zu tun
-
Ich bin fertig. Wollte ja nur mitteilen, dass die Backups jetzt wieder laufen.
-
Jetzt habe ich doch noch etwas gefunden, was ich für ein Backup Thema halte.
Der Influx Adapter hat eine Einstellung, wie lange die Daten aufgehoben werden sollen (S. 2, Standard Einstellungen, Storage Vorhaltezeit). Ich bin nicht sicher, ob es diese Einstellung früher schon gab oder die irgendwann reingekommen ist. Bei mir stand die auf "1 Jahr". Ich glaube aber nicht, dass ich die selbst so gesetzt hatte. Ich hatte ja über Jahre Daten in Influx gesammelt.
Im Zuge meiner Recovery Aktion jetzt habe ich meine IOBroker Installation über das Backup wiederhergestellt und dann mehrfach ein Backup meiner Influx Installation wiederhergestellt. Dabei bin ich ein paar Mal darüber gestolpert, dass nach der Wiederherstellung meine Daten im Influx zunächst vollständig waren, aber nach dem Verbinden mit IOBroker auf ein Jahr eingestutzt wurden - bis ich diese Option entdeckt habe.
Meine Vermutung ist, dass die Option im Influx Adapter irgendwann neu eingeführt wurde und dabei der Default auf "1 Jahr" gesetzt wurde. Das ist an der Stelle ja auch in Ordnung - wer den Adapter neu aufsetzt und konfiguriert, wird sicher alle Optionen durch schauen. Wenn man aber ein Backup wiederherstellt mit jahrelangem Datenbestand und diese Änderung nicht bemerkt, hat man nachher u. U. Datenverlust. Eine richtig gute Lösung dafür fällt mir ehrlich gesagt auch nicht ein. Den Parameter ungefragt zu ändern ist vielleicht auch nicht der beste Weg. Evtl. ein Warnhinweis?
-
@hansjochen sagte in Test Adapter ioBroker.backitup v2.8.x:
Den Parameter ungefragt zu ändern ist vielleicht auch nicht der beste Weg
Steile These. Abgesehen davon, dass dieses Thema nichts mit dem backitup-Adapter Thema zu tun hat (in dessen Thread wir uns hier befinden) stimmt deine Vermutung meines Erachtens auch nicht. Wenn du das Thema "Vorhaltezeit im Influxdb Adapter" diskutieren möchtest, mach' bitte einen neuen Thread auf.
-
Hallo @marc-berg ,
ich glaube, Du hast mich falsch verstanden und will hier sicher niemanden nerven. Ich bin nicht der Ansicht, dass das Backup etwas falsches wiederhergestellt hat, sondern eher, dass dieser vermutlich irgendwann neu eingeführte Parameter etwas unglücklich ist (der setzt eh' nur die Retention in Influx, das könnte man auch selbst in Influx setzen.).
Ich glaube aber, dass ein Benutzer, der eine Jahre alte IOBroker Instanz und einen Influx Datenbestand dazu am Ende eher nicht damit rechnet, dass nach der Wiederherstellung sein Datenbestand abgeschnitten wird - und das vielleicht auch nicht gleich bemerkt. Am Influx Adapter wird man da aber nichts ändern können, der ist ja so vermutlich schon seit längerem im Feld.
Daher war meine Überlegung, dass eine Warnung bei einer Recovery für andere Nutzer hilfreich sein könnte. Denn getriggert wird das Symptom m. E. erst durch das Wiederherstellen eines Backups mit Einstellungen im InfluxDB Adapter.
Ich werde aber ungefragt zu dem Thema hier nichts mehr schreiben. Wenn Ihr das nicht diskutieren wollt, respektiere ich das natürlich.
-
@hansjochen sagte in Test Adapter ioBroker.backitup v2.8.x:
sondern eher, dass dieser vermutlich irgendwann neu eingeführte Parameter etwas unglücklich ist (der setzt eh' nur die Retention in Influx, das könnte man auch selbst in Influx setzen.).
Das ist leider eine unbelegte (und falsche) Behauptung. Bereits die allererste Adapter Version, die InfluxDB 2.x unterstützt, hatte diesen Parameter schon und schon damals den Defaultwert von 1 Jahr.
Ich glaube aber, dass ein Benutzer, der eine Jahre alte IOBroker Instanz und einen Influx Datenbestand dazu am Ende eher nicht damit rechnet, dass nach der Wiederherstellung sein Datenbestand abgeschnitten wird und das vielleicht auch nicht gleich bemerkt
Auch das ist falsch. Wenn man eine ioBroker Instanz über Backitup wiederherstellt, werden die vorher definierten Vorhaltezeiten der (vorhandenen!) Instanzen 1:1 gesetzt, da greifen keine Defaults.
Daher war meine Überlegung, dass eine Warnung bei einer Recovery für andere Nutzer hilfreich sein könnte. Denn getriggert wird das Symptom m. E. erst durch das Wiederherstellen eines Backups mit Einstellungen im InfluxDB Adapter.
Es gibt ein Szenario, wie man in das von dir beschriebene Problem laufen kann: Man erstellt nach dem Restore manuell eine neue InfluxDB-Adapter-Instanz, die auf vorhandene Buckets zeigt. Dann, und nur dann greift das Default von (ja, diskussionswürdigen) 365 Tagen.
Ich werde aber ungefragt zu dem Thema hier nichts mehr schreiben. Wenn Ihr das nicht diskutieren wollt, respektiere ich das natürlich.
Ich hatte doch oben geschrieben, dass das Thema gern in einem neuen Thread diskutiert werden kann. Warum es nichts mit Backitup zu tun hat, habe ich (hoffentlich verständlich) argumentiert. Darum verstehe ich diese Reaktion jetzt überhaupt nicht.
-
Backitup ist ständig dabei sich weiterzuentwickeln und die Benutzerfreundlichkeit mehr und mehr voranzutreiben.
Aus diesem Grund gibt es wieder ein neues und wie ich finde sehr interessantes Feature, welches ab Version 2.9.2 verfügbar ist.
Jeder stand sicher schonmal vor dem Problem sein System neu aufzusetzen und musste mühsam erst per FTP auf das neue System und dort für einen Restore das Backup in den iobroker Backup Ordner schieben.
Die Umwege über Filezilla und Co. sind nun Geschichte.
Backitup baut auf Wunsch einen eigenen Fileserver auf und ihr könnt nun direkt über die Tab GUI eure Backups auf dem Host hochladen und im Anschluss einen Restore durchführen.Da dies aktuell im Beta ist, bitte ich euch die Funktion mal ausführlich zu testen.
Bitte testet vorallem, ob es sowohl per http als auch per https funktioniert (ist in Abhängigkeit eurer Einstellungen im Admin) und ob auch größere Files ordnungsgemäß hochgeladen werden.
Bitte testet auch, ob die Backup Files nach dem Upload nicht beschädigt sind.
Die Version 2.9.2 befindet sich aktuell im latest.
Danke für eure Unterstützung…
-
@simatec sagte in Test Adapter ioBroker.backitup v2.8.x:
Da dies aktuell im Beta ist, bitte ich euch die Funktion mal ausführlich zu testen.
Über welchen Port erfolgt der Upload? Ich frage für eine Docker-Umgebung ...
-
@marc-berg Der Port wird wie beim Download Server zufällig gesetzt und steht nur für den eigentlichen Upload zur Verfügung. D.h. es ist nicht dauerhaft aktiv
Docker ist hier sicher auch interessant zu testen, sollte aber ohne Port Mapping laufen.
-
@simatec sagte in Test Adapter ioBroker.backitup v2.8.x:
Der Port wird wie beim Download Server zufällig gesetzt und steht nur für den eigentlichen Upload zur Verfügung. D.h. es ist nicht dauerhaft aktiv
Genau das ist das Problem. Unter Docker funktioniert (im Bridge Netzwerk) weder Download noch jetzt der Upload. Da man vorher den Port nicht ahnen und einrichten kann.
-
@marc-berg Ab Version 2.9.3 ist der Fileserver Port für Downloads und Uploads im Docker auf 9081 festgelegt.
https://github.com/simatec/ioBroker.backitup/wiki/ioBroker.backitup-Wiki-Deutsch#docker-unterstützung
