CUxD-Backup ungleich dem OpenCCU-Backup

[papi]

Ich muss heute einige Backups durchziehen, weil ich im blödesten Fall nun 120 Tage zurück muss.
Backups hatte ich als Großmeister der Redundanz zwar genug, aber alle unbrauchbar. (Das hat man davon, wenn man Backups nicht regelmäßig testet.)
Zum Glück habe ich auch noch einige Backups der Docker-Custom-Ordner, da kann ich mir die bordeigenen Backups der (Open-)CCU nun rausziehen und sehen, ob ich damit auskomme, ich hatte sie leider nur auf 5 stehen und mehr als 30 geht ja, wie ich gelesen habe, auch nicht.

Zunächst mal zu Deinem Skript:

Code: Alles auswählen

root@Homematic:~# tclsh /usr/local/addons/cuxd/extra/ccu_backup /mnt 2>&1
SBK-File: /mnt/Homematic-3.87.6.20260313-2026-03-31-0649.sbk

saving DOM... OK!
creating archive...
sign configuration with current key...
store current key index...
copy firmware version...
creating sha256 checksum of all files
creating /mnt/Homematic-3.87.6.20260313-2026-03-31-0649.sbk
clean up temp files...
root@Homematic:~#

Das Backup hat gepackt die gleiche Größe, wie das der CCU, allerdings fällt gleich auf, dass die Datei firmware_version größer ist, sie enthält gegenüber dem Original auch Angaben über Firmware und Plattform:

Code: Alles auswählen

VERSION=3.87.6.20260313
PRODUCT=rpi3
PLATFORM=rpi3

Die signature.sha256 ist jetzt wieder enthalten.
Sie ist etwas kleiner, als das Original, sie enthält die gleichen Keys, aber in anderer Reihenfolge und ohne vorauseilendes "./" bei der Bezeichnung derer.

Code: Alles auswählen

6ec415d22df28b487777ee443e092c7cc2c1aea221115ce9cfbe9861b294611c  ./firmware_version
4355a46b15d348dc2f57c046f8ef63d4538ebb936000f3c9ee954a27460dd865  ./key_index
9d3ae5afdf692d12a9e11971c0f8f6d9fdf11457b6e3f9c95feb750d26b9cedd  ./signature
640f39684e354c5f666af3138c1cd7442d3f2c87e7406a2cdbcc7ede710949f0  ./usr_local.tar.gz

Code: Alles auswählen

19f091ff0a51056e49bae47382003082adde65160ba73e8eb83b12b39b6f2532  usr_local.tar.gz
eea15483cdccae723767a3e1d45f49630c87e60b5e21f0aee08541077c8e3edc  signature
2a0bec7246f8475e7d15e87f378f174eccb2fedb7dd3d9a74482dee60168804f  firmware_version
4355a46b19d348dc2f56c046f8ef63d4538ebb976000f3c9ee954a27460dd865  key_index

Rein sachlich gemeinte Frage: Warum wird hier eigentlich nicht das bordeigene Backup genutzt/angestoßen?
Ist das nicht doppelte Datenpflege?

Ich werde im Tagesverlauf probieren, ob mir das Ding um die Ohren fliegt und weitere Meldung erstatten.
Danke Uwe!

[uwe111]

Backups hatte ich als Großmeister der Redundanz zwar genug, aber alle unbrauchbar. (Das hat man davon, wenn man Backups nicht regelmäßig testet.)

Also unbrauchbar sind sie nicht. Die sha256-Checksummen könnte man im Notfall auch nachträglich hinzurechnen. Oder Du packst die Archive manuell aus.

Rein sachlich gemeinte Frage: Warum wird hier eigentlich nicht das bordeigene Backup genutzt/angestoßen?

Das hatte ich in meinem letzten Beitrag auch vorgeschlagen.

Ich werde im Tagesverlauf probieren, ob mir das Ding um die Ohren fliegt und weitere Meldung erstatten.

Ja, prüfe mal bitte, ob sich das vom CUxD erzeugte Backup jetzt auf dem normalen Weg wieder einspielen lässt.

Viele Grüße

Uwe

[NickHM]

Naja, für original CCU3-Nutzer ist das weiterhin eine recht simple Möglichkeit Backups zu erstellen.
Oder ist es gar die einzige "einfache" Option abseits der WebUI bei einer CCU3?

Wenn ich das hier lese, frage ich mich ganz besorgt, ob meine mit ioBroker angelegten und an verschiedenen Orten gespeicherten automatischen Backups überhaupt brauchbar sind. Ich habe da grade ein ganz ungutes Gefühl

[papi]

Ich habe da grade ein ganz ungutes Gefühl

Erste Bürgerpflicht: Ruhe bewahren.
Uwe sagt ja, man kann die sha256-Checksummen im Notfall auch nachträglich hinzurechnen oder die Archive manuell auspacken.

Für mich ist der Zug leider jetzt abgefahren, da ich diese Backups mittlerweile alle schon gelöscht habe - neeee, Sekunde, davon habe ich auch ein Backup.
Ihr könnt mich ruhig für verrückt halten, aber das und mein mittlerweile halbes Tera an Log-Dateien hat mir schon sooo oft den Arsch gerettet...

[Xel66]

Darum praktiziere ich seit Jahren das Firmwareupdate über eine Reserve-SD mit einspielen eines aktuellen Backups. Reservekarte mit aktuellem Image flashen, Backup ziehen, CCU runterfahren, SD tauschen, CCU booten, Backup einspielen und Rebooten und ich habe den Nachweis, dass meine Backups funktionell sind. Vor und nach größeren Änderungen mache ich auch grundsäzlich manuelle Backups, sowie ab und zu mal ein zyklisches. Auf die Datenablage des USB-Sticks möchte ich mich auch nicht verlassen (und nein, auch nicht auf ein gemountetes Verzeichnis meines NAS). Die Klickerei fürs Update und automatische Backups sind ja schön und gut, aber ich verlasse mich da nicht zu 100% drauf. Man weiß ja nie.

... mein mittlerweile halbes Tera an Log-Dateien hat mir schon sooo oft den Arsch gerettet...

Ein halbes Terra an funktionierenden Backups wären jetzt aber dienlicher. SCNR. Mir hat mal ein (automatisch angelegtes) Backup auf dem angeschlossenen USB-Stick den Arsch gerettet, weil ich das manuelle Backup vor einer größeren Änderung "vergessen" hatte. Passt doch hervorragend zum heutigen World Backup Day.

Gruß Xel66

[papi]

Leider funktioniert es noch nicht (3.87.6.20260313):

Screenshot 2026-03-31 174205.png (7.11 KiB) 470 mal betrachtet

Gruß Michael

[NickHM]

Ich habe mal ein mit ioBroker automatisch heute morgen generiertes Backup genommen.
Zumindest bis zur Abfrage des System Sicherheitsschlüssels bin ich gekommen.
Weiter habe ich mich nicht getraut, da ich das Backup ja nicht wirklich einspielen wollte.
Kommt nach dem Sicherheitsschlüssel noch mal eine Abfrage?

[jmaus]

Andererseits, wenn man OpenCCU nutzt braucht man das CUxD-Backup Script doch gar nicht.

Genau so sehe ich das auch und mein Vorschlag an Uwe wäre da eher dahingehend das er diese uralte cuxd eigene Backupfunktion restlos entfernt. Das brauch man wirklich nicht mehr.

Das sehe ich aus Gründen der Abwärtskompatibilität leider nicht so. Es sei denn wir bauen einen Wrapper, der über den alten Aufruf mit Umsetzung der Parameter die neue Funktion aufruft.

Anbei das angepasste ccu_backup zum Testen (auspacken und Script auf der CCU ersetzen). Ich würde mich über Rückmeldungen freuen.

Ich würde in der Tat auch dafür plädieren das man da einen wrapper einbaut der bei existenz der /bin/createBackup.sh diese stattdessen aufruft und das Backup damit generiert wird. Denn dieses Shell-Skript gibt es bei jeder RaspberryMatic und OpenCCU und generiert am schluss eine sbk Datei die 1:1 mit der kompatibel ist die die OpenCCU-eigene WebUI auch generiert. Und wenn es dieses skript gibt sollte das "ccu_backup" skript am besten einfach dieses aufrufen und nicht selbst versuchen das sbk zusammenzubauen, denn das kann sich mitunter ändern.

[uwe111]

Leider funktioniert es noch nicht (3.87.6.20260313):

Kannst Du es bitte nochmal mit der neuen Version testen?

[papi]

Code: Alles auswählen

root@ccu:~# tclsh /usr/local/addons/cuxd/extra/ccu_backup /mnt 2>&1
SBK-File: /mnt/ccu-3.87.6.20260313-2026-04-01-0756.sbk

exec /bin/createBackup.sh ccu-3.87.6.20260313-2026-04-01-0756.sbk
root@ccu:~#

Es stirbt recht früh weg, würde ich sagen.

Aaaber - wenn es das systemeigene Backup /bin/createBackup.sh nicht findet, erstellt es ein funktionsfähiges Backup, das auch dieselbe Größe hat, wie das Bordeigene.

Und wenn Du das von mir unverschämterweise angepasste Skript hier im Anhang nimmst, funktioniert mit Deinem Skript auch das bordeigene Backup, vor allem an einem gewünschten Ort mit Schreibrechten ($BACKUPDIR).

Code: Alles auswählen

root@Homematic:~# tclsh /usr/local/addons/cuxd/extra/ccu_backup /mnt 2>&1
SBK-File: /mnt/Homematic-3.87.6.20260313-2026-04-01-0831.sbk

exec /bin/createBackup.sh Homematic-3.87.6.20260313-2026-04-01-0831.sbk
Externes Backup erfolgreich abgeschlossen.

Dabei fällt mir ein - der geneigte HM-User will das Backup wohl lieber als Download im Browser vor die Füße gelegt bekommen, da müsste noch ne Anpassung her.