algorithm - 开发可靠，简单的网络备份软件

Question

是否有任何经过时间验证的策略、算法和开源数据存储格式有助于为慢速网络驱动器开发可靠、快速的增量备份软件？
我打算使用qt framework或.net（还没有决定），但编程语言并不重要，因为我在寻找想法和解决方案，而不是代码（尽管有sdk或库会更好）。
我不打算创建和企业级的客户机-服务器解决方案，但一些简单但仍然可以根据我的需要调整的东西。
长话短说：
我一直在努力寻找可靠的备份软件，它至少支持数据和文件名的简单混淆（xor加密对我来说很好），并且能够枚举和提取备份档案中的单个文件。
我想备份到模拟网络驱动器（使用expandrive或netdrive）。
我尝试过许多不同的程序，但每一个程序都至少有一个关键缺陷由于算法复杂，有些程序备份到网络驱动器的速度太慢。有些程序将所有内容压缩成一个大的zip或自定义格式的文件，这些文件可以分成多个部分，但如果我尝试枚举和提取单个文件，通常会导致超时。有些程序会加密文件内容，但会完全打开文件名，甚至不会混淆它们。
我也尝试过一些专用程序，这些程序直接备份到云服务，但它们被简化了，或者没有为google drive提供任何加密，我打算主要使用这些程序。
这就是为什么我决定创造一些定制，我可以调整我的喜欢这也是我学习如何正确实施备份过程的一个机会。
目前我的想法是把我的备份分成一些小的（100MB？50兆？还不确定……）按顺序编号的存储桶（文件夹）我可以在当前正在进行的bucket中存储一个锁文件。如果备份进程被中断并重新启动，我可以检查锁文件是否存在，然后我知道我必须从头开始重新启动该存储桶。
有了这个bucket系统，我必须确保每个bucket都有完整的文件这意味着如果我存储一个1GB的文件，我不能将它分成更多的部分，因为这会使自定义文件寻址表等的事情变得非常复杂。因此，我的bucket大小只是一个推荐的目标，而不是严格的目标。
另一个问题是如何存储文件列表及其修改时间，这样我就可以实现基于时间戳的增量备份，并尽快加载列表。我不确定把每个桶的文件列表存储在那个桶里是否是个好主意。也许最好将它存储在一个单独的文件中，以便我可以立即下载它？但这样我可能会损坏文件列表，无法恢复它。因此，最好将文件列表存储在bucket中，但我不确定是否遗漏了什么。
对于加密，正如我所说，简单的xor对我来说很好，但是如果我需要更好的东西（和更多的资源需求），我可以添加一些aes-有很多库可以完成这个任务。我还想加密文件列表。但我不确定我应该如何处理文件-我应该单独加密每个文件还是应该加密整个bucket？
我最关心的是可靠性。如何检查存档中的文件是否未损坏？腐败是我把档案藏在桶里的原因之一。如果数据损坏，则只有一个或多个存储桶会损坏。但如何发现腐败呢我可以计算校验和，但我不确定如何快速计算，以及应该为单个文件计算哪些校验和？整桶？以及使用什么算法来避免由于计算校验和而使备份过程变得太慢？
我可以按如下方式实现重复数据消除在备份期间，内存中同时有两个文件列表（服务器和本地）。如果我遇到两个文件名，我可以进行校验和，看看它们是否相同，如果相同，我只将文件存储在一个存储桶中，但在第二个存储桶的文件列表中，我会标记该文件与第一个存储桶中的另一个文件重复，并且当从存档中还原时，我可以提取该文件并把它复制到两个地方。
所有这些问题都让我产生了一个异端的想法——也许我可以使用git？
但我怀疑它是备份100GB数据的好工具。至少，我可以从git中学到一些有用的技巧，但我仍然不确定哪些想法会或不会用于备份目的。
如果有人做过类似的实现，听到你的经验会很好，也许会听到一些想法和警告，这些想法在直觉上看起来是对的，但在实践中可能会变得不好。

Answer 1

这是一个非常雄心勃勃的目标，创建一个非常通用的安全备份系统。虽然你可以很好地完成你想要做的事情，但是它可能会比预期的要花费指数级的时间，因为每一个单独的部分，比如异或数据和文件名，都可能是非常耗时的检查，逻辑错误可能会以一路丢失有价值的数据为代价。
一个建议是重新评估所有现有的商业选项，确定它们离精确需求有多近，比如80%、70%、90%……然后问：“商业工具不值得拥有的大量X小时是否值得大量的工时和可能的数据损失，我不仅要在其他地方重新发明70%、80%、90%，而且还要也可以加上剩余的x%。”或者，联系一个供应商并说“嘿，让我们一起工作，让你的工具多做x%。”会更容易吗？我想成为一名测试人员。”
有一些公司花了很多时间开发和测试商业产品，这些产品已经通过了多年的审查。在滚动自己的解决方案的同时，有时也支持现有的商业软件供应商，他们将数据加密、拉链、散列、混淆等作为全职工作。利用他们的经验，并与他们合作，以实现一个伟大的解决方案。