`init --encryption X` should warn if existing repo uses different encryption #840

New issue

Closed

opened 2024-03-09 15:09:02 +00:00 by scy · 3 comments

scy commented

2024-03-09 15:09:02 +00:00

What I'm trying to do and why

I've noticed that init is designed to be a no-op if there already is a Borg repo at the given location. I don't want to debate that decision, as far as I could tell browsing these issues there has already been some discussion about it.

However, I'd argue that if I do init, I have to specify the repo's encryption, and therefore should be able to rely on this encryption setting to actually have been applied to the repo.

In other words, a successful run of init currently guarantees that there is now a repo at the target location, but it does not guarantee that it is actually using the encryption I have requested.

Steps to reproduce

Assume PATH is the path to a repository, but right now, there's nothing at that path (i.e. it's non-existent).
borgmatic init --encryption none PATH
There is now a repo without encryption at PATH.
borgmatic init --encryption repokey-blake2 PATH

Actual behavior

The repo at PATH is still not using encryption. However, the call to init returned successfully.

Expected behavior

If there already is an existing repo, init should check whether the requested settings correspond to what's actually set for the repo.
If not, these settings should be applied.
If that's not possible (for example, because you cannot change the encryption on an already existing repo), init should quit with an error status.

Other notes / implementation ideas

The basic reasoning behind this is that people are (rightfully, I think) expecting to be able to run init in a script and rely on a success status to mean that everything has been created as expected.

Note that I only tested this with borgmatic 1.7.7. If this has been already fixed in a more recent version, please disregard this issue, and sorry for the noise.

borgmatic version

1.7.7

borgmatic installation method

Debian package

Borg version

1.2.4

Python version

3.11.2

Database version (if applicable)

No response

Operating system and version

Debian GNU/Linux 12 (bookworm)

### What I'm trying to do and why I've noticed that `init` is designed to be a no-op if there already is a Borg repo at the given location. I don't want to debate that decision, as far as I could tell browsing these issues there has already been some discussion about it. However, I'd argue that if I do `init`, I have to specify the repo's encryption, and therefore should be able to rely on this encryption setting to actually have been applied to the repo. In other words, a successful run of `init` currently guarantees that there is now a repo at the target location, but it does _not_ guarantee that it is actually using the encryption I have requested. ### Steps to reproduce 1. Assume `PATH` is the path to a repository, but right now, there's nothing at that path (i.e. it's non-existent). 2. `borgmatic init --encryption none PATH` 3. There is now a repo without encryption at `PATH`. 4. `borgmatic init --encryption repokey-blake2 PATH` ### Actual behavior The repo at `PATH` is still not using encryption. However, the call to `init` returned successfully. ### Expected behavior * If there already is an existing repo, `init` should check whether the requested settings correspond to what's actually set for the repo. * If not, these settings should be applied. * If that's not possible (for example, because you cannot change the encryption on an already existing repo), `init` should quit with an error status. ### Other notes / implementation ideas The basic reasoning behind this is that people are (rightfully, I think) expecting to be able to run `init` in a script and rely on a success status to mean that everything has been created as expected. Note that I only tested this with borgmatic 1.7.7. If this has been already fixed in a more recent version, please disregard this issue, and sorry for the noise. ### borgmatic version 1.7.7 ### borgmatic installation method Debian package ### Borg version 1.2.4 ### Python version 3.11.2 ### Database version (if applicable) _No response_ ### Operating system and version Debian GNU/Linux 12 (bookworm)

witten commented

2024-03-09 17:21:42 +00:00

Owner

Thanks for taking the time to file this and for trying out borgmatic! I can confirm that this ask still applies to borgmatic 1.8.8 (the most recent release as of now).

If there already is an existing repo, init should check whether the requested settings correspond to what's actually set for the repo.

If not, these settings should be applied.

If that's not possible (for example, because you cannot change the encryption on an already existing repo), init should quit with an error status.

Yeah, Borg's init can't actually change the encryption on an existing repo, so borgmatic init in this scenario would have to error. Which seems like a reasonable thing to do... borgmatic could introspect the existing encryption mode via borgmatic info --json and compare it to the requested encryption mode.

However, other init flags like append-only mode and storage quota are not (to my knowledge) available by introspecting the repo, and so borgmatic would not be able to check for those.

Thanks for taking the time to file this and for trying out borgmatic! I can confirm that this ask still applies to borgmatic 1.8.8 (the most recent release as of now). > * If there already is an existing repo, init should check whether the requested settings correspond to what's actually set for the repo. > * If not, these settings should be applied. > * If that's not possible (for example, because you cannot change the encryption on an already existing repo), init should quit with an error status. Yeah, Borg's `init` can't actually change the encryption on an existing repo, so `borgmatic init` in this scenario would have to error. Which seems like a reasonable thing to do... borgmatic could introspect the existing encryption mode via `borgmatic info --json` and compare it to the requested encryption mode. However, other `init` flags like append-only mode and storage quota are not (to my knowledge) available by introspecting the repo, and so borgmatic would not be able to check for those.