我有一个使用rdiff进行在线备份的产品。目前发生的是：
将文件复制到临时区域（因此在我们处理文件时文件不会消失或被修改）
散列原始文件，并计算rdiff签名（用于差异差分） 计算rdiff delta差异（如果我们没有先前版本，则跳过此步骤）
压缩＆amp;加密产生的差异
目前，这些阶段彼此截然不同。最终结果是我们多次遍历文件。对于小文件，这不是什么大问题（特别是给定磁盘缓存），但对于大文件（10或甚至100的GB），这是一个真正的性能杀手。
我想将所有这些步骤合并为一个读/写传递。
为此，我们必须能够以流式方式执行上述所有步骤，同时仍然保留所有“输出” - 文件哈希，rdiff签名，压缩＆amp; amp;加密差值差异文件。这将需要从源文件中读取一个数据块（例如，100k？），然后在内存中迭代文件以更新散列，rdiff签名，执行增量差异，然后将输出写入压缩/加密输出流。我们的目标是大大减少磁盘颠簸的数量。
目前，我们使用rdiff.exe（它是底层librsync库之上的一个薄层）来计算签名并生成二进制增量。这意味着这些是在单独的过程中完成的，并且以一次性而非流式方式完成。
如何使用librsync库来实现我的目的？
答案 0 :(得分：0)
您可以完全跳过第1步。文件打开时无法删除，打开文件时选择适当的锁定标志也可以防止它被修改。例如，CreateFile函数采用dwShareMode参数。
在开始创建rdiff delta之前，您需要计算整个rdiff签名。您可以通过计算签名然后一次为文件的每个（例如）100 MB块增加分数来避免读取整个文件。你会以这种方式失去一些压缩效率*。您也可以考虑从rdiff切换到xdelta，这可以通过输入一次创建一个增量文件。
压缩和加密可以与计算delta相关联。如果压缩和加密是由单独的程序完成的，它们通常允许从标准输入读取并写入标准输出。这可以通过批处理文件中的管道最简单地使用，例如：
rdiff signature oldfile oldfile.sig
rdiff delta oldfile.sig newfile | gzip -c | gpg -e -r ... > compressed_encrypted_delta
如果在程序中使用库进行压缩/加密，则需要选择支持流操作的库。
*如果数据在文件中移动，则会失去很多效率。如果有人将100 MB预先设置为10 GB文件，rdiff将生成大约100 MB的增量文件。 rdiff一次以100 MB或更少的块完成，将产生大约10 GB的delta。 200 MB的块将产生大约5 GB的delta，因为每个块中只有一半的数据来自旧版本文件的相应块。