DietPi-Backup | Add checkbox menu to include/exclude services from being stopped

[MichaIng]

A whiptails submenu to select/deselect those services which would be by default stopped during the backup (and restarted afterwards).

[disconn3ct]

This just stopped octoprint mid-print without warning. I think its a proper bug, not just a feature.

[Joulinar]

actually, this is working as it was designed. Therefore we are planning to add this feature.

[MichaIng]

Ideas:

• Dedicated dietpi-services CLI option to call a simplified include/exclude checkbox menu with clear description.
• New dietpi-backup menu entry which opens above checkbox menu, and which makes clear that (most) services are stopped by default.

[disconn3ct]

I would like to hear more about the design behind "stop services without warning during an unrelated activity." Are there any other designs in the system like that? Will it reboot when I change my password, for example?

[MichaIng]

I would not exactly call a full system backup unrelated: It backs up each and every file, and you do not want to have inconsistencies between them. It could be even seen as reasonable to remount all affected filesystem R/O, to assure to have a singular snapshot. Of course there are more or less problematic files in this regards. When backing up database file A while the database server runs and touches file B or the iblog, it will be simply broken, i.e. restoring the backup will render your database server unable to start, requiring complicated manual recovery steps.

It however makes sense to inform users about this. There was a hint on the Help dialogue already, but I added one to the confirmation dialogue: f1eb0ee

I understand the frustration when a time and resource consuming 3D print is aborted, and cannot be resumed where it stopped, I guess. A list of which services are safe to keep running or even destructive to stop, keeping up the right balance, is however difficult to maintain for our small team. A meaningful prominent menu to select/deselect it should be best we can do.

Will it reboot when I change my password, for example?

No, the only automated reboot that every happens is done during first run setup, if the APT "dist-upgrade" upgrades the kernel and modules for the currently loaded kernel are hence removed.

[disconn3ct]

It could be even seen as reasonable to remount all affected filesystem R/O

Absolutely agree, if we are discussing backups circa 2005. Everything else in my lab is taking backups at various intervals and this is the only one that randomly shot a bunch of services to do it.

Your db example is outdated; you don't back up a modern database by dumping the live files, and as you pointed out, trying to do so is likely to silently fail. Modern filesystems support snapshots, and DBs have various live, native backups that ensure consistency. (Even back in the old days, you dumped a db live by starting a transaction and doing a dump, or by asking the backend to do basically the same, or by asking the backend to quiesce the files and then taking a snapshot.)

Manually trying to emulate single-user mode because there might be a snowflake installed is overkill. (Also, maybe a separate bug, but this is the sort of thing that single-user runlevel was traditionally used for. Drop down, do the stuff, then pop back up. All system services are handled, not just the ones DietPi knows about.)

It however makes sense to inform users about this. There was a hint on the Help dialogue already, but I added one to the confirmation dialogue: f1eb0ee

🎉 👍 I think the phrasing is still a little weak when the impact is more like "shut down the system" and less like "can't add/remove packages" but its definitely better, and eventually the checklist.