"borgmatic restore --database all" should error when not actually restoring anything #246

New Issue

Closed

opened 2019-11-13 17:02:27 +00:00 by witten · 2 comments

witten commented 2019-11-13 17:02:27 +00:00

Owner

Copy Link

What I'm trying to do and why

I'm trying to restore databases when I don't actually have any databases configured in borgmatic's configuration. A user might do this accidentally, not realizing that the restore they think is happening (because no error) is actually not restoring anything. Unless they look carefully at the output, they may not realize nothing happened.

Steps to reproduce (if a bug)

# borgmatic restore -c test.yaml -v 2 --archive flux-2019-11-12T16:06:29.673759 --database all

No databases configured in test.yaml. Some database dumps in the archive.

Actual behavior (if a bug)

Ensuring legacy configuration is upgraded
test.borg: Restoring databases from archive flux-2019-11-12T16:06:29.673759
borg extract --debug --list --show-rc /root/tmp/test.borg::flux-2019-11-12T16:06:29.673759
using builtin fallback logging configuration
35 self tests completed in 0.07 seconds
Verified integrity of /root/tmp/test.borg/index.699
TAM-verified manifest
security: read previous location '/root/tmp/test.borg'
security: read manifest timestamp '2019-11-13T00:06:29.827230'
security: determined newest manifest timestamp as 2019-11-13T00:06:29.827230
security: repository checks ok, allowing access
root/tmp
root/tmp/log
root/tmp/test.yaml
root/.borgmatic
root/.borgmatic/postgresql_databases
root/.borgmatic/postgresql_databases/database.example.org
root/.borgmatic/postgresql_databases/database.example.org/users
root/.borgmatic/postgresql_databases/localhost
root/.borgmatic/postgresql_databases/localhost/test
root/.borgmatic/mysql_databases
root/.borgmatic/mysql_databases/172.17.0.2
root/.borgmatic/mysql_databases/172.17.0.2/all
terminating with success status, rc 0

summary:
test.yaml: Successfully ran configuration file

Expected behavior (if a bug)

Error!

Other notes / implementation ideas

Would also be good to check what happens when databases are configured, but none are found in the archive.

Environment

borgmatic version: 1.4.10.dev0

borgmatic installation method: pip install --editable

Borg version: 1.1.10

Python version: 3.7.4

Database version (if applicable): PostgreSQL 11.5, MySQL Ver 15.1 Distrib 10.4.8-MariaDB

operating system and version: Manjaro stable

#### What I'm trying to do and why I'm trying to restore databases when I don't actually have any databases configured in borgmatic's configuration. A user might do this accidentally, not realizing that the restore they think is happening (because no error) is actually not restoring anything. Unless they look carefully at the output, they may not realize nothing happened. #### Steps to reproduce (if a bug) ``` # borgmatic restore -c test.yaml -v 2 --archive flux-2019-11-12T16:06:29.673759 --database all ``` No databases configured in `test.yaml`. Some database dumps in the archive. #### Actual behavior (if a bug) ``` Ensuring legacy configuration is upgraded test.borg: Restoring databases from archive flux-2019-11-12T16:06:29.673759 borg extract --debug --list --show-rc /root/tmp/test.borg::flux-2019-11-12T16:06:29.673759 using builtin fallback logging configuration 35 self tests completed in 0.07 seconds Verified integrity of /root/tmp/test.borg/index.699 TAM-verified manifest security: read previous location '/root/tmp/test.borg' security: read manifest timestamp '2019-11-13T00:06:29.827230' security: determined newest manifest timestamp as 2019-11-13T00:06:29.827230 security: repository checks ok, allowing access root/tmp root/tmp/log root/tmp/test.yaml root/.borgmatic root/.borgmatic/postgresql_databases root/.borgmatic/postgresql_databases/database.example.org root/.borgmatic/postgresql_databases/database.example.org/users root/.borgmatic/postgresql_databases/localhost root/.borgmatic/postgresql_databases/localhost/test root/.borgmatic/mysql_databases root/.borgmatic/mysql_databases/172.17.0.2 root/.borgmatic/mysql_databases/172.17.0.2/all terminating with success status, rc 0 summary: test.yaml: Successfully ran configuration file ``` #### Expected behavior (if a bug) Error! #### Other notes / implementation ideas Would also be good to check what happens when databases are configured, but none are found in the archive. #### Environment **borgmatic version:** 1.4.10.dev0 **borgmatic installation method:** `pip install --editable` **Borg version:** 1.1.10 **Python version:** 3.7.4 **Database version (if applicable):** PostgreSQL 11.5, MySQL Ver 15.1 Distrib 10.4.8-MariaDB **operating system and version:** Manjaro stable

witten added the

bug

label 2019-11-13 17:02:32 +00:00

witten commented 2019-11-13 18:20:17 +00:00

Author

Owner

Copy Link

Potential data loss: This is a particularly nasty bug. What happened is that when no databases are configured, no dump patterns get passed to borg extract, which means borg extracts all files in the archive instead of just database dumps, which means it could extract over your actual non-database files! Super not good. I have a fix in hand, and will release it shortly.

**Potential data loss:** This is a particularly nasty bug. What happened is that when no databases are configured, no dump patterns get passed to `borg extract`, which means borg extracts *all* files in the archive instead of just database dumps, which means it could extract *over* your actual non-database files! Super not good. I have a fix in hand, and will release it shortly.

witten added the

data loss

label 2019-11-13 18:21:24 +00:00

witten referenced this issue from a commit 2019-11-13 18:43:46 +00:00

Fix for "borgmatic restore" showing success and incorrectly extracting archive files, even when no databases are configured to restore (#246).

witten commented 2019-11-13 18:46:34 +00:00

Author

Owner

Copy Link

Fix released in borg 1.4.10. Upgrading is highly recommended!

Fix released in borg 1.4.10. Upgrading is highly recommended!

witten closed this issue 2019-11-13 18:46:34 +00:00

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

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   

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

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

No description provided.