我正在寻找某种方法来解决 Linux 上使用 tar 的增量备份问题。
我有大量数据集（大约 3TB）需要备份到磁带。为此，我在 LTO4 设备上使用 linux tar 命令和 mt / mtx。
由于备份非常非常非常慢（我想我必须将其放在另一个问题中），我别无选择，只能使用增量备份以避免它在生产期间运行。
基本上，它是这样的：
完整的 tar 已制作完成：（级别为 0）
tar --new-volume-script=changetape.sh \ --exclude=.zfs \ --listed-incremental=file.index \ --label=full_DS01 \ -cvf /dev/nst0 \ /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog每天增量焦油：
mtx -f /dev/sg1 load X #(load correct tape) mt -f /dev/nst0 eod #(forward to end of data to write a new incremental tar) tar --exclude=.zfs \ --listed-incremental=file.index \ --label=incremental_DS01 \ -czvf /dev/nst0 \ /mnt/storage/sharename >>filelisting.log 2>>errlisting.errlog重复增量焦油。使用与 2 中相同的过程，因此我总是使用 0 级列出的增量，每次都会进行调整。这应该意味着我总是备份自上次增量更新以来已更改的文件。 （与差异相反，您总是与完整更新进行比较）
问题：
经过几次迭代后，增量开始失败，这意味着：备份运行，但似乎认为所有文件都已更改，实际上它执行了完整备份。
这发生在不同的数据集中。
我该如何解决这个问题？这怎么可能呢？一切似乎运行良好，然后它认为所有文件都已更改？
为了清楚起见：
- 数据集是只读安装点
- 文件夹结构与完整备份中的相同
- 上层文件夹名称没有改变
我该如何解决这个问题？
答案1
gtar 中的增量功能存在概念问题，无法在所有情况下正常工作。 2004年我尝试在star上检查增量功能时，gtar很早就失败了，根本无法测试。
你尝试过star的增量备份吗？
Freebsd 使用 star 进行 zfs 备份，并且由于 Freebsd 修复了一些旧的内核错误，因此效果很好。
gtar增量备份存在几个问题：
重要的较大元数据不在备份存档内，而是在由于使用
gtar供应商特定选项而创建的单独文件中-g。如果系统完全崩溃，该文件很可能会丢失（至少在最新版本中）。然而，该文件与备份分离的存在并不是真正的问题。真正的问题是该文件无法跟踪重命名。gtar 的备份存档不包含有关重命名文件的任何信息。只有一条跟踪允许假设新存档中未提及但当前文件系统中存在的文件名一定已消失并因此被删除。
如果顶层目录被重命名，gtar 需要归档包含所有内容的完整目录树。这使得 gtar 增量巨大，并且在恢复操作期间很容易溢出目标文件系统。
gtar 对于在两个增量之间更改文件类型的非目录文件存在问题。
gtar 无法处理目录重命名，然后创建以前名称的新目录。
因此，我无法使用我在 2004 年 9 月为 star 创建的 gtar 来运行最初的手工测试。
另一方面，Star 使用了 35 年来一直被认为正确的基本算法，因为它是在 1981 年为 ufsdump/ufsrestore 开发的。Star 的增量备份按以下方式工作：
有一个转储日期文件只记录每个完整或增量转储的时间戳、级别和文件系统。
每个 tar 存档都包含跟踪两次备份之间文件系统中的所有更改所需的所有元数据。除了所有已更改的文件之外，star 还归档所有已更改目录的文件名列表以及相关的索引节点号。这允许随时跟踪任何增量备份的所有文件删除和所有文件重命名。
当star从备份恢复文件系统时，它会创建一个数据库，其中包含所有提取的对象的条目，其中包含文件名、备份文件系统的原始inode编号以及提取的文件系统上使用的新inode编号。这使得star能够跟踪两个增量之间的所有变化。
当您重命名文件系统顶层的目录时，star 只需要备份根目录和重命名的目录及其元数据，而不是该目录内容中的单个文件。
10 年来，Star 被用来在 Berlios 文件系统上运行每日累积增量备份和恢复（通常每天更改 2-10GB 数据）并且从未失败。
在开始使用 gtar 进行备份之前，您可能希望首先运行类似的恢复测试。
顺便说一句：这里有一个脚本，用于验证 GNU tar 如何在增量恢复中失败：是否可以使用 tar 进行完整系统备份？