-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Restic 0.10.0 always reports all directories "changed", adds duplicate metadata, when run on ZFS snapshots #3041
Description
I run my backups from a ZFS snapshot in order to ensure the entire file-system is in a consistent state. After I upgraded to restic 0.10.0 from the previous official release, the backup started adding a duplicate copy of all the directory meta-data while claiming that all the directories have been changed. For example (pardon my bash):
# restic version
restic 0.10.0 compiled with go1.15.2 on freebsd/amd64
# commands executed for bug (repeatedly on unchanging
# /usr/local/bin/restic backup -H $HOSTNAME --verbose=1 --cache-dir=$RESTIC_CACHE --exclude-file "${path}/${EXCLUDE_NAME}" "$path"
scan finished in 2.928s: 1604 files, 341.787 GiB
Files: 0 new, 0 changed, 1604 unmodified
Dirs: 0 new, 231 changed, 0 unmodified
Data Blobs: 0 new
Tree Blobs: 219 new
Added to the repo: 17.876 MiB
The result occurs repeatedly after re-running the backup on a new ZFS snapshot of an otherwise static file-system. I expect it to work like the previous version in which directories were not seen to be "changed".
I tested this on the same file-system except without using a ZFS snapshot, and it does not report directories as "changed" or upload duplicate metadata. Therefore, this problem seems to be particular to using ZFS snapshots. My method for backing up from ZFS snapshots is as follows:
- create ZFS snapshot of file-system labeled "restic"
- run backup of "$basedir/.zfs/snapshot/restic", where the snapshot is mounted
- destroy the ZFS snapshot labeled "restic"
I find it interesting that restic is uploading new/unique directory meta-data with every run, suggesting that something about the directory meta-data is actually changing between runs. However, earlier versions of restic did not "see" these changes. I'm at a loss as to what's causing this.
In terms of severity, this is merely a nuisance to me---about 30ish MiBs added to the repo each day. However, I could see this being a bigger problem on systems with a lot more small files. Is there any way I can find out what aspect of the directory is being identified as "changed" from the command-line? Adding verbosity did not appear to do the trick.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status