有一台 Ubuntu 机器，里面有大量文件（2.7TB，数千个目录，超过 200 万个文件）。我需要每日增量文件备份，以便用户可以轻松浏览备份，就像浏览任何其他文件目录一样（通过 Windows 资源管理器和映射的 SMB 驱动器）。
在备份变得如此之大之前，使用 cp -al 将最新的备份目标文件夹使用硬链接旋转到前一天，然后对最新的备份目标文件夹执行 rsync 的组合效果很好。但是，我将脚本从 NAS（因此它将文件“拉”到备份）移到新服务器，现在我在源服务器而不是备份目标设备上运行备份脚本。
我不确定是从拉取切换到推送是否导致了问题，或者文件集是否太大，但我发现脚本失败了，cp 或 rsync 没有输出带有详细日志的错误。它只是停止了，我发现 cp 和 rsync 进程仍在内存中运行，但似乎没有做任何事情。就好像 rsync 正在“崩溃”，但并没有完全从内存中删除自己。
源日期（大约 95% 或更多）不会改变，因为它是存档数据，但它偶尔会改变。因此，显而易见的解决方案是分段备份以仅执行最新的目录，然后以较低的间隔单独备份相当静态的目录。或者，更改为完全不同的备份解决方案。
但正如我所说，限制在于备份必须能够通过映射驱动器在 Windows 资源管理器中轻松浏览。
所以我想知道是否有任何 rsync 选项（或其他技巧）可以用来加快备份速度？这几乎就像我需要的是 rsync 能够判断目录中是否有任何文件已更改，而不必读取每个文件的文件信息然后深入目录。
我正在使用带有选项的 rsync：-rlptgoh（哎呀，我刚刚注意到我在某个时候把表示详细的 v 去掉了。好吧，我会继续将其添加回来，看看是否能获得有关该问题的更多信息）
但是，您是否仍然有兴趣，是否有任何关于满足要求的更好方法的建议，或者 rsync 选项的其他组合？通过 Windows 资源管理器浏览增量的能力确实给系统管理员的典型建议带来了难题，因为他们通常不满足该要求。
答案1
为了加快速度rsync，您可以尝试使用该--numeric-ids选项。此外，由于rsync很大程度上取决于元数据访问速度，您可以尝试设置vfs_cache_pressure=20在您的备份目的地。
然而据我了解你正面临着受阻 cp或rsync过程，这是一个完全不同的问题。我会尝试简化这个过程，回到拉备份模型，这将使您可以使用rsync 集成硬链接功能，称为--link-dest
更好的是，我会使用rsnapshot配置并自动化备份和轮换过程。我是实际上，使用该系统从各种服务器备份 7+ TB（并且我与您有相同的要求：通过只读 samba 共享呈现备份）。