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