Duplicity 完整备份生命周期和效率

Question

我正在尝试为某些客户端制定备份策略，并且倾向于远程备份的双重性（已经将 rdiff-backup 用于内部/本地备份）。

每隔一段时间进行一次完整备份是否合理？由于重复性向前递增，因此每个增量备份都依赖于前一个增量，并且都严重依赖于最后一个完整备份。如果它变得腐败，坏事就会发生。一个相关的问题：Duplicity 是否会测试增量备份的一致性？

假设我确实需要经常进行完整备份，duplicity 创建完整备份的效率如何？它可以/是否检查文件签名并从以前的完整备份/增量复制未更改的数据？基本上是创建一个新的“完整”存档来传输新的/更改的数据并合并现有的未更改数据？

现在我担心的是需要运行完整备份，但是完整备份的一致大带宽使用会使某些客户端不合理。

Answer 1

我认为每隔一段时间进行一次完整备份是合理的：我的大多数机器都配置为每隔几个月进行一次。这个数字没有什么神奇之处：正确的值将取决于您拥有的数据量、数据变化的速度、您想要从最新快照以外的任何内容恢复的可能性、您需要多少流量和存储成本，以及你是多么的偏执。其他人可能希望每周进行一次完整备份。

除非您不时进行完整备份，否则存档大小和恢复时间将继续增长。

我不认为双重性特别有“检查”命令http://pad.lv/660895，但如果有的话会很好。每隔一段时间进行一次测试恢复是非常谨慎的。

一个相关的问题是您是否应该保留多个备份链。再次，这取决于成本。保留一个的原因之一是，如果当前链损坏，您可以从中恢复，无论是由于硬件故障、操作系统故障还是双重错误。当然，如果旧链很旧，从它恢复可能价值有限。

进行完整备份始终会上传数据的完整副本。

如果客户端关心的是使用的带宽的一部分，而不是流量费用，您可能希望在例如trickle.

Answer 2

您所要求的称为合成完整备份，它是指通过将增量备份与目标端（即：备份服务器）上的先前完整备份合并来获得完整备份的过程。

我不熟悉 Duplicity，但从他们的网站上看，它似乎没有进行合成完整备份。您必须将所有增量保持在它们所基于的完整状态。如果是这种情况，您可能希望每隔一段时间强制执行一次完整备份，因为：

• 经历一百万次增量可能会使恢复变慢
• 你可能不想让增量回到时间的开始

实现合成 fulls 的一种有趣方法是将rsync 与 --link-dest=DIR选项一起使用，或使用rsnapshot。它只会存储每个增量备份之间的差异，但每个增量备份都会看起来已满。当您删除其中任何一个时，它会自动适当地合并增量。它通过硬链接的魔力来实现这一点，因此差异将基于文件（文件已更改并包含在差异中，或者未包含）。