我正在尝试为某些客户端制定备份策略，并且倾向于对远程备份进行重复（已经使用 rdiff-backup 进行内部/本地备份）。
每隔一段时间进行一次完整备份是否合理？由于重复性向前递增，每个增量备份都依赖于前一个增量，并且所有备份都严重依赖于最后一次完整备份。如果它变得腐败，就会发生坏事。一个相关问题：Duplicity 是否测试增量备份的一致性？
假设我确实需要每隔一段时间进行一次完整备份，那么重复性创建完整备份的效率如何？它可以/是否检查文件签名并从以前的完整备份/增量中复制未更改的数据？基本上是创建一个新的“完整”存档来传输新的/更改的数据并合并现有的未更改数据？
现在我担心的是需要运行完整备份，但是完整备份的一致大带宽使用将使某些客户端不合理。
我认为每隔一段时间进行一次完整备份是合理的：我的大多数机器都配置为每隔几个月执行一次。这个数字没有什么神奇之处：正确的值取决于您拥有多少数据、它的变化速度、您希望从最新快照以外的任何内容中恢复的可能性、您需要多少流量和存储成本，以及你有多偏执。其他人可能希望每周进行一次完整备份。
除非您不时进行完整备份，否则存档大小和恢复时间将继续增长。
我不认为 duplicity 专门有一个“检查”命令http://pad.lv/660895，但如果有的话会很好。每隔一段时间进行一次测试恢复是非常谨慎的。
一个相关的问题是您是否应该保留多个备份链。同样，这取决于成本。保留一个的原因之一是，如果当前链因硬件故障、操作系统故障或重复性错误而损坏，您可以从中恢复。当然，如果旧链很旧，从它恢复可能价值有限。
进行完整备份始终会上传数据的完整副本。
如果客户关心的是所用带宽的比例，而不是流量费用，您可能希望在例如
trickle.您所要求的称为合成完整备份，它是指通过将增量备份与目标端（即：备份服务器）上的先前完整备份合并来获得完整备份的过程。
我不熟悉 Duplicity，但从他们的网站上看，它似乎没有进行合成完整备份。您必须将所有增量保持在它们所基于的完整状态。如果是这种情况，您可能希望每隔一段时间强制执行一次完整备份，因为：
实现合成完整的一种有趣方法是将rsync 与 --link-dest=DIR选项一起使用，或使用rsnapshot。它只会存储每个增量备份之间的差异，但每个增量备份似乎都已满。当您删除其中任何一个时，它将自动适当地合并增量。它通过硬链接的魔力做到这一点，因此差异将基于文件（文件已更改并包含在差异中，或者不包含）。