mbox series

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

Message ID cover.1718747513.git.richard@freakingpenguin.com
Headers show
Series Improve on restic-backup-service | expand

Message

Richard Sent June 18, 2024, 10:06 p.m. UTC 
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

Comments

Richard Sent June 27, 2024, 3:56 a.m. UTC | #1 
Hi giacomo,

> I think it would be nice to have an init action for the restic-guix
> command shipped with the service and move there the logic for
> initializing repositories. The service then could be adapted in a way
> that it would call the restic-guix init before calling restic-guix
> backup. Would you be interested in implementing this?

I'll take a look at it and see what the code looks like. It might be a
bit of effort to get that working cleanly while avoiding code dupe. For
instance, setting RESTIC_PASSWORD(_COMMAND) in both init and backup
program actions.

Where do you think the appropriate place to check init? and run the init
action is if it's no longer encapsulated in the backup action? A
conditional in restic-backup-job->mcron-job before launching restic-guix
backup? A one-shot shepherd service?

The former will necessitate adding a job string to display when running
$ herd schedule mcron. A downside of the latter is if the restic
repository is deleted for one reason or another that backup job will
fail until the system is rebooted, which isn't immediately obvious.
Personally I prefer the mcron-job conditional.

> At last, my use case for having a restic package field for each job is 
> to have some critical jobs that I don't want to touch running with 
> Guix's bootstrapped restic package and some personal jobs that I run 
> with a restic 0.16 binary package I have in my personal channel . I'm 
> not sure this warrants a field in each single job, but they are optional 
> anyway. Anyway I wouldn't consider this a blocker and if the Guix 
> project has some guidelines in this sense I'd say follow them.

Ah, I see. To me this is where a per-job restic-override or similarly
named field makes sense. This way we can have a default "global" restic
package configured at a service level while still allowing individual
jobs to use a custom restic package. I imagine this restic-override
field would be a "maybe-file-like" either set to #f or a custom restic
package.

Thanks for the feedback!