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

Hi all!

This is the previously promised [1] patch series relating to
restic-backup-service. The highlights:

1. init? was added that bootstraps a new backup.

2. RESTIC_PASSWORD_COMMAND support.

3. Add extra-packages field for jobs.

4. Move restic from restic-backup-job to restic-backup-configuration.

5. Add a basic system-level test suite.

Regarding 4, the previous way felt a bit orthogonal to how services of a
similar nature work. (For example, you don't specify an mcron package for
every job.) I can't think of a use case for mixing-and-matching restic
packages with different jobs. If there is a reason, I think a good compromise
would be a "restic-override" job field.

I'm marking this as WIP because there are a couple more things I want to
investigate, but it feels complete enough to submit for feedback. My main
point of interest is what can be done to improve support for Restic's other
backends, see [2]. I imagine 0.9.6 only supports a subset of those, but still.

In my dream world we could combine this patch with an upgrade to the restic
package itself (which, among other things, supports compression). I asked the
developers about (re)including a vendor directory in their tarball but haven't
heard back [3]. Perhaps this service can spark some action on an old Guix
tracking issue [4].

[1]: https://issues.guix.gnu.org/69513#7
[2]: https://restic.readthedocs.io/en/stable/030_preparing_a_new_repo.html
[3]: https://github.com/restic/restic/issues/3945#issuecomment-2141090355
[4]: https://issues.guix.gnu.org/63019

Richard Sent (5):
  services: backup: Support bootstrapping an initial restic backup
  services: backup: Add password-command support to restic-service
  services: backup: Add extra-packages field to restic-backup-job
  services: backup: Move restic package to restic-configuration
  tests: Add restic system test.

 doc/guix.texi           |  21 ++++++-
 gnu/services/backup.scm | 131 +++++++++++++++++++++++++++++-----------
 gnu/tests/restic.scm    | 124 +++++++++++++++++++++++++++++++++++++
 3 files changed, 238 insertions(+), 38 deletions(-)
 create mode 100644 gnu/tests/restic.scm


base-commit: a575d0f5d5322bac977423b6bd2742c8dc5a14a6
  

Hi Giacomo,

Thanks for adding the Restic Service to Guix.

Hi Richard,

Thanks for patch request 71639, which includes a few changes I'm looking
forward to. For instance, I like the idea of exposing the
'RESTIC_PASSWORD_COMMAND' variable directly via the service
configuration.

I think I might still be able to use the 'extra-flags' field to specify
a '--password-command' - if I understand it correctly - but direct
access to the option would be neat indeed.

Anything I can do to help with the patch? Could it make sense to break
the patch down into a couple of stages, possibly leaving the most
impactful changes for a later stage?

Thanks, cheers, Fabio.
  

Dear Fabio and Richard,

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.

After it gets in it should be sufficient to add "init" to 
%restic-guix-supported-actions to have a working restic-guix init 
invokation. it should be then matter of understanding where it is better 
to put it. 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. Please Richard let me know 
what you think of this approach and whether you would still be 
interested in implementing it, thank you very much!

I think the following subdivision should match all requirements we 
stated until now:

1. Improve the restic backup system service . This can be done in the 
current issue #71639:

services: backup: Add password-command support to restic-service
services: backup: Add extra-packages field to restic-backup-job
services: backup: Move restic package to restic-configuration

2. Refactor the restic-guix function to allow for more restic commands 
to be wrapped. This can be done in issue #72803:

services: restic-backup: Add more restic commands to the restic-guix 
package.

3. Allow for repositories to be initialized with a restic-guix init 
command. This commit could be adapted and moved to a new branch based on 
#72803:

services: backup: Support bootstrapping an initial restic backup

What do you think? Could this be a suitable action plan?

Thank you very much for your work,

giacomo


[0]: https://issues.guix.gnu.org/72803
  

> 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.

Hi Giacomo,

Thanks for this!

> 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 [...]

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.

I've just sent a quick follow-up to #63019 in the hope that we might be
able to get this sorted soon.

Thanks, cheers, Fabio.
  

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
  

Hi Richard and Giacomo.

> >> 1. Improve the restic backup system service [...]
[...]
> 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.

+1

> > 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.

> [1]: https://github.com/restic/restic/issues/3945

Thanks for the link to the Restic's issue tracker. I think it's actually
better to have the dependencies unbundled and built/imported
individually - although this is causing us some pain at the moment.

Some of the 'guix import go --recursive restic' errors seem to be caused
by Go projects using a slightly different subfolder scheme? There seem
to be various open issues (and semi-finalised patches) around this, such
as:

- https://issues.guix.gnu.org/issue/52362
- https://issues.guix.gnu.org/issue/63001
- https://issues.guix.gnu.org/issue/63647
- https://issues.guix.gnu.org/issue/64035
- https://issues.guix.gnu.org/issue/64036

I'll follow up on one of the threads above and report back here if I
find anything useful.

Thanks, cheers, Fabio.