borgmatic-collective/borgmatic
borgmatic-collective
/
borgmatic
15
57
Fork 40
Code Issues 53 Pull Requests 2 Actions Packages Releases 121 Activity

Remove previous named pipes before dumping databases #360

New Issue
Closed
opened 2020-10-14 12:34:59 +00:00 by fallen · 7 comments
fallen commented 2020-10-14 12:34:59 +00:00
Copy Link

What I'm trying to do and why

I had a borg/borgmatic infinite hang during my backups, I opened a ticket on borg repo (https://github.com/borgbackup/borg/issues/5420) then realized the issue was because of a dangling UNIX pipe in /root/.borgmatic/ due to a previously interrupted run with a wrong config (postgresql in the config but no postgresql on the server).
It took me long to understand what was going on.

I would like to avoid this to happen again (or to somebody else).

Steps to reproduce (if a bug)

Tell borgmatic config file you want to backup postgresql database even though you don't have postgresql.
It will create a dangling UNIX pipe and fail.
Then fix your config to tell only to backup mysql database.
Then run your backup, it will hang because of the dangling pipe for postgre is still there.

Actual behavior (if a bug)

It hangs indefinitely

Expected behavior (if a bug)

I would expect either a timeout (I opened a ticket for this idea on the borg repo).
See the ideas section for what is related to borgmatic.

Other notes / implementation ideas

I would propose to always cleanup the .borgmatic directory before backuping.
Or at least removing the mysql and postgresql related pipes.
Then, if in the config there is still a database backup section, re-create the needed pipes.

Environment

borgmatic version: 1.5.10

borgmatic installation method: via documented ansible playbook

Borg version: 1.1.14

Python version: 3.5.3

Database version (if applicable): mysql Ver 15.1 Distrib 10.1.45-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2

operating system and version:
Distributor ID: Debian
Description: Debian GNU/Linux 9.13 (stretch)
Release: 9.13
Codename: stretch

#### What I'm trying to do and why I had a borg/borgmatic infinite hang during my backups, I opened a ticket on borg repo (https://github.com/borgbackup/borg/issues/5420) then realized the issue was because of a dangling UNIX pipe in /root/.borgmatic/ due to a previously interrupted run with a wrong config (postgresql in the config but no postgresql on the server). It took me long to understand what was going on. I would like to avoid this to happen again (or to somebody else). #### Steps to reproduce (if a bug) Tell borgmatic config file you want to backup postgresql database even though you don't have postgresql. It will create a dangling UNIX pipe and fail. Then fix your config to tell only to backup mysql database. Then run your backup, it will hang because of the dangling pipe for postgre is still there. #### Actual behavior (if a bug) It hangs indefinitely #### Expected behavior (if a bug) I would expect either a timeout (I opened a ticket for this idea on the borg repo). See the ideas section for what is related to borgmatic. #### Other notes / implementation ideas I would propose to always cleanup the .borgmatic directory before backuping. Or at least removing the mysql and postgresql related pipes. Then, if in the config there is still a database backup section, re-create the needed pipes. #### Environment **borgmatic version:** 1.5.10 **borgmatic installation method:** via documented ansible playbook **Borg version:** 1.1.14 **Python version:** 3.5.3 **Database version (if applicable):** mysql Ver 15.1 Distrib 10.1.45-MariaDB, for debian-linux-gnu (x86_64) using readline 5.2 **operating system and version:** Distributor ID: Debian Description: Debian GNU/Linux 9.13 (stretch) Release: 9.13 Codename: stretch
witten commented 2020-10-14 16:54:18 +00:00
Owner
Copy Link

Fun fact: borgmatic does delete the PostgreSQL named pipe before initiating a backup... but only if the PostgreSQL hook is configured in borgmatic's configuration file! So I think the fix would be for borgmatic to delete the PostgreSQL (and MySQL) named pipes unconditionally before running a create—even if databases are not configured.

You win the award for finding the edge case of the week.🎖️

Thanks so much for bringing this to my attention.

Fun fact: borgmatic *does* delete the PostgreSQL named pipe before initiating a backup... but only if the PostgreSQL hook is configured in borgmatic's configuration file! So I think the fix would be for borgmatic to delete the PostgreSQL (and MySQL) named pipes unconditionally before running a create—even if databases are not configured. You win the award for finding the edge case of the week.🎖️ Thanks so much for bringing this to my attention.
🎉 1
fallen commented 2020-10-14 18:03:04 +00:00
Author
Copy Link

Ahah thanks for the 🎖️!
Yes I agree, that would fix it.
In parallel I am in contact with Borg's people so that they add a timeout and an error message to make this kind of situation more obvious.
(That can also help diagnose issues with people backuping character devices without knowing it with --read-special)
You're welcome!
Thanks for the very quick response :)
And thanks for the good software!

Ahah thanks for the 🎖️! Yes I agree, that would fix it. In parallel I am in contact with Borg's people so that they add a timeout and an error message to make this kind of situation more obvious. (That can also help diagnose issues with people backuping character devices without knowing it with --read-special) You're welcome! Thanks for the very quick response :) And thanks for the good software!
👍 1
witten added the
bug
 label 2020-10-14 18:15:56 +00:00
witten commented 2020-11-20 23:24:13 +00:00
Owner
Copy Link

Relevant Borg ticket: https://github.com/borgbackup/borg/issues/5422

Relevant Borg ticket: https://github.com/borgbackup/borg/issues/5422
witten commented 2022-10-12 17:26:31 +00:00
Owner
Copy Link

At long last, this should be taken care of! borgmatic now unconditionally nukes all ~/.borgmatic database named pipes, whether or not their hooks are configured. This happens automatically before/after create and restore currently. These changes will be part of the next release.

At long last, this should be taken care of! borgmatic now unconditionally nukes all `~/.borgmatic` database named pipes, whether or not their hooks are configured. This happens automatically before/after `create` and `restore` currently. These changes will be part of the next release.
witten commented 2022-10-12 18:03:17 +00:00
Owner
Copy Link

Just released in borgmatic 1.7.3!

Just released in borgmatic 1.7.3!
👍 1 🎉 1
fallen commented 2022-10-13 06:46:52 +00:00
Author
Copy Link

Hey @witten , thanks a lot for the fix :)
I'm still using borgmatic and it works great!

Hey @witten , thanks a lot for the fix :) I'm still using borgmatic and it works great!
witten commented 2022-10-13 16:07:40 +00:00
Owner
Copy Link

Glad to hear it!

Glad to hear it!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
main
spot-check
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
2 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#360
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?