Check frequency can cause an invalid set of options #565

New Issue

Closed

opened 2022-07-23 13:17:39 +00:00 by g-a-c · 3 comments

g-a-c commented 2022-07-23 13:17:39 +00:00

Contributor

Copy Link

What I'm trying to do and why

Configure checks to be more appropriate (run the lengthy ones less often than the quick ones)

Steps to reproduce (if a bug)

consistency:
    checks:
        - name: repository
          frequency: always
        - name: archives
          frequency: 1 week
        - name: data
          frequency: 1 week
        - name: extract
          frequency: 2 weeks

Actual behavior (if a bug)

For me archives was run recently, thus it is filtered out (filter_checks_on_frequency) from the set of repository/archives/extract/data, leaving repository/extract/data.

make_check_flags receives this list, and because repository is present and archives is not, it transforms the CLI flags passed to borg to contain --repository-only making the full command:

borg check --repository-only --verify-data --debug --show-rc

--repository-only and --verify-data are mutually exclusive, so this command fails.

Expected behavior (if a bug)

Either

• If the data check is requested and due but the archives check is not requested or due, then silently add the archives check as required for data to succeed
• If the data check is requested and due but the archives check is not requested or due, then silently remove the data check so that the overall command can succeed but with a reduced set of checks until the next time the two checks are naturally scheduled together

Other notes / implementation ideas

Environment

borgmatic version: 1.6.6

borgmatic installation method: pipenv

Borg version: 1.2.1

Python version: 3.9.2

Database version (if applicable): n/a

operating system and version: Debian 11

#### What I'm trying to do and why Configure checks to be more appropriate (run the lengthy ones less often than the quick ones) #### Steps to reproduce (if a bug) ```yaml consistency: checks: - name: repository frequency: always - name: archives frequency: 1 week - name: data frequency: 1 week - name: extract frequency: 2 weeks ``` #### Actual behavior (if a bug) For me `archives` was run recently, thus it is filtered out ([`filter_checks_on_frequency`](https://projects.torsion.org/borgmatic-collective/borgmatic/src/branch/master/borgmatic/borg/check.py#L96)) from the set of `repository/archives/extract/data`, leaving `repository/extract/data`. [`make_check_flags`](https://projects.torsion.org/borgmatic-collective/borgmatic/src/branch/master/borgmatic/borg/check.py#L154) receives this list, and because `repository` is present and `archives` is not, it transforms the CLI flags passed to `borg` to contain `--repository-only` making the full command: `borg check --repository-only --verify-data --debug --show-rc` `--repository-only` and `--verify-data` are mutually exclusive, so this command fails. #### Expected behavior (if a bug) Either - If the `data` check is requested and due but the `archives` check is not requested or due, then silently add the `archives` check as required for `data` to succeed - If the `data` check is requested and due but the `archives` check is not requested or due, then silently remove the `data` check so that the overall command can succeed but with a reduced set of checks until the next time the two checks are naturally scheduled together #### Other notes / implementation ideas #### Environment **borgmatic version:** `1.6.6` **borgmatic installation method:** pipenv **Borg version:** `1.2.1` **Python version:** `3.9.2` **Database version (if applicable):** n/a **operating system and version:** Debian 11

witten commented 2022-07-23 16:20:31 +00:00

Owner

Copy Link

Wow, good catch! And thank you so much for diving into the source to see what's getting passed around. I think this probably makes sense to do, if documented well:

If the data check is requested and due but the archives check is not requested or due, then silently add the archives check as required for data to succeed

My thinking is that the pre-existing behavior was that if you requested a data check, that implicitly ran archives as well.

Wow, good catch! And thank you so much for diving into the source to see what's getting passed around. I think this probably makes sense to do, if documented well: > If the data check is requested and due but the archives check is not requested or due, then silently add the archives check as required for data to succeed My thinking is that the pre-existing behavior was that if you requested a `data` check, that implicitly ran `archives` as well.

witten added the bug label 2022-07-23 16:20:40 +00:00

witten referenced this issue from a commit 2022-07-24 04:02:38 +00:00

Fix handling of "repository" and "data" consistency checks to prevent invalid Borg flags (#565).

witten commented 2022-07-24 04:04:17 +00:00

Owner

Copy Link

Okay, this should be fixed now with the first approach you suggested. It'll be part of the next release. Thanks again!

Okay, this should be fixed now with the first approach you suggested. It'll be part of the next release. Thanks again!

witten closed this issue 2022-07-24 04:04:17 +00:00

witten commented 2022-08-22 04:59:42 +00:00

Owner

Copy Link

Just released in borgmatic 1.7.0!

Just released in borgmatic 1.7.0!

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

command-hook-steps

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 bug

Milestone

No items

No Milestone

Assignees

Clear assignees

witten

No Assignees

2 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: borgmatic-collective/borgmatic#565