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

[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?

[simatec]

@bbtown Backitup ist so konzipiert, dass bei einem Fehler im Backupprozess keine alten Backups gelöscht werden.
Im schlimmsten fall ignoriert ein User diesen Fehler über Wochen und hat durch das löschen kein funktionstüchtiges Backup mehr

[BBTown]

@simatec ich verstehe deinen Ansatz, etwas schade ist dabei nur, dass z.B. bei einem fehlgeschlagenen "CCU" Backup, die ioBroker Backups nicht aufgeräumt werden und somit ggf. eine Festplatte volläuft.

Schöner wäre es daher wenn es möglich wäre das einzugrenzen .... also in meinem Beispiel dann lediglich die CCU-Backups stehen zu lassen und nicht jene ohne Fehler.

Vielleicht läßt sich so etwas ja mit vertrebarem Aufwand beizeiten mal prüfen

[simatec]

@bbtown iobroker Backups und CCU Backups sind doch zwei völlig getrennte Backuptypen.
Schlägt dein iobroker Backup fehl, dann wird bei einem CCU Backup trotzdem gelöscht
Umgekehrt natürlich auch