使用cron自动备份我的数据库和文件

1）如果你坚持在颠覆中存储备份，那么这种方法没有任何错误。 不过，这很奇怪。

2）你应该保持结账，将转储放到工作目录中，并在提交之前适当地运行svn update和svn add 。

3）如果你从shell脚本运行命令，应该没有重叠。

另外请注意，压缩mysql输出会创build大不相同的二进制文件，并导致您的存储库磁盘需求膨胀。 使用未压缩的sql可能需要更多的初始空间，但文本差异将更有效地存储在存储库中。 另外，不需要将每个文件存储为名称中的date的单独文件。 也可能是同一个文件，因为版本控制会让你回到时钟。

我更喜欢使用类似于最近7天的压缩sql的备份来进行备份，然后快照一个月或两个月。 我没有看到需要版本控制数据库的所有永恒。

正如我所说的将数据库保存在SVN存储库中不是一个好的做法。

关于mysqldump，请记住，以这种方式你也包括这些选项（–opt是下面的简写的默认值）：

 --add-drop-table --add-locks --create-options --disable-keys --extended-insert --lock-tables --quick --set-charset 

因此，如果您将使用您创build的完整转储，则会覆盖上次执行的备份后插入的所有数据。

直到你的数据库将会像你所说的那么小，我build议你更频繁地进行备份。

这是一个很好的例子，你可以继续。

如果你的数据库很大，存储数百个数据库的副本将会超过你的存储容量，可能会让你无所事事，忙于其他事情。 gzip压缩几乎肯定会受到伤害，因为它阻碍了SVN在修订之间压缩的能力 ，我认为SVN已经在内部使用了一个zip库。 您可能需要花费几天的时间进行备份，并尝试两种方式，并查看哪一个使用较less的磁盘。 以某种方式命令转储可能也是有帮助的，比如用 – order-by-primary ; 否则，SVN将不得不浪费磁盘代表mysqldump的轻率重新sorting，你不关心。

但最终你不得不丢弃数据。 我见过的一个有趣的方法是“对数备份”的名字。 这个想法是，较新的备份比较旧的备份更重要，所以您可以节省更多的备份，并随着年龄的增长过期。 所以你最终结束了

• 每周7次的备份
• 去年12个月的备份
• 1年前的年度备份。

这是RRDtool的一个类似的方法，数据被合并到一个代表性的对象中。 你总共有20多个备份，以及恢复最近过去的短期数据和从遥远的过去的长寿命数据的能力。

其实回答这个问题

由于您的数据相对较小，而且可能不会有太大变化，所以SVN可能不是一个坏的方法。

我有一个类似的过程，把感兴趣的网站放到SVN中，我已经修改它来适应你的需求。 把这个放在你的cron.daily或者whellver中，它会帮你完成的。 您将需要首先初始化回购，并调整以适应您的需求，但这是一个好的开始：

 #!/bin/bash # check out to temp dir DIR=`mktemp -d` cd $DIR # check out repository svn co $1 . # dump db mysqldump --order-by-primary -u root -pPASSWORD database_name # if changed, commit svn commit -m 'Nightly backup' cd .. rm -rf $DIR 

有关使用automysqlbackup执行备份的自动转储，然后使用BackupPC创build自动pipe理的全/差异？

BackupPC硬链接不同备份内的未更改文件，以最大限度地减less磁盘空间使用。

http://sourceforge.net/projects/automysqlbackup/

http://backuppc.sourceforge.net/

将你的数据库转储到一个文件，并提交该文件svn是一个很好的方法。 有几件事情我build议改变，虽然…你应该覆盖同一个文件每次转储（删除date从文件名），并删除压缩。

就像编辑你的源代码一样，你本质上是修改数据库转储文件。 另外，正如其他人所提到的，如果你不压缩它，从长远来看它会在服务器上压缩得更好，因为差异会小得多。

这种方法的重要之处在于它在特定时间将数据库与代码结合在一起。 例如，你需要运行修订版1428.没问题…更新你的本地回购到版本1428，你有所有的代码和数据库转储运行1428.加载该转储，编译你的代码，在业务。