"NoneType" exception when creating archive under FreeBSD #355
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#355
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?
Quick preface: I'm not sure if FreeBSD is officially supported by borgmatic. If it isn't then an admin can close this issue.
What I'm trying to do and why
I'm attempting to create a backup to a local repository on a FreeBSD host. While repository initialization works, attempting to run
borgmatic create
results in a NoneType Error traceback, with the application exiting immediately. Creating backups with plain borg works fine, which leads me to believe that this is an issue with borgmatic.Steps to reproduce (if a bug)
sudo pkg install -y py37-borgbackup py37-borgmatic
) or pip (sudo pip install --user --upgrade borgmatic
)borgmatic init --encryption repokey
)borgmatic create
Actual behavior (if a bug)
The task fails almost immediately with the following output:
No archive is created.
Expected behavior (if a bug)
borgmatic runs and creates the archive.
Other notes / implementation ideas
Manually creating the archive with borg by calling
sudo borg create /var/test-repository::archive1 /etc
works as expectedEnvironment
borgmatic version: Tested with 1.5.9 and 1.5.10
borgmatic installation method: pkg package and pip installation
Borg version: 1.1.13
Python version: 3.7.8
operating system and version: FreeBSD 11.4
Additonal files
Configuration file:
(I use ansible to template out the config file, hence the ugly YAML. I also tested a "cleaner" version without the null values and the result was the same)
borgmatic info output for the repo:
(The repo contains a single archive that i created manually with
borg
. borgmatic fails whether this archive exists or not)Vagrantfile for the FreeBSD VM:
I'm be more than happy to supply additional information or logs if needed. Running borgmatic on FreeBSD would allow me to use one backup solution throughout my entire network, including for backing up FreeNAS hosts from within jails.
First of all, thank you for supplying all the excellent detail with this ticket! It certainly helps.
I don't use FreeBSD myself, so it's probably fair to say FreeBSD is "less supported" than, say, Linux. But borgmatic is "just Python", so I'm also happy to try to make it work on FreeBSD insofar as I can.
Also, FWIW, I got an exact repro on Linux when using your configuration! So this issue doesn't appear to be FreeBSD-specific.
But when I comment out the entire
hooks
section (which is composed entirely ofnull
values in your example),borgmatic create
works just fine. No errors.What does that "cleaner" version look like? Have you tried commenting out the
hooks
section entirely?Even if this issue is "caused" by the
null
values, I'm still marking this as a bug because borgmatic should never give a traceback based on an invalid configuration file.Thanks for the quick reply! I just tried commenting out the entire hooks section myself, and indeed, the backup runs just fine. Seems like the empty mysql/psql_databases keys are confusing borgmatic in some way?
The "cleaner" version just had the "null" values removed, but I did not comment out the keys. Probably should have played around with that a little more before opening this issue, hah.
There is some more weirdness here though - the original config does work fine on some systems for me, notably a Ubuntu 20.04 Vagrant VM. That's why I assumed that my config was fine, as I would have expected an error/quirk in the config to affect all systems:
Software versions for the Ubuntu VM:
- borgmatic: 1.5.1
- borg: 1.11.1
- Python: 3.8.2
I guess my original issue can be considered resolved - but I agree that a config error probably shouldn't result in a traceback. And it's weird that it still works on some systems - I guess that could be caused by a different borgmatic or library version?
Yup, and that's the bug that needs fixing IMO.
No worries! I'm glad there is a work-around for you with the current version.
Just by looking at changelogs, I'm 90% sure the traceback/regression was introduced in borgmatic 1.5.3. That's when database dumps were changed to be streaming rather than temporary files on disk. Given that you're using borgmatic 1.5.1 on the Linux systems and borgmatic 1.5.9+ on FreeBSD, that could explain the difference you're seeing.
Fixed in master!
Just released in borgmatic 1.5.11!