Are the systemd config files created for https://www.uyuni-project.org/uyuni-docs/en/uyuni/administration/backup-restore.html persistent across reboots and upgrades?

[ppanon2022]

Back in October, I'm pretty sure I created the /etc/systemd/system/server-db-backup.service and /etc/systemd/system/server-db-backup.timer files as indicated in the Uyuni backup and restore page. I had backups regularly moving/copying files to /var/spacewalk/db-backup. But that seems to have stopped after the latest upgrade to 2024.12 and I can no longer find those files. Is that directory and its contents correctly externally persisted? I had thought so since that page mentions running those command in the container context with mgrctl term, but I'm no longer sure. Since the container has no cron or other scheduling service, I want to create other custom scheduled tasks run by systemd timers but I need them to persist across reboots and upgrades so I don't have to keep on reinventing the wheel.

Also the OnCalendar line in the provided timer file example doesn't actually work.

uyuni-server:/etc/systemd/system # systemd-analyze verify /etc/systemd/system/server-db-backup.*
/etc/systemd/system/server-db-backup.timer:5: Failed to parse calendar specification, ignoring: Mo..Sun *-*-* 2:00:00
server-db-backup.timer: Timer unit lacks value setting. Refusing.
Unit server-db-backup.timer has a bad unit file setting.

OnCalendar=Mon..Sat --* 2:00:00
does work however.

OK, I think I've figured it out. I did create the systemd files in the host, not the container. However because the host is running MicroOS, the file changes must have gotten lost somehow. In addition to the OnCalendar= fix in the doc, some recommended corrections would be to add
some verbiage to explain that the creation of the files must be done with transactional-update shell active.

Finally, the transactional backups just keep building, so you've only moved your storage growth from the postgres db storage to the other container storage map, which doesn't really help that much. I think you want a second pair of service/timer files that only run an hour earlier on Sat (or maybe on every other Sat/1 or on the 1st day of the month) to delete all the contents of /var/spacewalk/db-backup, forcing the next backup to do a new full baseline backup.