我们使用 rsync 进行备份，如下所示：
rsync -axH --inplace --delete --delete-excluded \
--exclude-from=excludes --stats \
--link-dest="${previous?}" "${source?}"/ "${dest?}"/"${stamp?}"
$previous 指向上一个备份，这样将使用硬链接创建未更改的文件。目标文件系统 $dest 位于外部 USB 硬盘上，上面除了备份集合外没有其他内容。
在大多数情况下，这种方法非常快。在测试系统上，每个备份大约 200 GB，包含一些大邮件目录 - 但整个 rsync（假设自上次运行以来没有发生太大变化）仅需一分钟左右。
然而，在极少数情况下，也许平均每 100 次运行都需要很长时间，大约 20 分钟或更长时间。rsync 统计数据显示没有任何异常。主机系统在此类运行期间没有显示任何异常活动。系统日志中没有任何令人兴奋的内容。
在某些文件系统（对于 $dest）上，情况似乎比其他文件系统更糟糕。以上数字适用于 EXT4。例如，在 JFS 上，正常运行大约需要 3 分钟，异常运行不太严重，但对我们来说仍然是个问题。
查看 rsync 的调试输出可以发现，在长期运行期间，某些（大型）文件被发现不是最新的，尽管它们在发送方没有被更改。查看它们的 inode 可以发现，没有为这些文件创建硬链接。但 rsync 的统计数据并未显示比平时更多的传输字节，并且通过观察硬盘活动 LED，在这些情况下只有目标驱动器在工作。这些文件是否在目标上从一个目录复制到另一个目录？这不仅是一个性能问题，还可能导致不必要的空间消耗。
以防万一：在备份之前，使用以下命令删除最旧的现有备份：
rsync -a --delete empty/ "${dest?}"/"${old?}"
其中 'empty' 表示一个空目录。这比 'rm -fr' 快得多。
有人能对此提供可能的解释和解决方法吗？
使用 rsync 版本 3.1.0 协议版本 31。
答案1
简短回答：罪魁祸首是我们删除旧备份目录的方式，即 rsyncing 一个空目录。现在我们使用：
查找“${old?}”-删除
这也很快并且避免了问题。
更长的答案：事实上，花费特别长时间的运行是绝对确定的。我们总是保留一定数量的备份（比如 n 个），并在执行新备份之前删除最旧的备份。每 (n+1) 次备份都花费很长时间。看来，通过使用 rsync 删除旧备份，它的一部分会以某种方式因 --link-dest 操作而失效，因此某些文件不是硬链接的，而是复制的（显然是从目标文件系统本身复制的）。此复制过程开始一个新的“周期”，当删除它的第一个备份时结束，这发生在 n 次运行之后。这很可能是由于 rsync 或内核中的错误，但我不会进一步调查。