我在stackoverflow上问过这个问题，但是有人指出在这里问一下会更好。
让我们假设一个RAID NAS上的Subversion和MySQL。 备份数据的最佳做法是什么？
我正在考虑将mysqldumps置于subversionn控制之下，然后可能会定期备份svn库，方法是将所有东西压缩。
除非您将svn备份存储在不同的物理硬盘驱动器上，否则似乎不需要备份存储库。 这是真的？ 如果没有，为什么？
最后，应该多久进行一次备份，还应该保存多less？
首先，不要版本控制你的数据库备份。
备份是一个备份 – 一个时间点。 使用版本控制听起来像一个不错的主意，但意识到这意味着如果你有一个灾难性的失败，需要恢复数据库，你将需要恢复整个SVN仓库（ZOMG Freaking HUGE ）。 这可能是额外的停机时间，你买不起。
其次，确保你的备份以某种方式离开网站。 如果您需要恢复数据，本地计算机上的备份非常好，因为您已经搞乱了，并且丢弃了一张表。 如果你的服务器的磁盘死了，你绝对不会这么做。
选项包括外部硬盘驱动器或使用rsync将备份传送到远程机器。 甚至还有像rsync.net这样的存储服务提供商。
第三，关于备份的频率：只有你知道你需要多久才能做到这一点。
我现在的公司有一个从属数据库，可以近乎实时地复制我们的生产数据。 该奴隶每晚备份到本地机器，然后同步到异地存储设备。
在生产硬件故障的情况下，我们激活从站。 数据丢失应该是最小的，应该是停机时间。 在发生意外删除的情况下，我们可以从本地备份中恢复（最多丢失1天的数据）。 在发生灾难性事件的情况下，我们可以从场外备份恢复（这需要一段时间，但是只会丢失最多1天的数据）。
这种备份scheme是否适用于您取决于您的数据：如果它频繁更改，您可能需要调查一个备份策略，以实现您的时间点恢复（日志传送解决scheme通常可以做到这一点）。 如果它大部分是静态的，你可能只需要每月备份一次。 关键在于确保在合理的时间内捕获数据的变化，确保在发生重大事件时不会丢失这些变化。
通用build议：
具体的build议：