1 现状

1.1 服务器

目前SVN服务器占用磁盘空间40G，实际使用10G，已过期文件30G。---后研究发现40G内容均为实际内容，Copyto操作相当于创建了一个新的指针，实际内容并没有被复制。

1.2 备份方式

直接利用RAR压缩，执行一次备份需要8.5小时以上。且生成文件较大，难以传输，致命问题是恢复备份的时间不可估计。-----打算采用分卷压缩，还是比较傻

2 SVN备份方案研究

2.1 hotcopy

命令行：svnadmin hotcopy d:\svnhome d:\svnBackup

效果：完全备份，创建完全一致的目录及内容。

优点：恢复速度可忽略不计。

缺点：磁盘占用空间较大，等于服务器文件空间。

恢复策略：停止服务，删除根目录，重命名备份文件夹为原根目录，重启服务。

备注：执行此命令时可对服务器进行其他操作，不保证结果是最新版本。建议停止服务后操作。

2.2 dump

命令行：1.svnadmin dump d:\svnhome > d:\svnBackup.20100421

2.svnadmin dump d:\svnhome –revision 15 –incremental > d:\svnBackup.15

效果：按照版本完全/增量备份

优点：可执行增量备份（需提供版本号）

缺点：完全备份时间很长，生成文件大，恢复速度很慢

恢复策略：svnadmin create d:\newsvnhome

Svnadmin load d:\newsvnhome < d:\svnBackup.svn

3 方案

3.1 脚本

根据实际情况，现行制定的方案为采用hotcopy的方式编写脚本，并于每周日晚8点定制计划任务自动执行。

脚本内容：

@echo off

:: SVN根目录

set SVN_HOME="D:\svn_repository"

:: SVN备份目录

set SVN_BACKUP="D:\svnBackup"

:: SVN服务名称

set SVN_SERVER="SUBVERSION"

if exist %SVN_BACKUP% goto have

mkdir %SVN_BACKUP%

:have

net stop %SVN_SERVER%

@echo 正在备份，请稍等...

svnadmin hotcopy %SVN_HOME% %SVN_BACKUP%\%date:~0,10%

@echo 备份成功

net start %SVN_SERVER%

3.2 存在问题

目前服务器文件大小依然为40G，备份时间较长，效率应优于rar方式。--------svn的压缩做的非常好，rar压缩svn的压缩比超级高(应该大于99%)基本无用功

方案1：准备完成备份后在客户端删除不用的文件夹，但发现服务器上其实并没有删除对应内容。失败。-----要删除了还叫什么版本控制，此方案最傻

方案2：删除服务器db文件夹对应内容，导致客户端无法显示目录结构。失败。-------------目录结构好像不止revprops和revs两部分

方案3：dump服务器20091116以后版本，删除原根目录，load备份文件。此方案的速度应该很慢很慢。-----------未发现直接能dump版本大于一个版本号的命令，可能需要写bat

4 附

Rar命令行分卷：rar a –v4096 d:\a.rar d:\svn_repository

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

另外一些总结：

1.svn的压缩比很厉害，服务器40g，全部checkout出来100g，实际内容应该比这还要大（未包括一些删除的文件）；

2.dump很好，不愧是官方推荐的形式，不过适合于管理规范的方式，区分正在进行的项目与结束的项目，将不动内容加锁，这样可以将已有内容备份出去，如果想查看可以另设置一个svn服务

3.隐藏的.svn文件夹占用的空间较大，且很多，删除方案http://www.svn8.com/svnsy/20100228/23538.html