borgmatic 2.2.0, published 29 October, goes at a problem that shows up whenever you back up a virtual machine: a tarball is opaque to Borg. The docs give the reason: “Borg can’t effectively deduplicate their contents because of the way that a tarball’s files are packed together (and often compressed)”, which hurts most on “large ones like virtual machine exports.”

A tarballs hook, marked beta

The answer is a tarballs: hook (#1273) that declares a tar file as a data source. The docs mark it “Beta feature”, worth weighing first. During backup, borgmatic “streams each tarball to Borg, unpacking its files directly into the created Borg archive.” The files inside arrive as files rather than as one packed blob, which is what keeps deduplication working.

The docs note it does not use Borg’s import-tar, which is limited to a single tarball per archive and rules out extra source directories. It also avoids spilling to disk: “Both create and restore operate without using any temporary files for tarball data.”

Each entry takes a name and a path, with an optional label and restore_path. Restoring goes through the data source:

borgmatic restore --archive latest --data-source virtual-machine

The limitations matter before you plan around it. Contents are stored under borgmatic/tarballs/ (with Borg 1.4 or later) rather than at their original path, so a conventional extract will not put them where they came from. Restored tarballs “are not bit-identical to their corresponding original tarballs, even though their file contents and metadata should be the same.” Only gzip, bzip2, xz and no compression are supported. A tarball that also sits in your source directories gets backed up twice unless you exclude it. Restore removes any tarball already at the restore path before writing. And enabling the hook forces Borg’s --read-special for the backup, whatever your own read_special option says.

Hangs, file descriptors, and smaller things

Three fixes go after runs that stall or fail rather than misbehave quietly. #1368 fixes “a hang in which a database dump command spewing lots of output could send borgmatic into a loop”, which the release says was most prevalent with MongoDB. #1370 fixes “Too many open files” and “filedescriptor out of range in select()” errors when dumping hundreds of databases. The release also closes a theoretical hang in which the program “neglected to consume sub-process stderr output”, affecting restore, browse and config bootstrap.

Smaller items: --dry-run works for the borg action when the flag follows borg (#1360), diff gains --json, and browse shows a size for every file and directory (#1372).

The eMudhra line, scoped

There is a security item, and its scope is narrower than the heading suggests: “Upgrade the certifi dependency to remove trusted eMudhra certificates, thereby addressing the eMudhra certificate authority compromise. This affects outgoing HTTP requests made from borgmatic monitoring hooks, and only applies to the precompiled borgmatic binary (which bundles certifi).” Read precisely: monitoring callbacks from the precompiled binary, not the backup path, and not a source or distribution install, where certifi comes from elsewhere. It is the same certificate authority thread the desk covered in our 22 October piece.

The quiet regression, and the interpreter

The least visible fix is the one filesystem-snapshot users will feel: #1376 repairs “a regression in which ZFS/LVM/Btrfs hooks no longer got Borg cache hits due to a random temporary directory created within the borgmatic runtime directory.” A lost cache hit is not an error message. It is a slower run, which goes unnoticed until the window is too short.

One upgrade note for older installs: the release drops support for Python 3.10, “which has been end-of-lifed”, and corrects its package metadata to reflect that 3.9 support went away in 2.0.11. If borgmatic runs on a distribution’s Python 3.10, that interpreter needs to move before the package will.

The release notes give no upgrade command, so how you update depends on how borgmatic was installed. If you back up VM exports, the hook is the reason to care. If you never touch it, the hang and cache-hit fixes still earn the update.