When installing cockpit server-manger I notice it brings nethserver-backup-config, nethserver-backup-data, duplicity, restic, dav2fs, etc. as dependencies, even if the user doesn’t choose to install the backup module.
In the nethgui server-manger, the backup module appears as not installed (because restore part isn’t), but the backup menus are there. But that’s not the issue I want to point the finger to.
I guess this is done in order to have the backup options in cockpit UI. Having nethserver-backup-config serves its purpose, but I’m not sure bringing the other components make sense, and goes in detriment of modularity. If a user doesn’t want to use backups, and module is not installed, no reason to show it.
Is there a technical reason for that (,that cannot be solved in another way)?
I haven’t played at all with cockpit or its backup part, and therefore I’m not aware of the internals, so take my words with a grain of salt.
I do not have the full answer, but I know that the mind has changed with cockpit, I think we want less modularity and more simplicity for the end administrators. IIRC the backup was made with two rpm, one for backup and one for restore in nethgui, this is hard to understand.
Steph is right, it’s exactly what we are trying to achieve: basically the backup can be considered part of the core.
This is because are going to discontinue the nethserver-restore-package since it causes too many support requests hand has some serious limitation on big backups. We are searching for an alternative implementation but we didn’t find a valid solution, yet.
The only technical reason is to simplify the Cockpit API part, but this could be resolved with a little bit more code. The real reason is that we want the backup is installed and used by anyone is installing NS
We have seen to many scenarios where the backup wasn’t configured and the machine died for an hardware failure!
