NEWS
Test Adapter ioBroker.backitup v3.0.x
-
@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
-
Könntest du diese Meldung
According to the Backitup settings, backups are currently stored in the same local file system that is the source of the backup.
optional machen?
Ich sichere ganz bewusst nach /opt/iobroker/backups. Der Komplette LXC wird über PBS alle X Stunden gesichert. Bei einem ggf. notwendigen Restore habe ich entweder ein funktionales Backup des LXC oder dann direkt an der richtigen Stelle die Backups des Adapter liegen. Für alle Fälle wird auch über ein rsync Skript der /opt/iobroker/backups noch auf einen Fileserver synchronisiert.
-
Ab sofort steht die Version 2.10.6 auf Github und in der latest Repo zur Verfügung.
Changelog
2.10.6 (2024-01-27)
- (simatec) Gulp deleted
- (simatec) adapter-dev added
- (simatec) Translation added
- (simatec) Customised design
- (simatec) Hover info added to the Restore tab
- (simatec) Improved mobile view
- (simatec) dependencies updated
2.10.5 (2024-01-22)
- (simatec) Fix CCU Backup with selfsigned Certificates
2.10.4 (2024-01-21)
- (simatec) Fix CCU Backup
2.10.3 (2024-01-19)
- (simatec) CCU backup switched from request to axios
- (simatec) Sentry fix
-
ich glaub ich bin hier richtig oder
[DEBUG] [grafana] - Start Grafana Backup ... [DEBUG] [grafana] - Created grafana_tmp directory: "/opt/iobroker/backups/grafana_tmp" [DEBUG] [grafana] - Created dashboard directory [DEBUG] [grafana] - Created dashboards_manually_restore directory [DEBUG] [grafana] - Created datasource directory [DEBUG] [grafana] - start Grafana request ... [DEBUG] [grafana] - Grafana is available ... Status: 200 [ERROR] [grafana] - Error on Grafana Datasource Request [DEBUG] [grafana] - found Dashboard: device-list [DEBUG] [grafana] - found Dashboard: strom-copy-2 [DEBUG] [grafana] - found Dashboard: hydro [DEBUG] [grafana] - found Dashboard: strom-copy [DEBUG] [grafana] - found Dashboard: strom [DEBUG] [grafana] - found Dashboard: production-overview [DEBUG] [grafana] - found Dashboard: verbraucher [DEBUG] [grafana] - found Dashboard: keller-sensoren [DEBUG] [grafana] - start Grafana backup compress ... [DEBUG] [grafana] - Try deleting the Grafana tmp directory: "/opt/iobroker/backups/grafana_tmp" [DEBUG] [grafana] - Grafana tmp directory "/opt/iobroker/backups/grafana_tmp" successfully deleted [ERROR] [grafana] - cannot found Grafana Backup files [DEBUG] [grafana] - done
Am Key scheint es nicht zu liegen, denn wenn ich da absichtlich was anderes eintrage, dann kommen meine Dashboards nicht mehr
[ERROR] [grafana] - Error on Grafana Datasource Request [ERROR] [grafana] - Error on Grafana Dashoard Request: AxiosError: Request failed with status code 401 [DEBUG] [grafana] - start Grafana backup compress ...
Ich hab bisher noch nie Grafana Daten gesichert, das Update ist also nicht schuld
Der Token hat kein Ablauf Datum, und hat die Rechte Admin.
Hab bisher nur Influx, Iobroker und die Javas gesichert, dachte mit, das sicher von Grafana kann nicht schaden