目前，我创建了一个 NFS 并将其安装在一个特殊的服务器上，该服务器负责实际备份并将其上传到 s3。我主要担心的是，我觉得这个简单的任务太复杂了。我安排了 cron 作业来在非工作时间运行备份，但仍然想优化和改进我的策略。
目前，备份服务器上的脚本只会在特定日期内查找 NFS 共享上的文件，将它们全部打包并使用 aws sync 命令上传到 s3 glacier。下次运行时，脚本将获取 aws s3 对象的列表并跳过查找这些日期的文件（日期是存档文件名的一部分，因此它是一种非常快速的自定义同步机制）
在 NFS 上使用 tar 命令检查网络使用情况时，网络使用率从未超过 200Mbps，并且是通过 1Gbit 交换机通过局域网传输的。上传到 s3 的速度在 aws cli 配置中受到限制。因此，该脚本非常低调，这正是我想要的。然而，有些东西告诉我，也许我应该每天简单地使用 aws sync 备份数据，而不是重新发明轮子。find 和 tar 以及额外同步逻辑中的额外复杂性可能会由于过于复杂而导致一些无法预见的错误。
我的问题是，按照我的方式做有什么缺点（我主要担心的是使用 NFS 进行大量读取备份操作是否不好？）并且添加所有额外的逻辑。
但是，如果我只是为了简单而强行使用 aws sync 来同步所有文件，那么对于 TB 级的数据来说，这将花费非常长的时间，并且还会使备份服务器上的 CPU 激增，并且由于读取量巨大，使用 NFS 共享的生产环境中的 CPU 也会激增。我想我可以尝试同步特定日期，并存储一个包含我已经备份的日期的本地文件。
希望得到一些智慧:)
答案1
像 aws sync 或 rsync 这样的同步程序很容易使用，但元数据很重。大量的文件会导致大量的元数据 I/O。
tar 命令可以根据您关心的内容自定义同步。仅检查 mtime 元数据或遍历名称中包含日期的树将更有效率。但是，是的，自定义意味着您必须确保它是正确的。
块级备份不关心文件，而是备份整个卷。但是，增量备份和恢复单个文件比较棘手。基于快照可能会有所帮助（Linux LVM、ZFS）。但您需要在存储设备上执行此操作，而不是 NFS 共享。
无论实施如何，最重要的部分始终是恢复。
测试恢复。定义一组文件，为恢复时间目标设置一个计时器，然后执行。抽查文件列表是否完整，并且完整性良好。特别检查边缘情况，例如当天的第一个和最后一个文件。