From bc79eafb0bad48f3e53e6d95cd968e9414ca321a Mon Sep 17 00:00:00 2001 From: Dan Helfman Date: Mon, 7 Apr 2025 13:51:20 -0700 Subject: [PATCH] Document potential performance issues and workarounds with the ZFS, Btrfs, and LVM hooks (#1035). --- NEWS | 2 + docs/how-to/snapshot-your-filesystems.md | 58 ++++++++++++++++++++++++ 2 files changed, 60 insertions(+) diff --git a/NEWS b/NEWS index d2527d4e..a37dc813 100644 --- a/NEWS +++ b/NEWS @@ -1,5 +1,7 @@ 2.0.2.dev0 * #1059: Fix a regression in which soft failure exit codes in command hooks were not respected. + * #1035: Document potential performance issues and workarounds with the ZFS, Btrfs, and LVM hooks: + https://torsion.org/borgmatic/docs/how-to/snapshot-your-filesystems/ 2.0.1 * #1057: Fix argument parsing to avoid using Python 3.12+ string features. Now borgmatic will diff --git a/docs/how-to/snapshot-your-filesystems.md b/docs/how-to/snapshot-your-filesystems.md index 018e6553..925fe0ef 100644 --- a/docs/how-to/snapshot-your-filesystems.md +++ b/docs/how-to/snapshot-your-filesystems.md @@ -116,6 +116,27 @@ you can use the standard extract them. +#### ZFS performance + +With Borg version 1.x Because of +the way that ZFS snapshot paths can change from one borgmatic invocation to the +next, the [Borg file +cache](https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html#cache) +may not get cache hits on snapshotted files. This makes backing up ZFS snapshots +a little slower than non-snapshotted files that have consistent paths. You can +mitigate this by setting a fixed [runtime +directory](https://torsion.org/borgmatic/docs/how-to/backup-your-databases/#runtime-directory) +(that's not located in `/tmp`). This allows borgmatic to use a consistent +snapshot path from one run to the next, thereby resulting in Borg files cache +hits. + +With Borg version 2.x Snapshotted +files should get cache hits regardless of whether their paths change, because +Borg 2.x is smarter about how it looks up file paths in its cache—it constructs +the cache key with the path *as it's seen in the archive* (which is consistent +across runs) rather than the full absolute source path (which can change). + + ### Btrfs New in version 1.9.4 With Borg version 1.x Because of +the way that Btrfs snapshot paths change from one borgmatic invocation to the +next, the [Borg file +cache](https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html#cache) +will never get cache hits on snapshotted files. This makes backing up Btrfs +snapshots a little slower than non-snapshotted files that have consistent paths. + +With Borg version 2.x Even +snapshotted files should get cache hits, because Borg 2.x is smarter about how +it looks up file paths in its cache—it constructs the cache key with the path +*as it's seen in the archive* (which is consistent across runs) rather than the +full absolute source path (which changes). + + ### LVM New in version 1.9.4 With Borg version 1.x Because of +the way that LVM snapshot paths can change from one borgmatic invocation to the +next, the [Borg file +cache](https://borgbackup.readthedocs.io/en/stable/internals/data-structures.html#cache) +may not get cache hits on snapshotted files. This makes backing up LVM snapshots +a little slower than non-snapshotted files that have consistent paths. You can +mitigate this by setting a fixed [runtime +directory](https://torsion.org/borgmatic/docs/how-to/backup-your-databases/#runtime-directory) +(that's not located in `/tmp`). This allows borgmatic to use a consistent +snapshot path from one run to the next, thereby resulting in Borg files cache +hits. + +With Borg version 2.x Snapshotted +files should get cache hits regardless of whether their paths change, because +Borg 2.x is smarter about how it looks up file paths in its cache—it constructs +the cache key with the path *as it's seen in the archive* (which is consistent +across runs) rather than the full absolute source path (which can change).