1

我有一个使用 rdiff 进行在线备份的产品。目前发生的情况是：

  1. 将文件复制到暂存区域（这样文件在我们处理时不会消失或被修改）

  2. 散列原始文件，并计算 rdiff 签名（用于差异差异） 计算 rdiff 差异差异（如果我们没有先前版本，则跳过此步骤）

  3. 压缩和加密产生的增量差异

目前，这些阶段的执行方式各不相同。最终结果是我们多次迭代文件。对于小文件，这没什么大不了的（尤其是考虑到磁盘缓存），但对于大文件（10 甚至 100 GB），这才是真正的性能杀手。

我想将所有这些步骤整合到一个读/写通道中。

为此，我们必须能够以流方式执行上述所有步骤，同时仍保留所有“输出”——文件哈希、rdiff 签名、压缩和加密的增量差异文件。这将需要从源文件中读取一个数据块（比如 100k？），然后在内存中迭代文件以更新哈希、rdiff 签名、进行增量差分，然后将输出写入压缩/加密输出流. 目标是大大减少我们所做的磁盘抖动量。

目前我们使用 rdiff.exe（它是底层 librsync 库之上的一个薄层）来计算签名并生成二进制增量。这意味着这些是在一个单独的过程中完成的，并且是一次性完成的，而不是流式的。

我怎样才能使用 librsync 库来做我需要的事情？

4

1 回答 1

0

您可能可以完全跳过第 1 步。该文件在打开时不能被删除，并且在打开它时选择适当的锁定标志也可以防止它被修改。例如，CreateFile函数采用 dwShareMode 参数。

在开始创建 rdiff 增量之前，您需要计算整个 rdiff 签名。您可以通过计算签名来避免读取整个文件，然后每次对文件的每个（例如）100 MB 块进行增量。这样会损失一些压缩效率*。您也可以考虑从 rdiff 切换到xdelta，这可以在输入的单次传递中创建一个增量文件。

压缩和加密可以与计算增量并行完成。如果压缩和加密由单独的程序完成，它们通常允许从标准输入读取并写入标准输出。这可以通过批处理文件中的管道最简单地使用，例如：

rdiff signature oldfile oldfile.sig
rdiff delta oldfile.sig newfile | gzip -c | gpg -e -r ... > compressed_encrypted_delta

如果您在程序中使用库进行压缩/加密，则需要选择支持流操作的库。

*如果数据在文件中四处移动，则会失去很多效率。如果有人在 10 GB 文件前添加 100 MB，rdiff 将生成大约 100 MB 的 delta 文件。一次以 100 MB 或更少的块完成 rdiff 将产生大约 10 GB 的增量。200 MB 的块将产生大约 5 GB 的增量，因为每个块中只有一半的数据来自旧版本文件的相应块。

于 2011-02-16T23:53:53.920 回答