MySQL dump on "all" fails when only system databases are present #319
Labels
No Label
bug
data loss
design finalized
good first issue
new feature area
question / support
security
waiting for response
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: borgmatic-collective/borgmatic#319
Loading…
Reference in New Issue
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?
What I'm trying to do and why
I've imported my borgmatic config from another machine and noticed that the config now fails on the "all" database dumps. The machine is still fresh and doesn't have any databases imported yet.
Steps to reproduce (if a bug)
Actual behavior (if a bug)
Expected behavior (if a bug)
Have borgmatic recognize that only system databases are found, and skip database dump without error.
Environment
borgmatic version: 1.5.4
borgmatic installation method: pip package
Borg version: 1.1.11
Python version: 3.8.3
Database version (if applicable): 10.3.22-MariaDB
operating system and version: Debian testing (bullseye)
Thanks so much for reporting this one. It definitely seems like the current behavior of issuing a
mysqldump
command with invalid parameters is not the right thing to do!The one problem I can envision if borgmatic doesn't error when there are no "all" databases to backup: A user may see backups succeeding and assume that everything is working, when in fact nothing is being backed up.. because there are no user databases on the system. Thoughts on that?
In your particular case, I'm curious.. Why do you have the MySQL database hook enabled if no user databases are present? Are you planning to add databases later on?
I am migrating to a new machine and am indeed planning to adding/importing databases later on. I was preparing borgmatic beforehand and stumbled across the error.
You're right about the cases where a user might assume that everything is working, when it isn't. And that user should probably have the mysql hook disabled. Maybe a descriptive error would be enough, without calling the invalid mysqldump command?
A descriptive error makes sense to me!
Released in borgmatic 1.5.5!
I've tested the update, works great!
Thanks Dan.