Read BORG_RELOCATED_REPO_ACCESS_IS_OK environment variable #707

New Issue

Closed

opened 2023-05-30 18:05:08 +00:00 by hrv231 · 4 comments

hrv231 commented 2023-05-30 18:05:08 +00:00

Copy Link

What I'm trying to do and why

Running borg check or borg check --repair to a repository that has been moved location recently.

Steps to reproduce (if a bug)

docker run
-d
--name='borgmatic'
--net='bridge'
-e TZ="America/Los_Angeles"
-e HOST_CONTAINERNAME="borgmatic"
-e 'TZ'='America/Los_Angeles'
-e 'BORG_RELOCATED_REPO_ACCESS_IS_OK'='yes'

Actual behavior (if a bug)

/mnt/borg-repository/borg_backup/repo1: Listing archives
Warning: The repository at location /mnt/borg-repository/borg_backup/repo1 was previously located at /mnt/borg-repository/repo1
Do you want to continue? [yN] no (from BORG_RELOCATED_REPO_ACCESS_IS_OK)
Aborting.
Repository access aborted

Expected behavior (if a bug)

/ # borg list /mnt/borg-repository/borg_backup/repo1
Enter passphrase for key /mnt/borg-repository/borg_backup/repo1:
Warning: The repository at location /mnt/borg-repository/borg_backup/repo1 was previously located at /mnt/borg-repository/repo1
Do you want to continue? [yN] yes (from BORG_RELOCATED_REPO_ACCESS_IS_OK)
repo1-2022-11-30T18:15:00 Wed, 2022-11-30 18:15:27
repo1-2022-12-31T18:15:00 Sat, 2022-12-31 18:15:14
repo1-2023-01-31T18:15:01 Tue, 2023-01-31 18:15:15

Other notes / implementation ideas

When running borgmatic check, borgmatic is not able to read the BORG_RELOCATED_REPO_ACCESS_IS_OK environment and automatically type "no" for me, however borg does read and execute it properly.

I think there has to be a way for borgmatic to read that environment the same way as borg is able to do so.

I tested this with borgmatic 1.7.9 and 1.7.13; borg 1.2.3 and 1.2.4 both are able to detect 'BORG_RELOCATED_REPO_ACCESS_IS_OK'='yes' properly.

To know more about it: https://github.com/borgbackup/borg/issues/1426#issuecomment-236919222

Environment

borgmatic version: [1.7.13]

borgmatic installation method: [Docker container]

Borg version: [1.2.4]

Python version: [3.11.2]

#### What I'm trying to do and why Running *borg check* or *borg check --repair* to a repository that has been moved location recently. #### Steps to reproduce (if a bug) docker run -d --name='borgmatic' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_CONTAINERNAME="borgmatic" -e 'TZ'='America/Los_Angeles' -e 'BORG_RELOCATED_REPO_ACCESS_IS_OK'='yes' #### Actual behavior (if a bug) /mnt/borg-repository/borg_backup/repo1: Listing archives Warning: The repository at location /mnt/borg-repository/borg_backup/repo1 was previously located at /mnt/borg-repository/repo1 Do you want to continue? [yN] **no** (from BORG_RELOCATED_REPO_ACCESS_IS_OK) Aborting. Repository access aborted #### Expected behavior (if a bug) / # borg list /mnt/borg-repository/borg_backup/repo1 Enter passphrase for key /mnt/borg-repository/borg_backup/repo1: Warning: The repository at location /mnt/borg-repository/borg_backup/repo1 was previously located at /mnt/borg-repository/repo1 Do you want to continue? [yN] **yes** (from BORG_RELOCATED_REPO_ACCESS_IS_OK) repo1-2022-11-30T18:15:00 Wed, 2022-11-30 18:15:27 repo1-2022-12-31T18:15:00 Sat, 2022-12-31 18:15:14 repo1-2023-01-31T18:15:01 Tue, 2023-01-31 18:15:15 #### Other notes / implementation ideas When running *borgmatic check*, borgmatic is not able to read the BORG_RELOCATED_REPO_ACCESS_IS_OK environment and automatically type "no" for me, however *borg* does read and execute it properly. I think there has to be a way for borgmatic to read that environment the same way as borg is able to do so. I tested this with borgmatic 1.7.9 and 1.7.13; borg 1.2.3 and 1.2.4 both are able to detect 'BORG_RELOCATED_REPO_ACCESS_IS_OK'='yes' properly. To know more about it: https://github.com/borgbackup/borg/issues/1426#issuecomment-236919222 #### Environment **borgmatic version:** [1.7.13] **borgmatic installation method:** [Docker container] **Borg version:** [1.2.4] **Python version:** [3.11.2]

s1shed commented 2023-05-30 18:24:26 +00:00

Contributor

Copy Link

I've not used the docker image, but for what it's worth there's an option for this in the borgmatic configuration file

    # Bypass Borg error about a repository that has been moved.
    # Defaults to false.
    # relocated_repo_access_is_ok: true

You can probably override the configuration in the command line invocation instead for a one-off: https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#configuration-overrides

I've not used the docker image, but for what it's worth there's an option for this in the borgmatic [configuration file](https://torsion.org/borgmatic/docs/reference/configuration/) ``` # Bypass Borg error about a repository that has been moved. # Defaults to false. # relocated_repo_access_is_ok: true ``` You can probably override the configuration in the command line invocation instead for a one-off: https://torsion.org/borgmatic/docs/how-to/make-per-application-backups/#configuration-overrides

witten commented 2023-05-30 18:59:36 +00:00

Owner

Copy Link

Thanks for filing this! Seems like a reasonable feature request. But yeah, you can use the existing configuration option in the meantime as @s1shed points out.

Thanks for filing this! Seems like a reasonable feature request. But yeah, you can use the existing configuration option in the meantime as @s1shed points out.

witten changed title from borgmatic is not able to read some of borg options to Read BORG_RELOCATED_REPO_ACCESS_IS_OK environment variable 2023-05-30 19:00:21 +00:00

witten commented 2023-05-30 20:00:53 +00:00

Owner

Copy Link

For anyone looking to implement this: I'd recommend keeping the existing configuration option, but then if the BORG_RELOCATED_REPO_ACCESS_IS_OK environment variable is set, use that to override that config option. There's also the separate BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK environment variable / unknown_unencrypted_repo_access_is_ok config option, which would be nice to roll into this work.

The changes in question would likely go into borgmatic/borg/environment.py:make_environment().

For anyone looking to implement this: I'd recommend keeping the existing configuration option, but then if the `BORG_RELOCATED_REPO_ACCESS_IS_OK` environment variable is set, use that to override that config option. There's also the separate `BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK` environment variable / `unknown_unencrypted_repo_access_is_ok` config option, which would be nice to roll into this work. The changes in question would likely go into `borgmatic/borg/environment.py:make_environment()`.

witten added the

design finalized

good first issue

labels 2023-05-30 20:01:06 +00:00

witten commented 2024-01-24 22:30:18 +00:00

Owner

Copy Link

So I just checked this with the most recent borgmatic release, and setting the BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK environment variable does cause borgmatic to pass that variable through to Borg as long as the relocated_repo_access_is_ok option isn't set in borgmatic's configuration file. If the relocated_repo_access_is_ok option is set, then that overrides the environment variable. That actually seems like the right precedence to me, so I'm going to call this "done" for now. But if you have other feedback and/or have issues getting this working, please do let me know.

So I just checked this with the most recent borgmatic release, and setting the BORG_UNKNOWN_UNENCRYPTED_REPO_ACCESS_IS_OK environment variable _does_ cause borgmatic to pass that variable through to Borg as long as the `relocated_repo_access_is_ok` option isn't set in borgmatic's configuration file. If the `relocated_repo_access_is_ok` option is set, then that overrides the environment variable. That actually seems like the right precedence to me, so I'm going to call this "done" for now. But if you have other feedback and/or have issues getting this working, please do let me know.

witten closed this issue 2024-01-24 22:30:18 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

spot-check

1.8.11

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

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

No description provided.