我们的MySQL数据库服务器托pipe几十个数据库，转储文件大小从1到100 MB。
目前，我们的备份方法是mysqldump ，包装在shell脚本中，并从crontab运行。 这对我们来说很好。 唯一的主要缺点是存储转储文件的存储需求很大。
由于MySQL数据库转储是一个文本文件，当然我会考虑将其存储在一个版本控制系统中，比如Subversion。 我记得Subversion只存储每个提交中的文件的增量。
这种方法build议吗？ 有什么我们应该注意的陷阱？
SirStan提到的binlog是很好的方法。
也可以运行mysqldumps，然后使用rdiff-backup创builddumpfile的备份。 rdiff会保留n个最后的备份[你决定有多less]，并且会相当节省空间，因为它只保留最近版本的文件+一组差异的完整快照，允许它重build以前的版本。
不pipe你放在svn里，都留在svn里。 版本库只会增长 – 所以这是保持你的sql模式，源代码和文档的好地方; 但不是来自sql的实际数据。
MySQL文档可能正是你所需要的。 二进制增量备份！ （对于通过rsync / ftp / etc的穷人奴隶服务器也是很好的）。
MySQL支持增量备份：
必须使用–log-bin选项启动服务器才能启用二进制日志logging; 请参见第5.2.4节“二进制日志”。 二进制日志文件为您提供了在执行备份之后复制对数据库所做的更改所需的信息。 目前您想要进行增量备份（包含自上次完全备份或增量备份以来发生的所有更改），则应使用FLUSH LOGS旋转二进制日志。 完成之后，需要将所有二进制日志复制到备份位置，范围从最后一次完整备份或增量备份时刻到最后一次备份完成。 这些二进制日志是增量备份; 在恢复时，可以按照第6.3节“时间点恢复”中的说明应用它们。 下次进行完全备份时，还应该使用FLUSH LOGS，mysqldump –flush-logs或mysqlhotcopy –flushlog来旋转二进制日志。 请参见第4.5.4节“mysqldump – 数据库备份程序”和第4.6.9节“mysqlhotcopy – 数据库备份程序”。
使用svn会占用大量的空间。
说你提交100MB的文件和SVN成为1版，那么如果你添加一个200MB的新文件，版本将是2。
你的svn仓库将是300mb。
如果你在第一版中像你的文件一样的话，你将不得不svnrepourl
我知道这个问题有点过时，但在我的公司，我们一直在尝试类似的东西。 我们一直在拉取xml格式的备份（不是来自MySQL，而是简单的文本文件），大小约为300 MB，每天晚上将其提交到一个SVN存储库。 第一次提交将存储库设置为41 MB，但每次提交都较小。 我们现在处于修订版本8，版本库的总大小是57 MB。 这是它包含的所有历史的大小的2.5％！
我刚刚尝试使用相同的数据rdiff备份; 下面是一个比较（所有大小以MB为单位）：
备份＃备份大小回购大小三angular洲rdiff大小三angular洲 0 0 0.03 0.03 0 0 1 286.05 41.49 41.46 286.05 286.05 2 285.93 45.97 4.49 322.13 36.08 3 286.23 50.52 4.54 323.27 1.14 4 286.63 50.79 0.27 324.54 1.26 5 287.46 55.52 4.73 326.54 2.00 6 287.76 55.77 0.25 327.72 1.19 7 288.15 56.14 0.37 328.98 1.26 8 288.41 56.63 0.50 330.36 1.38
看起来像增量差不多（有时svn更好，有时rdiff备份是），所以在整体规模上，SVN赢了。 rdiff的一个好处是，很容易删除旧的备份，在SVN中你必须做一个svnadmin转储和svnadmin加载来摆脱旧的版本。 我想这是一个偏好的问题，但SVN易于使用，并有大量的工具来支持它。
看看这个脚本自动化的过程，允许特定的数据库select和排除表[免责声明我是作者] – http://mysql-svn-backup.redant.com.au/
Percona XtraBackup支持MySQL数据库的增量热备份。