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