$RESTIC_REPOSITORY2 confusion

Features and Ideas
1

So I noticed that in the case of restic init --copy-chunker-params, $RESTIC_REPOSITORY2 is the SOURCE and $RESTIC_REPOSITORY is the TARGET. However, in the case of restic copy, $RESTIC_REPOSITORY2 is the TARGET, and $RESTIC_REPOSITORY is the SOURCE.

Am I the only one that finds this confusing? :sweat_smile:

I do have a feeling that I use restic copy a little backwards from everyone else, most likely. I think most people use it to copy from their main $RESTIC_REPOSITORY to an offsite / secondary $RESTIC_REPOSITORY2. I, however, tend to use it to copy from an intermediary repo $RESTIC_REPOSITORY2 to my main repo $RESTIC_REPOSITORY. The reason for this is, I occasionally backup offline devices, and have a fast SSD to do so - and it doesn’t make sense for me to take my main repository offline to hook up to the offline machine. So once it starts to fill, I dump it onto my main repo.

So, I don’t want to change the restic copy workflow, because I feel like I’m a fringe case for that. I would like to see init follow copy's logic, though. Does this make sense?

So if you wanted to copy chunker params, you know that $RESTIC_REPOSITORY2 is always a TARGET. So you’d copy params from $RESTIC_REPOSITORY to $RESTIC_REPOSITORY2 - not the other way around, as it currently is.

Luckily restic will not mess with an already initialized repo, else I’d be in trouble, because I totally got the logic messed up on this haha. Just wondering if I’m the only one that is confused by this, or if it makes sense to everybody else.

And with all that in mind, and the fact that we now have “version 2” repos… I’d also like to suggest $RESTIC_REPOSITORY2 be renamed to something like $REPOSITORY_TARGET or something a little clearer. Make sense??

2

Yes, the mismatch between init and copy has been observed before, such as:

Sounds as though they’re in a bit of a pickle, though, as to how to improve the situation without causing backward-compatibility issues.

1 Like
3

Ahh, should have known someone else would have pointed that one out by now haha. I just honestly hadn’t needed to copy the chunker params before cause I typically just copy “config” and “keys” into a new directory for my “temporary repos”.

That said, a big repository v2 upgrade might be just the time to nip this in the bud, especially considering “repo2” sounds a lot like “repo v2” :wink:

1 Like
4

The rationale has been that the --repo one is the “main” repository and the --repo2 is the “secondary” repository.

In the case of init, the main repository is the one you are focusing on, where you want the work to be done, in this case the one you’re initializing. The secondary one is the one which you are just picking some initialization parameters from.

In the case of copy, the main repository is the one you are copying, the one that has the stuff you are working with (the data, the backups). The secondary one is the one which you are putting the copy in.

This is not an argument or excuse, just an attempt at explaining the rationale.

1 Like
5

Yeah, I kind of get it. Perhaps for init, it would be better if --copy-chunker-params just took the repo path of the repo you want to copy from, to avoid the confusion?

6

Letting --copy-chunker-params won’t work as then we have no way to pass the repository password etc.

What would be possible is to replace --repo2 with a more sensible name like --repo-src / --from-repo / etc. The copy command would the use --repo as destination and the other one as source.

1 Like