总结
将我的 ZFS 池从 0.7.x 升级到 0.8.3（以及将 Ubuntu 从 18.04.x 升级到 20.04.1）后，我的 Nextcloud 数据备份（几乎）始终是完整备份。升级前一切都很好，而且我的其他系统 rpool 也按预期运行。
真实的故事
我配置了两个 TAR 备份。系统备份，以前和现在都很好，Nextcloud 数据备份，以前也很好，但现在不行了。它在 ZFS 0.7.x 和 Ubuntu 18.04.x 上已经运行了一年多。前段时间我迁移到了 Ubuntu 20.04，然后是 20.04.1，自第一次升级以来，Nextcloud 备份 (几乎) 一直是完整备份。它按预期进行增量备份的概率是十分之一，但不幸的是，这更像是一个小故障，而不是规则。
果汁
我的备份没有什么特别的：
tar -cpz \
--listed-incremental="$backupIncrementalMetadataFullFileName" \
--exclude="$backupLocation" \
--exclude="*RychuSrv*Backup*.*" \
"/srv/nextcloud/${nextcloudFolderName}" \
| tee "$tarBackupFullFileName" \
| gpg [censored]
ZFS 发生了什么？
我之所以关注 ZFS，是因为……还有什么原因？:) 但我不知道是什么原因导致这种情况发生。我尝试将我的行为rpool与 Nextcloud 的行为进行比较，除了日期或 guid 等明显差异外，我没有发现任何有意义的东西。具有不同值的属性包括：
- 设备
- 创建txg
- 自动修剪（
rpool是 SSD） - canmount（备份的有
on和rpool的有noauto）
我知道可能对此问题产生影响的其他功能/属性是atime和，realtime并且两个池中都是on。
文件是什么样子的
因此，备份的内容大多是文件夹中的图像和视频文件，其中大多数文件很长时间都没有改变。例如：
# ls -1l . | tail -n 500 | head -n 10
-rw-r--r-- 1 www-data www-data 2113359 Jan 5 2020 IMG_20200105_172639.jpg
-rw-r--r-- 1 www-data www-data 2029782 Jan 5 2020 IMG_20200105_172641.jpg
-rw-r--r-- 1 www-data www-data 2374428 Jan 5 2020 IMG_20200105_172652.jpg
-rw-r--r-- 1 www-data www-data 2523738 Jan 5 2020 IMG_20200105_172654.jpg
-rw-r--r-- 1 www-data www-data 3405077 Jan 6 2020 IMG_20200106_083530.jpg
-rw-r--r-- 1 www-data www-data 1989491 Jan 6 2020 IMG_20200106_183744.jpg
-rw-r--r-- 1 www-data www-data 2220897 Jan 11 2020 IMG_20200111_131056.jpg
-rw-r--r-- 1 www-data www-data 2850718 Jan 11 2020 IMG_20200111_132928.jpg
-rw-r--r-- 1 www-data www-data 2095188 Jan 11 2020 IMG_20200111_132956.jpg
-rw-r--r-- 1 www-data www-data 2312352 Jan 11 2020 IMG_20200111_133414.jpg
# stat IMG_20200111_131056.jpg
File: IMG_20200111_131056.jpg
Size: 2220897 Blocks: 4369 IO Block: 131072 regular file
Device: 43h/67d Inode: 328087 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 33/www-data) Gid: ( 33/www-data)
Access: 2020-08-05 00:16:30.136312800 +0200
Modify: 2020-01-11 13:10:57.000000000 +0100
Change: 2020-01-13 14:36:14.531413322 +0100
Birth: -
您可以看到该文件是在午夜之后访问的，这意味着备份脚本将其拉入备份。
为什么？这个文件 6 个月前就被更改了！
附言：我刚刚注意到 Access 时间的时区不同。这不是很奇怪吗？
答案1
我刚刚了解到，修改时间戳并不是确定文件是否被修改的唯一因素（就 TAR 而言）。快照文件还包含有关文件位于哪个驱动器的信息。可以使用脚本在快照文件中检查上次使用了哪个设备。tar-snapshot-edit不幸的是，设备 ID 似乎经常发生变化。以下这链接，可以找到更多详细信息：
各种情况都可能导致设备编号发生变化：升级内核版本、重新配置硬件、以不同的顺序加载内核模块、使用动态组装的虚拟卷（例如 LVM 或 RAID）、热插拔驱动器（例如外部 USB 或 Firewire 驱动器）等。在大多数情况下，用户不会注意到这种变化。但是，它会影响 tar 增量备份：设备编号存储在 tar 快照文件中（请参阅增量快照文件的格式部分），用于确定文件自上次备份以来是否已更改。如果设备编号由于某种原因而发生变化，则默认情况下，您运行的下一次备份将是完整备份。
就我而言，最简单的解决方法就是添加--no-check-device可以完成这项工作的选项。