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