Test Adapter ioBroker.backitup v3.0.x
-
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 -
@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!
-
@marc-berg Das Fenster schließt nach erfolgreichen Download automatisch
-
@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.
-
@marc-berg sehr komisch ... Chrome und Safari funktionieren auch
-
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" ? -
@aleks-83 Den Namen hast du als Namenzusatz in Backitup vergeben.
-
@simatec
blind...
-
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.. .
-
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. -
Das ist ja genau was ich vermeiden will…
-
@ilovegym
Das der Adapter dauerhaft rennt?ist das dein Kernthema,wenn ja dann müsstest du das via Script lösen.Warum eigentlich?
-
@ilovegym
zu a: ja muss er… Es gibt Dienste und Funktionen, die nicht als Schedule funktionieren.zu B: Ein Cronjob für Experten ist geplant
-
Ab sofort steht auf Github und in kürze im Latest die Version 2.10.2 zur Verfügung.
Changelog
2.10.2 (2024-01-14)
- (simatec) Cronjob for Expert Settings added
- (simatec) Code restructured
- (simatec) Translation added
2.10.1 (2024-01-09)
- (simatec) small Fixes
- (simatec) Code restructured
2.10.0 (2024-01-06)
- (simatec) File server improved
- (simatec) Restore Tab improved
- (simatec) Design improved
- (simatec) Docu updated
- (simatec) Breaking Changes for Docker mapping ports
