Just upgraded from OpenHABian 4.2.3 on RPI4 / bullseye to OpenHABian 4.2.3 / x64 / bookworm.
The complicated stuff ran like a charm. Up and running in half a day.
Now I am stuck with something stupid which actually should never go wrong: openhab-cli backup.
On the console, I entered sudo openhab-cli backup --full like I did a thousand times before. And then I got this:
Using '/etc/openhab' as conf folder...
Using '/var/lib/openhab' as userdata folder...
Using '/usr/share/openhab/runtime' as runtime folder...
including cache
Using '/var/lib/openhab/backups' as backup folder...
Writing to '/var/lib/openhab/backups/openhab-backup-24_11_29-15_29_15.zip'...
Making Temporary Directory if it is not already there
Using /tmp/openhab/backup as TempDir
#########################################
openHAB backup script
#########################################
Copying configuration to temporary folder...
Removing unnecessary files...
Zipping folder...
zip warning: No such file or directory
zip warning: No such file or directory
zip warning: No such file or directory
zip warning: No such file or directory
zip warning: No such file or directory
zip failed to store a backup.
…all of this with a resulting zip file which looks fine, actually.
I could imagine this having something to do with the fact that I symlinked stuff in the persistence folders for even further reducing SD card load, but I am not sure - especially as I had this exactly the same on the bullseye system without any errors.
What does openhab-cli backup --full actually execute, is there a way to know so I can find out what is failing?
Thanks for your quick reply, I could find out more immediately!
Zip exists and r/w permissions are okay (despite the error messages, a consistent and seemingly complete backup archive is actually created!)
It directly has to do with the symlinks. If I change zip -qr "$OutputFile" to zip -qry "$OutputFile", there are no more errors and the resulting zip archive contains the original symlinks instead of resolving them and having copies of the files there (which is what the -y option is supposed to do)
I would now guess that the errors come at the time when the temp folder is being cleaned up after the actual zip operation (that’s why the archive is okay). Don’t know why it did not happen with the bullseye version - either slight behavior change of certain components, or maybe I created the symlinks differently…
Well, finally, this leads me to one question:
I would guess that putting frequently changed files into ZRAM and symlinking them to their original locations where whatever application expects them is a general way to mitigate SD card wear. Of course on your own risk that they might be corrupted on e.g. power fail, but well.
So maybe it would be worth thinking about having the possibility of backing up and restoring the actual symlinks with the backup funktion - may it be permanently adding the -y option to the zip command, or (even better) as a command line option,
e.g. sudo openhab-cli backup --full --symlinks
Should I create a ticket / feature request in GIT?