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

[HansJochen]

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?

[Marc Berg]

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

[HansJochen]

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.

[Marc Berg]

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

[simatec]

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…

[Marc Berg]

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

[simatec]

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

[Marc Berg]

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

[simatec]

@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

[Marc Berg]

@simatec sagte in Test Adapter ioBroker.backitup v2.8.x:

Ab Version 2.9.3 ist der Fileserver Port für Downloads und Uploads im Docker auf 9081 festgelegt.

Ja, das sieht schon gut aus, nur dass sich das Downloadfenster nach dem erfolgreichen Download bei mir nicht automatisch schließt. Sollte es das tun?

Ich werden morgen noch weiter testen. Vielen Dank schon mal!

[simatec]

@marc-berg Das Fenster schließt nach erfolgreichen Download automatisch

[Marc Berg]

@simatec sagte in Test Adapter ioBroker.backitup v2.8.x:

Das Fenster schließt nach erfolgreichen Download automatisch

Habe das jetzt nochmal auf einer VM nachgestellt. Mit Firefox schließt das Fenster nicht, aber mit dem Edge läuft es wie gedacht.

Firefox

Edge

[simatec]

@marc-berg sehr komisch ... Chrome und Safari funktionieren auch

[aleks-83]

Ich habe auf meinem alten Host (genannt "Tiny") ein Backup gemacht.
Dieses habe ich auf den neuen Host (genannt "Debian") eingespielt.

Alles hat super funktioniert.
Die Adapter wurden geladen, alle Einstellungen sind da.
Vis und Javascript läuft. Pefekt.

Eine Kleinigkeit ist mir aufgefallen.
Der alte Host hat täglich um 12:00 ein Backup gemacht.
Dieses hat er mir mit einer Telegram Nachricht bestätigt.

BackItUp:
Eine neue iobroker (Tiny) Sicherung wurde erstellt.
...

Wenn der neue Host jetzt eine Benachrichtigung zu einem Backup schickt, steht dort ebenfalls (Tiny).
Woher kommt das und wie kann ich das ändern?
Der offizielle Hostname ist "Debian". Woher kommt also das "Tiny" ?

[simatec]

@aleks-83 Den Namen hast du als Namenzusatz in Backitup vergeben.

[aleks-83]

@simatec
blind...

[A Former User]

@simatec

zwei Fragen...
a) muss der Adapter dauernd laufen, kann er nicht als Scheduled sein Task ausfuehren?
Damit waere es auch moeglich, mehrmals am Tag das Backup laufen zu lassen..

b) falls a) nicht so einfach geht, waere es moeglich, mehrere Backups am Tag zu planen?
Zur Zeit verwende ich ein Script um den Adapter mehrmals am Tag anzuwerfen.. aber wenn ich schon ein Script hab, dann kann auch gleich damit meine Backups machen und hin und her schieben.. ich hab ja n Adapter, um kein Script laufen zu haben..

Auf der Seite ist noch soviel Platz.. .

[bob der 1.]

@ilovegym

Mach dir ao viele Instanzen wie du brauchst,das ist simpel und du kannst endlos viele Backups ziehen.
Dazu noch ein Script das ein Backup auslöst wenn du zum bsp. dem Echso sagst....Backup ! und eins das du zb mit einer Fernbedinung von Ikea koppelst das du das per Tastendruck.machst,dann eins wenn dein Handy erkannt wird mir dem radar adapter....oder Fritzbox checkpresence..............für was man dem Backitup adapter alles missbrauchen kann.

[A Former User]

@bob-der-1

Das ist ja genau was ich vermeiden will…

[bob der 1.]

@ilovegym
Das der Adapter dauerhaft rennt?ist das dein Kernthema,wenn ja dann müsstest du das via Script lösen.

Warum eigentlich?