Test Adapter ioBroker.backitup v3.1.x

simatec

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

Changelog

2.1.3 (22.04.2021)

(simatec) Admin-Tab changed
(simatec) Javascript Restore changed
(simatec) Redesign Admin-Tab
(simatec) Redesign Config
(simatec) Preparation for admin 5

SBorg

@simatec Die Tage bei einem Restore festgestellt + feature request: Projekte unter NodeRED (default Pfad: .../iobroker-data/node-red/projects )

simatec

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

Changelog

2.1.4 (26.04.2021)

(simatec) Redesign Restore GUI
(simatec) small GUI Bugfix

PatrickFro

"Auf diesem Host wurde keine zigbee-Instanz gefunden. Bitte überprüfen Sie Ihr System" wird mir bei jedem Aufruf des Backitup-Adapters angezeigt, wobei ich sogar 2 zigbee-Instanzen habe.

Ein Backup wird auch für Zigbee angelegt, für Zigbee.1, nicht jedoch für Zigbee.0.

simatec

@patrickfro Nutzt du Multihost?

PatrickFro

Genau, nutze ich. Raspi im Keller mit Javascript.1 und zigbee.0 sowie NUC in der Wohnung mit Javascript.0 und zigbee.1

simatec

@patrickfro sagte in Test Adapter Backitup v2.1.x:

Raspi im Keller mit Javascript.1 und zigbee.0

Darum kommt die Warnung. Ein zigbee.0 Backup des Slaves kann auf dem Master nicht durchgeführt werden, da der Master kein Zugriff auf das Filesystem vom Slave hat.
Also sinnvoll wäre eine 2. Instanz für den Slave

PatrickFro

Naja, auf dem Raspi ist bisher so wenig drauf, dass ich mich noch gegen eine eigene Instanz entschieden habe. Klar wäre sie besser.

Aber weshalb kommt auf dem NUC, auf dem die Instanz ist, beim Aufrufen des Adapters die Fehlermeldung? Das ist für mich unlogisch, denn eine Zigbee-Instanz gibt es auf dem NUC.

Meister Mopper

@simatec sagte in Test Adapter Backitup v2.1.x:

Also sinnvoll wäre eine 2. Instanz für den Slave

Da habe ich ein Verständnisproblem:

Ich muss ja dann auf dem Slave auch ein ioBroker-Backup aktivieren, um Zigbee zu sichern.

Inwieweit beinflusst das ein ioBroker-Backup des Masters?

simatec

@patrickfro sagte in Test Adapter Backitup v2.1.x:

Das ist für mich unlogisch, denn eine Zigbee-Instanz gibt es auf dem NUC.

Es gibt eine Zigbee Instanz auf dem NUC, aber auch eine auf dem PI. Backitup prüft alle Instanzen. Ist eine nicht auf dem Host, auf dem Backitup läuft, kommt die Warnung.
Es ist keine Fehlermeldung, sondern eine Warnung

simatec

@meister-mopper sagte in Test Adapter Backitup v2.1.x:

Ich muss ja dann auf dem Slave auch ein ioBroker-Backup aktivieren, um Zigbee zu sichern.
Inwieweit beinflusst das ein ioBroker-Backup des Masters?

Die beeinflussen sich nicht. Trotzdem ist es ratsam, die Backups nicht zeitgleich auszuführen.
Wir arbeiten an einer Lösung, dass auch der Master die Files vom Slave sichern kann.
Aber das wird noch eine Zeit dauern

Allerdings wird auch dann eine Instanz auf dem Slave benötigt.
Diese wird dann aber mit der Instanz auf dem Master kommunizieren ...
So ist auf jeden Fall der grobe Plan.

Meister Mopper

@simatec
Danke, ok, ich teste das einmal.

Ich hatte die Befürchtung, dass das Backup des Slave das des Masters überschreibt. Das wäre fatal.

simatec

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

Changelog

2.1.5 (29.04.2021)

(simatec) Bugfix AdminTab
(simatec) small Bugfix

Dr. Bakterius

Mal eine Frage zum Backup der Skripte:

Wenn ich die 'javascripts_*.tar.gz' mit WinRAR öffne, gibt es darin eine Menge Dateien die sich lediglich 'PaxHeader' nennen. Auch einen leeren Ordner mit dem Namen gibt es.

Liegt das an WinRAR oder passt da etwas mit Backitup nicht?

simatec

@dr-bakterius Nimm mal bitte 7zip

Bibo*13

@simatec Leider geht das auch nicht mit 7zip. Hab ich gerade mit erschrecken festgestellt

ente34

@dr-bakterius sagte in Test Adapter Backitup v2.1.x:

Liegt das an WinRAR oder passt da etwas mit Backitup nicht?

Die meisten Windows Packer können mit den (Posix-)Paxheaders nicht umgehen
s.a hier

Dr. Bakterius

@ente34 Danke, nach einem Update von WinRAR passt das jetzt.

crunchip

@simatec mit dieser Version hatte ich heute Nacht ne Meldung, zuvor mit v.2.1.3 lief noch alles, hab ich etwas übersehen/vergessen einzustellen?

Your backup was not completely created. Please check the errors!!

redis: Error: ENOENT: no such file or directory, lstat '/opt/iobroker/backups/redistmp/temp-693.rdb'

hab nachgesehen, ein Verzeichnis redistmp wurde erstellt, auf der Backup Platte, das jedoch leer ist
redis_2021_04_30-05_31_18_backupiobroker.tar.gz wurde nach wie vor erfolgreich erstellt
Verzeichnis /opt/iobroker/backups ist leer

bin noch auf
js-controller v3.2.16
admin v4.2.1
jsonl in verwendung

BBTown

@simatec mir ist folgendes aufgefallen (womöglich ist das Verhalten auch bereits bekannt??)

Von jetzt auf gleich wurden meine "überzähligen" ioBroker Backups nicht mehr automatisch gelöscht.

Dann erinnerte ich mich daran, dass ich Einstellungen geändert hatte (zusätzlich InfluxDB sichern, Scripte sichern, Grafana sichern) und hierbei ganz offensichtlich aber nicht alle geforderten Angaben hinterlegt habe.
Entsprechend wurden diese zusätzlichen Backups gar nicht durchgeführt.

Dieser "Fehler" hatte jedoch zugleich zur Folge, dass der "Löschvorgang" der weiterhin korrekt ausgeführten ioBroker Backups, nicht mehr abgearbeitet wurde (womöglich weil das erst zum Schluss erfolgen soll?).
Nachdem ich diese "zusätzlichen Backups" wieder deaktiviert habe, wurde der Löschvorgang zumindest wieder wie zuvor korrekt durchgeführt.

Vielleicht könnte man das ganze dahingehend optimieren, dass eine fehlerhafte/unvollständige Konfiguration einer Teilkomponente keinen Einfluss auf die anderen Backup-Prozesse hat?

NEWS