Configuration file for restic: crestic

Features and Ideas
1

Hello everyone!

I’m used to backup my data hard drive to 3 different restic repositories (local and remote).

I’d like to automate this with configuration files, i.e. I’d like to have something similar to the ssh utility where you can just use ssh target to connect to the target using the options specified in a configuration file for that specific target.

The most similar thing that I found is crestic. (I am not the author)
The reference issue is #16.

I’d like to see crestic or a similar ssh-like approach integrated into restic.
What do you think?

1 Like
2

As you wrote and even linked to, there’s already an issue on GitHub that tracks this feature request.

3

Yeah, and the last comment in January was:

image
image751×222 21.5 KB

Since it hasn’t been done I did it, it seems there isn’t agreement and more discussion is needed

4

At this point in time I’d say more discussion isn’t needed, because we are already having a lot of other work to attend. When the time comes to add support for user-facing config files, there will be plenty of discussion if need be :slight_smile:

1 Like
5

Maybe move this thread to the recipes section where all the other restic wrappers have been introduced?

6

There is a fairly straightforward workaround. For a repository you want to call “foo,” create an executable file in /usr/local/bin named restic-foo with the following contents.

#!/bin/sh

export RESTIC_REPOSITORY=/path/to/foo/repository
export RESTIC_PASSWORD=secret

exec restic "$@"

You can set appropriate permissions so that only some users can read the password and execute the script.

Then you just invoke restic-foo instead of restic.

7

For people preferring to set up an alias:

alias restic-foo='RESTIC_REPOSITORY=/path-to/foo-repo RESTIC_PASSWORD=secret restic'

8

I just proposed a PR to get a restic-integrated solution using viper:

(but still WIP, though)

9

With all due respect, this isn’t helping. If you read the issue thread, 1) there is no concensus on which format to use, 2) viper has been mentioned several times, 3) the author has stated several times he’s not convinced about viper and would prefer to use another tool, 4) there are already several other branches referenced that attempts to solve the configuration file feature, 5) given that there are so many different suggestions and ways to do this it’s pretty reasonable that whatever the final decision is it should be @fd0’s.

So, with that in mind, I fail to see how filing a PR that “solves” the problem in a way that others have already suggested before, and that is certainly not the decided way forward, especially when there are already other work of similar type, will help the project. Especially when the maintainers are busy trying to focus on things that leads up to an actual release, it’s not like we’re going to (or at least should) sit down and tackle this thing all of a sudden. Not to mention posting about it in two places gets so much attention that we do have to sit down and spend time responding to it, time that would otherwise have been spent on things leading up to a release.

My point is that in this particular case it should be very clear that the issue being discussed is not ready for yet another PR. If I’m misinterpreting something in that assessment, please feel perfectly free to correct me, I am very open to being wrong or misunderstanding something, and I don’t want to come across as being ungrateful for your work, you have done a lot of great contributions to restic lately!