我问过堆栈溢出，但有人指出最好在这里问。
假设 Subversion 和 MySQL 位于 RAID NAS 上。备份数据的最佳实践是什么？
我正在考虑将 mysqldumps 置于 subversionn 控制之下，然后也许通过 7zip 压缩整个内容来定期备份 svn 存储库。
除非您将 svn 备份存储在不同的物理硬盘上，否则备份存储库似乎没有帮助。这是真的吗？如果不是，为什么？
最后，多久备份一次，保存多少份？
答案1
首先，不要对数据库备份进行版本控制。
备份就是备份 - 某个时间点。使用版本控制听起来是个好主意，但要意识到这意味着你需要恢复整个 SVN 存储库（ZOMG Freaking巨大的）如果您遇到灾难性故障并需要恢复数据库。这可能是您无法承受的额外停机时间。
其次，确保您的备份以某种方式移出现场。
如果您因为弄乱并删除了表而需要恢复数据，那么本地机器上的备份是很好的选择。如果您的服务器磁盘坏了，那么这对您来说绝对没有好处。
选项包括外部硬盘或使用 rsync 将备份发送到远程机器。甚至还有存储服务提供商比如 rsync.net专门从事该项工作。
第三，关于备份频率：只有您知道需要多久进行一次备份。
我目前的公司有一个从属数据库，可以近乎实时地复制我们的生产数据。该从属数据库每晚都会备份到本地计算机，然后同步到异地存储设施。
如果发生生产硬件故障，我们会激活从属数据库。数据丢失应该最小，停机时间也应该最小。如果意外删除了表，我们可以从本地备份中恢复（最多丢失 1 天的数据）。如果发生灾难性事件，我们可以从异地备份中恢复（这需要一段时间，但同样只会丢失最多 1 天的数据）。
这种备份方案是否适合您取决于您的数据：如果它经常更改，您可能需要研究一种可让您进行时间点恢复的备份策略（日志传送解决方案通常可以做到这一点）。如果它主要是静态的，您可能只需要每月备份一次。关键是确保您在数据更改后的合理时间内捕获更改，确保您不会在发生重大事件时丢失这些更改。
答案2
一般建议：
- 监控你的备份
- 检查它们是否成功完成[例如，mysqldump 搜索终点线的初始结果；检查 dump 命令返回的错误代码]，
- 如果备份大小合理
- 偶尔运行恢复测试 - 可能每 3-6 个月一次
- 备份到离线媒体，这样在遭受恶意攻击时就不会丢失数据
- 将备份保存在异地，这样在发生自然灾害时就不会丢失数据
具体建议：
- 将 mysqldumps 传输到 svn 进行版本控制听起来有点小题大做 - 从 svn 中删除任何东西都很困难。如何使用rdiff-备份保留上次备份以及之前几个备份的“差异”？
- svn - 使用 svnadmin dump - 这是获取 svn 转储的“正确”方法
- 如果你想要更加安全 - 使用 lvm 并对 mysql 和 svn 数据目录额外进行 lvm 快照
- 使用 innodb 存储引擎使备份无锁
答案3
在制定备份策略时，您首先应该评估恢复点目标 (RPO) 和恢复时间目标 (RTO)。RPO 表示企业在发生事故时愿意丢失多少数据，而 RTO 表示恢复所需的时间。您对 RTO 和 RPO 的要求将决定维护备份的经济和性能成本。[1]。
一般有四种备份策略：
- 服务器副本：使用另一台服务器，物理和逻辑上与主数据库服务器分开，并且每当将数据写入数据库时也会写入复制数据库。
- 数据库转储：定期将数据库转储到文件并将该文件发送到备份服务器。
- 数据库快照：使用任何文件系统快照工具，如快照对数据库的底层数据文件进行定期快照并发送到备份服务器。
- 基于云和代理：您只需在数据库服务器中安装一个代理，并定期将其备份到云。
每种方法都有其优点和缺点，可以从不同的角度进行比较：
非阻塞：所有方法都不需要停止对数据库的写访问以进行备份，除非数据库快照在某些情况下，例如在 mongodb 中启用日志功能时，即使使用 LVM 快照也不能保证快照的一致性和有效性。
增加的：转储和快照通常不是增量的，因此备份速度低于其他方法。副本和云方法本质上是增量的。
工作量：快照对数据库没有负载，因为只是复制了底层文件。转储负载最大。在其他方法中，工作负载分布在数据库工作时间内。