Before I start with the idea itself, I’d like to set some context around it, and also thank the restic contributors!
As many others who have been let down by the CrashPlan closure I have been evaluating replacement tech for some time and after a few different tests I have settled on Restic. The main contender for me was Duplicati, but one big let down with Duplicati was the backup speed to B2 as it didn’t support multiple upload connections, and I had about a terabyte of data to upload… According to the developer it would have been a lot of work to implement the feature. Coming from CrashPlan, Duplicati was offering a similar feature set as you can setup multiple backup configurations from an easy-to-use UI, and no need to write your own cron jobs.
My use case is a linux workstation with lots of photos to backup as well as development files and other documents. I am also using restique (https://github.com/maxkueng/restique) to save out my configurations in a single file to help with running my backups from a single command line without any env vars to set for the various backups. I do have a few android phones that I’d like to add to the restic ecosystem and was happy to see restic work with termux.
I think restic would benefit from having a way to register backup configurations including schedules, and expose this functionality via a simple web interface such as the duplicati one (https://www.duplicati.com/screenshots).
I do understand that the current implementation stays well away from storing this kind of things, and I’m guessing that the main reason is security, having passwords stored in text files in one honey-pot location can be scary. I would still recommend allowing this feature to exist, the way restique wraps restic can only be stretched so far before it becomes a performance problem, and even worse security problem. As long as the features are opt-in I don’t think this would be an issue.
I have investigated the implementation details of having a web server and a long running daemon running as part of restic and it all seems fairly straightforward, the whole html structure being stored within the restic executable using rice.
The implementation would have to be staged though, first the configuration support and the long-running scheduler deamon would have to be implemented, then the UI, and it would be a non-negligeable amount of work. I would be happy to try to contribute on my little spare time to such an effort.