SVN仓库备份实战：dump、hotcopy与svnsync选型与恢复指南

1. 为什么SVN备份不能靠“复制粘贴”

1.1 先理解仓库的物理构成，才能明白备份的逻辑

很多团队用SVN好几年，仓库积累了上万次提交，但真正做过备份的少之又少。我见过不少同事把“备份”理解为把仓库目录整个拷贝一份到移动硬盘，然后心安理得地继续开发。直到某天服务器硬盘故障、或者误操作删了仓库，才发现这份“拷贝”根本没法用。

要搞清楚SVN备份怎么做，先得知道仓库里到底装了什么。以最常见的FSFS格式为例，一个标准仓库目录的结构大致是：

text复制repo/
├── README.txt
├── conf/
│   ├── authz
│   ├── passwd
│   └── svnserve.conf
├── db/
│   ├── current
│   ├── format
│   ├── revprops/
│   ├── revs/
│   └── transactions/
├── format
├── hooks/
│   ├── post-commit.tmpl
│   ├── pre-commit.tmpl
│   └── ...
└── locks/
    └── db.lock

如果你直接在运行中的仓库目录上执行文件系统的复制，大概率会碰到几个问题：

第一，写操作正在进行时，数据文件可能处于不一致状态。 SVN的每次提交涉及多个文件写入，包括revs目录下的新版本文件、revprops下的属性文件、current指针的更新。如果在某个提交过程中直接复制，可能出现版本文件存在但current指针还没更新、或者revprops缺失的情况。

第二，直接复制出来的仓库无法通过完整性校验。 复制完成后你跑一下 svnadmin verify，很容易报出校验错误。

第三，FSFS格式本身就是为“仓库目录内原子操作”设计的，但文件系统的拷贝并不保证原子性。 数据库类型的仓库（BDB格式）更不用说，直接复制几乎必坏。

所以，正确的SVN备份思路是：要么通过SVN提供的管理工具导出为独立文件（svnadmin dump），要么使用专门的热备份命令（svnadmin hotcopy），要么搭建跨仓库的同步镜像（svnsync）。

1.2 备份目标不是“存下来”，而是“能恢复”

我在很多项目和团队中推进过SVN备份方案，最强调的一点就是：备份的价值只有在恢复时才能体现。你辛辛苦苦跑完备份脚本，生成了几十GB的dump文件，但如果从来没验证过它能load回来，那和没备份没本质区别。

所以正常备份方案应该包含三个核心指标：

• 可恢复性：备份文件是否完整、能否通过 svnadmin verify、能否在干净环境里load成功。
• 可追溯性：备份文件中包含哪些版本号范围、备份时间、仓库UUID是否保留。
• 可自动化：能否定时执行、增量备份、自动清理过期文件。

如果把这三点记牢，后面设计备份脚本和恢复预案时就不会跑偏。

2. 三种SVN备份方式选型：dump、hotcopy还是svnsync

2.1 svnadmin dump：慢但通用，跨版本迁移的可靠选择

svnadmin dump 是SVN自带的导出工具，它把仓库中的所有版本数据按顺序输出为一个纯文本格式的dump文件。这个文件包含了从版本0到指定版本的所有提交记录、路径变更、文件内容和属性信息。

基本用法如下：

bash复制# 全量备份仓库 repo 的所有版本
svnadmin dump /path/to/repo > full_backup.dump

# 备份指定版本范围
svnadmin dump /path/to/repo -r 1000:2000 > range_backup.dump

# 增量备份某个版本区间
svnadmin dump /path/to/repo -r 1500:2000 --incremental > incremental_1500_2000.dump

dump方式最大的优势是通用性强。它输出的文件是SVN定义的标准格式，不依赖仓库的物理存储格式，也不依赖版本库的FSFS/BDB类型。所以当你需要做跨大版本升级（比如从SVN 1.6升到1.14）、或者要把仓库迁移到另一台完全不同的服务器上，dump和load是最稳妥的组合。

缺点也很明显：速度慢、文件体积大。对一个几千个版本、占用几十GB磁盘的仓库跑全量dump，可能需要好几个小时。这也是为什么实际生产中要做周期性全量+定期增量的组合方案，而不能每天都全量dump。

2.2 svnadmin hotcopy：物理级热备份，速度快的首选

svnadmin hotcopy 是在线复制仓库目录，它能在SVN服务不停止的情况下，产生一个一致性快照。

bash复制svnadmin hotcopy /path/to/repo /backup/repo_hotcopy

我用hotcopy的感受是，它的备份速度比dump快得多，因为本质上是在文件系统层面复制整个仓库目录，不需要遍历逐个版本生成文本格式。恢复也很快——直接把hotcopy出来的目录挪到目标位置、配置好服务就行。

不过要注意，hotcopy有它的限制：

• 不能跨大版本。hotcopy默认只能在相同或相近版本的SVN之间使用，跨大版本时可能因为内部格式变化导致恢复失败。
• 备份内容包含配置和hooks。这是优势也是隐患，它会把conf目录下的权限配置