我有十几个存储库，文件系统的大小为1 GB到10 GB，我需要为所有这些存储库设置自动备份（我们的旧备份脚本在计算机出现故障时丢失） XP 64位计算机。
在阅读this question关于备份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倍。
答案 0 :(得分：6)
对于每日备份，我会说你真的不需要svnadmin dump。如果您要将存储库转移到可能运行不同SVN版本和操作系统的新服务器，我将使用dump方法，因为它是转储存储库的最便携方式，但它的空间效率不高。
我建议使用该链接引用的hotcopy方法。这将保证文件系统的状态是一致的，并且还将复制配置文件和钩子脚本（顺便说一句，svnadmin转储不会复制这些，所以你最终会得到一个不完整的备份）。因为它只是存储库的直接副本，所以它的大小相同，因此备份应该更易于管理。
在紧急情况下，如果您需要恢复从hotcopy完成的备份，那么您所需要的只是具有相同主要版本SVN（例如1.6或1.7）的机器，并且是安全的，相同的操作系统。您应该然后可以直接使用此存储库，或者此时您可以执行svnadmin dump传输到新服务器。
编辑：svnsync和hotcopy的比较：
常见方面：
hotcopy的优点：
svnsync的优点：
答案 1 :(得分：4)
感谢bahrep和the_mandrill的建议，我决定使用svnsync来获取这些存储库。我能够很容易地设置它，因为我们没有任何钩子或配置文件，所以没有别的东西可以备份。由于我在hotcopy中遇到的问题（感谢the_mandrill提出解决这些问题的方法），我认为svnsync对我们来说是更简单的解决方案。
除了the_mandrill所指出的，svnsync还有其他优点：
要设置svnsync，我必须完成以下步骤。请原谅任何错别字。我们所有的存储库都使用VisualSVN Server托管。
创建一个新的空存储库：
svnadmin create \\computerB\C$\repositories\mirror
创建文件\mirror\hooks\pre-revprop-change.bat。它的唯一内容是这一行：
exit 0
初始化同步
svnsync init https://computerB.domain.net/svn/mirror https://computerA.domain.net/svn/repo
同步两个回购
svnsync synchronize https://computerB.domain.net/svn/mirror https://computerA.domain.net/svn/repo
答案 2 :(得分：1)
从VisualSVN Server 3.6开始，您可以使用Backup-SvnRepository PowerShell cmdlet来备份Subversion存储库。恢复
来自备份的存储库，使用Restore-SvnRepository cmdlet。
此外，服务器的企业版提供scheduled backup feature。内置的计划备份supports several backup types including incremental backups，在存储空间和备份所需的时间方面都很有效。