svn备份的方式有三种：
1svnadmin dump
2)svnadmin hotcopy
3)svnsync.
优缺点分析
==============
第一种svnadmin dump是官方推荐的备份方式，优点是比较灵活，可以全量备份也可以增量备份，并提供了版本恢复机制。
缺点是：如果版本比较大，如版本数增长到数万、数十万，那么dump的过程将非常慢；备份耗时，恢复更耗时；不利于快速进行灾难恢复。
个人建议在版本数比较小的情况下使用这种备份方式。
第二种svnadmin hotcopy原设计目的估计不是用来备份的，只能进行全量拷贝，不能进行增量备份；
优点是：备份过程较快，灾难恢复也很快；如果备份机上已经搭建了svn服务，甚至不需要恢复，只需要进行简单配置即可切换到备份库上工作。
缺点是：比较耗费硬盘，需要有较大的硬盘支持（俺的备份机有1TB空间，呵呵）。
第三种svnsync实际上是制作2个镜像库，当一个坏了的时候，可以迅速切换到另一个。不过，必须svn1.4版本以上才支持这个功能。
优点是：当制作成2个镜像库的时候起到双机实时备份的作用；
以上不是自己观点，下面真实记录我的svn sync实验过程
两台机器
server1: 192.168.1.224
server2: 192.168.1.225
都是centos6.5环境
首先在sever1上搭建好了一个svn，然后模拟提交了一些东西
然后在sever2上搭建了一个一模一样的svn，保持空的
现在的目的是将server1同步备份到server2
在server1上直接运行:
svnsync init svn://192.168.1.225/ svn://192.168.1.224/
即svnsync init 目标svn链接 源svn链接，执行同步之前的初始化
这一步失败了，报如下错误：
svnsync: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook
提示需要在hooks下面创建一个pre-revprop-change hook
简单解释下，hook类似于操作系统的勾子，svn会在收到一些操作请求的时候执行hooks目录下的对应的脚本，例如想要commit的时候做一些事情就可以在对应的脚本下面添加你要执行的命令，下一次在commit 的时候就会触发执行
一开始没明白，不知道应该在源机器上创建还是在目标机器上创建，其实是在目标机器上创建的
然后在目标机器上copy了一份pre-revprop-change.tmpl成pre-revprop-change
再次执行初始化命令
依然报错，这次的错误不一样了
svnsync: Revprop change blocked by pre-revprop-change hook (exit code 255) with no output.
大概就是同步的过程中刚刚创建的hook调用没有成功，然后尝试给pre-revprop-change添加可执行权限，依然失败
依然失败，依然失败，在stack overflow上看到有人提出的解决方法是把pre-revprop-change改成下面这个样子：
#!/bin/sh
exit 0
再次初始化，终于成功，提示先让你输入用户名密码，最后一步的输出如下：
后来经过验证，确实需要可执行权限，改了之后还是失败的原因是hooks执行的结果是失败的，确实执行了
这一步成功之后，下一步同步就直接成功了：
svnsync sync svn://192.168.1.225/
执行这个命令会把没有同步的版本都同步过去
然后为了让server1每次有更新之后都自动同步到server2，可以在server1的commit的hooks最后加上执行一下同步的命令：
svnsync sync svn://192.168.1.225/
这样就完美实现了实时备份，而且在server1出现问题的时候随时都可以直接切换到server2哟
最后有一点要注意的是，我尝试备份到一个不为空的svn，也就是目标svn已经存在要备份的repos的时候，是会失败的，因此，只能备份到一个空的svn
最后还有一个非常重要的要注意的问题就是，如果在直接在目标在做了修改的话，那么后面就没有办法同步了，都会失败，所以，禁止在备份svn上直接做任何操作，这里的花建议专门写一个脚本，在post-commit勾子里面调用，通过脚本来同步，然后判断一下是否同步成功，如果同步失败了需要及时处理，比如可以给相关人员发邮件通知及时处理，防止同步失败了导致server1一旦宕机之后突然发现server2早就没有同步了就晚了。