[bug#71639] [PATCH WIP 0/5] Improve on restic-backup-service

[Richard Sent <richard@freakingpenguin.com>]

Hi Giacomo and Fabio!

I've been struck by the the law of development: the backlog will always
expand to exceed the time available.

>> I apologize for blocking this issue with my proposal. I think Fabio's
>> proposal of splitting the changes in this patch is the best way
>> forward, if you agree as well Richard. I submitted [0] to refactor the
>> restic-guix procedure in a way that it can support many different
>> commands.

That sounds fine with me. I'll try to rebase and resubmit as time is
available (hopefully the next few days......). If my schedule is
inconvenient feel free to do with my patches what you will.

>> 1. Improve the restic backup system service [...]
>> 2. Refactor the restic-guix function [...]
>> 3. Allow for repositories to be initialized with a restic-guix init
>> [...]

Ideally, we'd also move the system tests to 1 so further work can be
trivially verified by running $ make check-system TESTS=restic. That'll
require writing an intermediary bootstrapping function in the test
suite.

> I think this is a perfectly sensible plan. For what it's worth, I've
> provided some little feedback around point 2 as part of #72803.
>
> As a further point, I also think we should manage to update Restic
> itself to 0.17.0 (while we're still at 0.9.6 which was released in Nov
> 2019). With such an out-of-date package, the service also risks to loose
> a little bit of its value.

That would be lovely! One particular feature I'm hopeful for is
compression support.

Unfortunately restic stopped providing a vendor directory in their
tarball after 0.9.6 and seemingly has no interest in providing it again
[1]. Last time I tried guix import with restic I saw some odd behavior.
Someone with more experience in Go may have better luck.

>> Lately I was thinking that may be best to have initialization as a
>> one shot Shepherd service that check whether a given job is supposed
>> to have its repository initialized and if that's the case it could
>> run restic-guix init name-of the job.

Is the intent to have one "mega" one-shot service that checks every job,
or a unique one-shot service per job? I greatly prefer the former as $
sudo herd status is crowded as it is.

It's worth noting users will need the ability to specify custom Shepherd
requirements so e.g. backup initialization to a remote file-share isn't
triggered until the file-system-/my/remote/nas symbol is provisioned by
Shepherd.

On an unrelated note, Shepherd timers are interesting and may allow for
better user management/error signaling instead of mcron. I'm not
proposing we refactor to use them now (especially since they're not even
in stable), but just thought I'd mention them. [2]

[1]: https://github.com/restic/restic/issues/3945
[2]: https://lists.gnu.org/archive/html/guix-devel/2024-03/msg00247.html

-- 
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.