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

Previous Next

Full log

View this message in rfc822 format

From: Richard Sent <richard <at> freakingpenguin.com>
To: paul <goodoldpaul <at> autistici.org>
Cc: 71639 <at> debbugs.gnu.org
Subject: [bug#71639] [PATCHv2 0/5] Improve on restic-backup-service
Date: Wed, 26 Jun 2024 23:56:55 -0400

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!

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.