主页 / ubuntu / 问题 / 1265491
Accepted
Rychu
Asked: 2020-08-09 02:52:26 +0800 CST

TAR `--listed-incremental` 始终是 ZFS（和 Ubuntu）升级后的完整备份

  • 772

TL;博士

在将我的 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 的行为进行比较，除了日期或指南等明显差异外，我没有发现任何有意义的东西。具有不同值的属性是：

  • 设备
  • 创建txg
  • 自动修剪（rpool是 SSD）
  • canmount（备份的 hason和rpool's has 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 个月前更改！

PS。我刚刚注意到访问时间有不同的时区。这不是很奇怪吗？?

upgrade backup tar zfs

1 个回答

  1. Best Answer

    我刚刚了解到，修改时间戳并不是确定文件是否被修改的唯一因素（以 TAR 术语）。快照文件还包含有关文件所在驱动器的信息。tar-snapshot-edit可以使用脚本在快照文件中检查上次使用的设备。不幸的是，设备 ID 似乎经常更改。在此链接之后，可以找到更多详细信息：

    各种情况都可能导致设备编号发生变化：升级内核版本、重新配置硬件、以不同的顺序加载内核模块、使用动态组装的虚拟卷（例如使用 LVM 或 RAID）、热插拔驱动器（例如外部 USB或 Firewire 驱动器）等。在大多数情况下，用户不会注意到此更改。但是，它会影响 tar 增量备份：设备号存储在 tar 快照文件中（请参阅增量快照文件的格式部分），用于确定自上次备份以来文件是否已更改。如果设备编号由于某种原因发生更改，默认情况下您运行的下一个备份将是完整备份。

    就我而言，最简单的解决方法是简单地添加--no-check-device完成这项工作的选项。

    • 0

相关问题