Log*_*acy 6 svn windows backup visualsvn-server
我有大约十几个存储库,文件系统的大小为1 GB到10 GB,我需要为我们的XP 64设置所有这些存储库的自动备份(我们的旧备份脚本在计算机出现故障时丢失)钻头机器.
在阅读了关于备份SVN repos的最佳方法的这个问题后,我开始抛弃我们拥有的最大回购,大约是13 GB.这个命令现在已经执行了大约2.5个小时,并且它目前正在倾倒大约200个300的修订版.
svnadmin --deltas \\path\to\repo\folder > \\path\to\backup\folder\dump.svn
转储文件超过100 GB并且正在计数.我知道我可以7-zip这个吸盘,但100 GB ?! ...... o_O
存储库包含大量二进制数据,这可能是问题的一部分,但截至目前,切换到更有效的版本控制系统(假设有一个)是不现实的; SVN是这里生活的一部分.
我考虑过使用hotcopy,它占用的空间要少得多,但我尝试使用旧的热备份备份,而subversion 1.7找不到它需要的一堆文件.似乎我必须安装最初热门复制repo的SVN版本,并转储该repo以使其进入更新的SVN.这句话似乎验证了我在hotcopy中遇到的问题:http://svn.haxx.se/users/archive-2005-05/0842.shtml
我觉得像我刚才已经有失踪的东西.也许有一些倾倒的标志,神奇地使倾倒1/5大小...
我还有其他选择吗？
更新:最后一个修订版#327刚刚被转储.转储文件的最终大小为127 GB.这是一个13.5 GB的回购.在我的所有存储库中,我可能大约相当于3倍.
对于每日备份,我会说你真的不需要做svnadmin dump.如果您要将存储库转移到可能运行不同SVN版本和操作系统的新服务器,我将使用dump方法,因为它是转储存储库的最便携方式,但它不是非常节省空间.
我建议使用引用该链接的hotcopy方法.这将保证文件系统的状态是一致的,并且还将复制配置文件和钩子脚本(顺便说一句,svnadmin转储不会复制这些,因此您最终会得到不完整的备份).因为它只是存储库的直接副本,所以它的大小相同,因此备份应该更易于管理.
在紧急情况下,如果您需要从hotcopy恢复备份,那么您应该需要的是具有相同主要版本SVN(例如1.6或1.7)的机器,并且是安全的,相同的操作系统.您应该可以直接使用此存储库,或者您可以svnadmin dump在此时执行传输到新服务器.
编辑:svnsync和hotcopy的比较:
共同方面:
hotcopy的优点:
svnsync的优点: