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