Access borg repositories in read only mode #388

New Issue

Open

opened 2021-01-29 08:47:48 +00:00 by icrc-fdeniger · 5 comments

icrc-fdeniger commented 2021-01-29 08:47:48 +00:00

Copy Link

What I'm trying to do and why

Use borgmatic extract/list commands in a secured environement where borg repository are in read-only mode.
Borg add the option --bypass-lock to be compliant with read-only repository.

Other notes / implementation ideas

1. Add extra-command for borg list / borg extract operation (--bypass-lock).
2. A global configuration "Read-only" that will prevent all write operations

Environment

borgmatic version: [version here]

1.5.12

borgmatic installation method:
Docker

Borg version: [version here]

1.1.15

Python version: [version here]

Use python3 --version

operating system and version:
Alpine

#### What I'm trying to do and why Use borgmatic extract/list commands in a secured environement where borg repository are in read-only mode. Borg add the option --bypass-lock to be compliant with read-only repository. #### Other notes / implementation ideas 1. Add extra-command for borg list / borg extract operation (--bypass-lock). 1. A global configuration "Read-only" that will prevent all write operations #### Environment **borgmatic version:** [version here] 1.5.12 **borgmatic installation method:** Docker **Borg version:** [version here] 1.1.15 **Python version:** [version here] Use `python3 --version` **operating system and version:** Alpine

witten added the good first issue label 2023-03-27 04:13:40 +00:00

witten commented 2023-03-27 04:14:03 +00:00

Owner

Copy Link

I apologize for the super lengthy delay in this getting any attention. A borgmatic list --bypass-lock flag seems like a good idea to me. But do you think it would be needed if there was a "read only" borgmatic configuration option as you suggest? That way borgmatic would be responsible for issuing --bypass-lock as needed. Or perhaps borgmatic could support both in order to handle one-off lock bypassing and global read-only use cases.

I apologize for the super lengthy delay in this getting any attention. A `borgmatic list --bypass-lock` flag seems like a good idea to me. But do you think it would be needed if there was a "read only" borgmatic configuration option as you suggest? That way borgmatic would be responsible for issuing `--bypass-lock` as needed. Or perhaps borgmatic could support both in order to handle one-off lock bypassing *and* global read-only use cases.

witten commented 2024-11-20 06:37:43 +00:00

Owner

Copy Link

Looks like --bypass-lock is gone in Borg 2.

Looks like `--bypass-lock` is gone in [Borg 2](https://borgbackup.readthedocs.io/en/2.0.0b14/changes.html).

gautamaggarwal2810 commented 2025-03-27 03:34:12 +00:00

Contributor

Copy Link

I would like to work on this issue.How should I proceed with this and what remains to be implemented??

I would like to work on this issue.How should I proceed with this and what remains to be implemented??

witten removed the good first issue label 2025-03-28 18:34:21 +00:00

witten commented 2025-03-28 18:53:05 +00:00

Owner

Copy Link

I've removed the "good first issue" label, but you're still welcome to work on this. I removed it because with --bypass-lock gone in Borg 2, the implementation here is no longer quite as straightforward IMO. Here's how I would state the high-level requirement: Some users want to use borgmatic with a read-only Borg repository, e.g. a repo burned to a physical disc or on read-only network storage. With Borg 1, one way to support that need would be with an option that causes --bypass-lock to get passed to relevant Borg subcommands. For instance, I could envision adding an optional read_only option to each repository within repositories:. That way, you could indicate whether a repo is read-only with that option, and if set, borgmatic would take care of passing --bypass-lock for any actions where Borg would put a lock in place.

There is the question what to do about Borg 2 though. It might be worth a little experimenting to see how a read-only Borg 2 repository works with borgmatic today—and whether borgmatic needs to make any changes to support such a scenario. It's possible that the feature described above could be documented as Borg 1 only.

An alternate approach would be not to add --bypass-lock functionality directly, especially since its going away eventually. Instead, this ticket could be closed and #427 could be implemented instead to allow users to self-service extra flags.

I've removed the "good first issue" label, but you're still welcome to work on this. I removed it because with `--bypass-lock` gone in Borg 2, the implementation here is no longer quite as straightforward IMO. Here's how I would state the high-level requirement: Some users want to use borgmatic with a read-only Borg repository, e.g. a repo burned to a physical disc or on read-only network storage. With Borg 1, one way to support that need would be with an option that causes [`--bypass-lock`](https://borgbackup.readthedocs.io/en/stable/usage/general.html#common-options) to get passed to relevant Borg subcommands. For instance, I could envision adding an optional `read_only` option to each repository within `repositories:`. That way, you could indicate whether a repo is read-only with that option, and if set, borgmatic would take care of passing `--bypass-lock` for any actions where Borg would put a lock in place. There is the question what to do about Borg 2 though. It might be worth a little experimenting to see how a read-only Borg 2 repository works with borgmatic today—and whether borgmatic needs to make any changes to support such a scenario. It's possible that the feature described above could be documented as Borg 1 only. An alternate approach would be *not* to add `--bypass-lock` functionality directly, especially since its going away eventually. Instead, this ticket could be closed and #427 could be implemented instead to allow users to self-service extra flags.

gautamaggarwal2810 commented 2025-03-29 12:26:24 +00:00

Contributor

Copy Link

Thanks for taking time to write such a detailed explanation @witten !! But since this is no longer a beginner friendly good-first issue,I am not confident enough to take this issue right now as I have yet to get started on my gsoc proposal and time is ticking by. I will visit this issue again in some time and try to solve this. Thanks

Thanks for taking time to write such a detailed explanation @witten !! But since this is no longer a beginner friendly good-first issue,I am not confident enough to take this issue right now as I have yet to get started on my gsoc proposal and time is ticking by. I will visit this issue again in some time and try to solve this. Thanks

👍 1

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

logging-execution-fixes

command-hook-steps

2.0.13

2.0.12

2.0.11

2.0.10

2.0.9

2.0.8

2.0.7

2.0.6

2.0.5

2.0.4

2.0.3

2.0.2

2.0.1

2.0.0

1.9.14

1.9.13

1.9.12

1.9.11

1.9.10

1.9.9

1.9.8

1.9.7

1.9.6

1.9.5

1.9.4

1.9.3

1.9.2

1.9.1

1.9.0

1.8.14

1.8.13

1.8.12

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

blocked

breaking

bug

data loss

design finalized

good first issue

new feature area

question / support

security

waiting for response

No Label

Milestone

No items

No Milestone

Assignees

Clear assignees

witten

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#388