我构建了一个增量备份解决方案，它使用 RSYNC 来备份我们的一些服务器。我使用 PHP 运行配置文件以获取需要备份的每台服务器的信息。然后 PHP 调用 RSYNC 来增量地处理服务器的远程备份。
这在我们所有的服务器上都运行良好，只需几分钟即可完成......除了一台服务器。这台服务器有很多数据，RSYNC 似乎就挂在上面了。进行一次增量备份需要 3 天以上的时间。我猜它卡在了构建文件列表上。
当我在想要备份的文件夹上运行以下命令时，这里是“iused”的结果。
df -i folder/
54176307
对于 RSYNC 来说，这是否意味着数据量太大？我是否应该寻找其他替代方案？备份服务器当前运行的是 3.0.8 版本，但是，正在备份的客户端都运行的是 RSYNC 2.6.9。您认为将所有内容升级到 3.0.8 会有所不同并缩短此服务器的 3 天备份时间吗？
谢谢，雅各布
答案1
我怀疑单单升级是否能带来您想要的那种改进。在 72 小时后，您可能希望性能提高一个数量级（7.2 小时）。如果您希望使用 2-3 小时，那么在没有 SSD 和良好网络的情况下，祝您好运。
有了 5500 万个 inode（假设文件数量大致相同），您将不得不认真重新考虑您的方法。首先，如果您使用的是 ext 变体，我会考虑对不同的 FS 进行基准测试。
其次，如果您使用的是 ext FS（例如 ext3/4），我要做的第一件事就是关闭 atime！打开 atime 后，每次读取/查看文件时，文件系统都必须对磁盘进行微小的写入，因为 atime 表示“访问时间”。关闭它后，您将无法查看文件何时被访问，但这就是 cookie 崩溃的方式。如果您使用的是标准 SATA 磁盘，假设您每秒可以执行 100 次 IOPS。每次访问写入都需要其中一次（最坏情况）。这意味着每秒需要 100 个文件才能验证它的存在，而当您读取它时，您正在使用更多的 IOPS。55000000/100 = 550000s = 152 小时。一旦您利用内核非常好的算法来合并 IOPS，您可能已经找到了瓶颈。
在您的 /etc/fstab 中，使用 mount 选项：
noatime,nodiratime
完全禁用 atimes。关闭 nodiratime 可关闭目录的访问时间。如果您有很多目录，我建议将其关闭。
我敢打赌，仅此一点就会产生巨大的帮助。
以下是一个 fstab 示例：
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc nodev,noexec,nosuid 0 0
# / was on /dev/sda1 during installation
UUID=66188c62-0d8c-46d8-a44f-8f673ca6ac98 / ext4 errors=remount-ro,discard,noatime,nodiratime 0 1
# swap was on /dev/sda6 during installation
UUID=c3f40312-d6f9-4bb7-b426-602a4b7a6c47 none swap sw 0 0
答案2
我有几个脚本可以做类似的事情。我认为正确的解决方案是让 find 彻底检查文件系统，找出自上次备份以来发生更改的内容，然后让 rsync 进行“同步”，但我还没有解决这个问题。
相反，我有两个脚本，一个用于查找要备份的顶级目录，另一个用于并行备份每个目录。我发现使用 NFS 文件存储时，大约 10 个并行 rsync 的 CPU 利用率相当高。由于该作业此时接近 CPU 限制，而单个 rsync 接近 CPU 的 7%，因此我使用 xargs 运行每个单独的作业，但使用 -P 选项同时运行 7 个作业。
如果有人感兴趣的话我可以通过电子邮件发送脚本。它们应该非常易读。