Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[wendy2702]

@lemonbiter ich kenne den Backitup Adapter auch nicht aber kannst du mal das erste File in den Zigbee ordner kopieren und dann nochmal testen.

Bitte nach dem kopieren die Berechtigungen prüfen.

Sonst würde ich persönlich das probieren:

Zigbee Instanz stoppen
Im Adapter die beiden files suchen und sichern bzw. umbennen.
Die beiden Files aus dem Backup an deren Stelle kopieren, berechtigungen kontrollieren
Adapter starten und schauen ob es geklappt hat.

Ist aber nur ein Versuch.

[lemonbiter]

@wendy2702

Bömisches Dorf...Leider

a) welche BEIDEN Files...? Es gibt je Tag ja nur EIN Backup. Und in jedem Backup sind gaaanz viele Ordner (siehe Oben im Screenshot) und in jedem dieser Ordner sind exakt 2 Files...

Also die Rechte sind identisch.. das habe ich herausgefunden:

Wohin kopieren usw...
Wo liegt der Original Zigbee Adapter?
Tut mir leid... Ich kenne die Strukturen auf Unix nicht

[crunchip]

@lemonbiter die Daten liegen unter /opt/iobroker/iobroker-data/zigbee_0

[lemonbiter]

@crunchip

Das liegt da in meinem Ordner: /opt/iobroker/iobroker-data/
Es fehlt also der zigbee_0 obwohl ich ja einen neuen Zigbee Adapter installiert habe

[crunchip]

@lemonbiter der Ordner wird erst angelegt, wenn der Adapter funktioniert, nehme ich mal an

[lemonbiter]

@crunchip

so, habe den Ordner manuell angelegt:

Im Ordner sind nun diese beiden Dateien.

Ich habe die Rechte angepasst

danach hat er den backup...tar.gz automatisch angelegt

Adapter neu gestartet, bleibt gelb

[simatec]

@lemonbiter
Du solltest wirklich nicht soviel spielen.
Also erstmal in /opt/iobroker/backups den zigbee_0 Ordner löschen und im Anschluss dann den Restore ausführen.
Hast du den zigbee Adapter auf dem slave oder Master installiert? Denke daran, dass der Stick auch an diesem System stecken muss

[lemonbiter]

@simatec

Hallo Simatec...
Hast recht... es gab einen Grund den ich gerne mal erkläre..

also, ja, der Stick ist die TI Platine... steckt bzw. angeschlossen---
ich lösche den Ordner. Soll ich auch den Adapter löschen?

[simatec]

@lemonbiter
Nein keinen Adapter mehr löschen

[lemonbiter]

@simatec
Der Adapter ist auf dem Slave. Alles was ich hier geschrieben habe bezieht sich auf den Slave :-)

OK... Ordner ist gelöscht. Adapter ist auf Pause...

So sieht der Backup Ordner jetzt aus:

und so der ioBroker Data:

Backup einspielen siehe Fehler oben

Die Einstellungen der Zigbee Karte sind leer.

Wie also geht es nun weiter?

[simatec]

@lemonbiter
Versuchst du auch über die Slave Instanz von Backitup einzuspielen, oder vom Master?

[lemonbiter]

@simatec
Die vom Slave Adapter

[simatec]

@lemonbiter
Und was passiert beim restore?

[lemonbiter]

@simatec

Error: {"errno":-1,"code":"EPERM","syscall":"utime","path":"/opt/iobroker/backups/zigbee_0/"}

[burncolonia]

Hallo zusammen,

ich habe aktuell exakt das selbe Problem. Ich möchte von meinem alten Rechner mit Ubuntu auf eine neue VM (ESXi) auch Ubuntu umziehen. Habe alles gebackuped und wollte es nun auf der neuen VM wieder einspielen. iobroker klappt soweit auch nur wenn es dann an Jarvis, Influx, History oder Zigbee geht kommt der EPERM utime Fehler.

Ich habe auch festgestellt das der Ordner /opt/iobroker/backups "root" gehört. Ich bekomme das wenn der backitup Adapter läuft auch nicht geändert. Wenn ich Ihn stoppe kann ich es ändern, sobald ich ihn wieder starte gehört er wieder root. Ändere ich es dann nochmal geht es, sobald ich dann aber die Backups zu wiederherstellen einlese gehört er wieder root.

Langsam verzweifle ich dran ... aber schön das ich nicht alleine bin ... ;-)

[simatec]

@burncolonia
Von wo stellst du die Backups wieder her?

[burncolonia]

@simatec
Hi,

habe sowohl vom NAS (cifs) als auch von GoogleDrive probiert.

[simatec]

@burncolonia
Wenn du den mount vom NAS hast, ist root normal. Auf den Ordner /opt/iobroker/backups ist dann der mount
Welche Version nutzt du von Backitup?

[burncolonia]

@simatec

2.1.0

[simatec]

@burncolonia
Zeige doch bitte mal den Log