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

Copy Link

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)

### 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

Copy Link

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.

witten referenced this issue from a commit 2024-03-11 18:24:50 +00:00

When running the "rcreate" action and the repository already exists but with a different encryption mode than requested, error (#840).

witten commented 2024-03-11 18:25:21 +00:00

Owner

Copy Link

This is implemented in main and will be part of the next release. Thanks again for bringing this to my attention!

This is implemented in main and will be part of the next release. Thanks again for bringing this to my attention!

❤️ 1

witten closed this issue 2024-03-11 18:25:21 +00:00

witten commented 2024-03-11 20:30:51 +00:00

Owner

Copy Link

Released in borgmatic 1.8.9!

Released in borgmatic 1.8.9!

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.10

1.8.9

1.8.8

1.8.7

1.8.6

1.8.5

1.8.4

1.8.3

1.8.2

1.8.1

1.8.0

1.7.15

1.7.14

1.7.13

1.7.12

1.7.11

1.7.10

1.7.9

1.7.8

1.7.7

1.7.6

1.7.5

1.7.4

1.7.3

1.7.2

1.7.1

1.7.0

1.6.6

1.6.5

1.6.4

1.6.3

1.6.2

1.6.1

1.6.0

1.5.24

1.5.23

1.5.22

1.5.21

1.5.20

1.5.19

1.5.18

1.5.17

1.5.16

1.5.15

1.5.14

1.5.13

1.5.12

1.5.11

1.5.10

1.5.9

1.5.8

1.5.7

1.5.7.dev0

1.5.6

1.5.5

1.5.4

1.5.3

1.5.2

1.5.1

1.5.0

1.4.22

1.4.21

1.4.20

1.4.19

1.4.18

1.4.17

1.4.16

1.4.15

1.4.14

1.4.13

1.4.12

1.4.11

1.4.10

1.4.9

1.4.8

1.4.7

1.4.6

1.4.5

1.4.4

1.4.3

1.4.2

1.4.1

1.4.0

1.3.26

1.3.25

1.3.24

1.3.23

1.3.22

1.3.21

1.3.20

1.3.19

1.3.18

1.3.17

1.3.16

1.3.15

1.3.14

1.3.13

1.3.12

1.3.11

1.3.10

1.3.9

1.3.8

1.3.7

1.3.6

1.3.5

1.3.4

1.3.3

1.3.2

1.3.1

1.3.0

1.2.18

1.2.17

1.2.16

1.2.15

1.2.14

1.2.13

1.2.12

1.2.11

1.2.10

1.2.9

1.2.8

1.2.7

1.2.6

1.2.5

1.2.4

1.2.3

1.2.2

1.2.1

1.2.0

1.1.15

1.1.14

1.1.13

1.1.12

1.1.11

1.1.10

1.1.9

1.1.7

1.1.6

1.1.5

1.1.4

1.1.3

1.1.2

1.1.1

1.1.0

1.0.3

1.0.2

1.0.1

1.0.0

0.1.8

0.1.7

0.1.6

0.1.5

0.1.4

0.1.3

0.1.2

0.1.1

0.1.0

0.0.7

0.0.6

0.0.5

0.0.4

0.0.3

0.0.2

Labels

Clear labels   

bug

  

data loss

  

design finalized

  

good first issue

  

new feature area

  

question / support

  

security

  

waiting for response

No Label

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

Milestone

Clear milestone

No items

No Milestone

Assignees

Clear assignees

No Assignees

2 Participants

Notifications

Subscribe

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#840

No description provided.