我们用rsync做这样的备份：
rsync -axH --inplace --delete --delete-excluded \ --exclude-from=excludes --stats \ --link-dest="${previous?}" "${source?}"/ "${dest?}"/"${stamp?}" 先前的$指向以前的备份，以便使用硬链接创build未更改的文件。 目标文件系统$ dest位于外部USB硬盘驱动器上，没有其他任何东西在备份集合上。
这种方法在大多数情况下都非常快速。 在testing系统上，每个备份大约200GB，包含一些大邮件 – 仍然是整个rsync（假设自上次运行以来没有多less变化）只需要一分钟左右的时间。
然而，在极less数情况下，平均每100次运行一次，耗时很长，大约需要20分钟甚至更长时间。 rsync统计显示没有什么不寻常的。 主机系统在这样的运行过程中没有显示不寻常的活动 没有什么令人兴奋的syslog。
在某些文件系统上（对于$ dest），似乎更糟。 以上数字适用于EXT4。 以JFS为例，正常运行大约需要3分钟，特殊运行不太严重，但对我们来说还是一个问题。
看一下rsync的debugging输出显示，在长时间运行期间，某些（大）文件被发现并不是最新的，尽pipe它们在发送方没有被改变。 没有硬链接为这些文件创build，看看他们的inode揭示。 但是，rsync的统计信息并不会显示比平时更多的传输字节，而从观察硬盘活动指示灯，只有目标驱动器正在工作。 这些文件是从一个目录复制到另一个目录吗？ 这不仅是一个性能问题，而且可能导致不必要的空间消耗。
如果是重要的话：直接在备份之前，使用以下命令删除最早的现有备份：
rsync -a --delete empty/ "${dest?}"/"${old?}"
其中'空'是一个空目录。 这比'rm -fr'快得多。
任何人都可以请提供可能的解释，也许是一种治疗？
使用rsync版本3.1.0协议版本31。
简短的回答：罪魁祸首是我们删除旧的备份目录，即rsyncing一个空目录。 现在我们使用：
find“$ {old？}” - 删除
这也很快，避免了这个问题。
较长的回答：事实上，过长的运行发生了绝对的确定性。 我们总是保留一些备份，并删除最旧的备份，然后再执行新备份。 每第（n + 1）个备份花了很长时间。 看来，通过删除一个旧的备份与rsync，它的一部分是在某种程度上无效的 – 链接 – 目标操作，以便一些文件不是硬链接，但复制（显然是从目标文件系统本身复制）。 这个复制过程开始一个新的“时期”，当它的第一个备份被删除时，这个过程结束，这是在n次运行之后发生的。 这很可能是由于rsync或内核中的错误，但我不会进一步调查。