我希望mysqldump用 Percona 的 Xtrabackup 替换老化且明显不理想的基于 的数据库备份策略。这一切看起来都很简单，只是我想知道：在完整备份之间我应该保留多少个增量备份？
我意识到从一长组增量中进行恢复会有些繁琐，但看起来编写脚本相当容易。
我还想象，如果我不知何故丢失了备份集中的增量，那么从那时起，我将失去一切。这似乎不太可能（这些人将转向 S3），但仍然是糟糕的一天。
这类事情有经验法则吗？每周进行一次完整备份（即每组备份 168 个文件）是否太疯狂了，还是对于某些工作负载而言是正常的？
值得一提的是，我们正在研究一个约 10M 行的数据库，每天增长约 20k 行，很少有更改的行（即大部分是追加的）。因此增量会非常小。
答案1
很难说什么是最好的备份策略 - 这完全取决于您的数据的价值，以及如果您丢失最后 X 个小时的数据将支付的损失。
您正确地指出了增量版本的问题 - 如果您丢失了一个，那么之后的所有内容都会丢失。另一个问题是，如果完整版本损坏，那么您将丢失所有内容，就是这样。
现在，认识到这一点，备份规划是平衡备份成本和数据丢失成本的精细艺术。
如果您仅依赖一个主数据库，并希望每小时进行增量备份，我建议您尽可能频繁地进行完整备份，只要您的链接可以将它们上传到 S3。因此，例如，如果您可以在 4 小时内将完整备份上传到 S3，那么每天都这样做。
但是，为了获得更好的效果，我建议设置主从复制，并备份二进制日志。这样，只要二进制日志保留数据，您就可以计划进行增量备份。如果增量失败，您可以进行完整备份恢复，然后重播日志。额外的好处是在从服务器上备份，因此不会对主服务器（和用户）造成性能损失。