borgmatic-collective/borgmatic
borgmatic-collective
/
borgmatic
15
56
Fork 39
Code Issues 54 Pull Requests 1 Actions Packages Releases 120 Activity

"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 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!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
spot-check
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
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.
Delete Branch "%!s(<nil>)"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?