SVN备份迁移实战：一套完整的仓库搬迁方案，含常见坑位清单
干了快十年运维和研发管理，经手过的版本控制服务器少说也有十几台。每次接到“SVN备份迁移”这种活儿，我知道八成又有人要踩坑了：要么是项目组要换机房，要么是原来的服务器磁盘快满了，要么是领导觉得版本库放在某个人电脑上太不靠谱，需要统一迁到公司服务器。SVN这东西虽然老，但很多传统团队的存量代码和历史记录都在里面，动它之前不想清楚，轻则历史提交记录错乱，重则整个仓库打不开，那真是一晚上都睡不安稳。
这篇博文我不会给你讲什么高深理论，就结合我实操过的迁移经历，从备份方案选型、核心参数解读、完整迁移步骤到常见故障排查，把SVN备份迁移这件事掰开了讲清楚。适合刚接手SVN服务器的运维、团队里的版本管理员，以及准备把散落的仓库统一收拢的研发负责人。文章里的命令和步骤你直接拿去用，踩过的坑我也给你标出来。
1. 迁移前的项目调研与备份方案选型
1.1 先摸清家底：仓库结构、版本规模、二进制文件占比
很多人一上来就敲svnadmin命令，我建议你先花半天时间做调研。问自己三个问题：这台服务器上一共多少个仓库？最大的仓库有多少个版本？仓库里有没有大量二进制文件（比如设计稿、编译产物、安装包）？
调研方法很简单，登录服务器执行：
# 查看SVN根目录下所有仓库 ls -la /data/svn/repos/ # 查看每个仓库的版本号范围（需要逐一执行） svnlook youngest /data/svn/repos/project-a svnlook youngest /data/svn/repos/project-b # 统计仓库实际占用空间 du -sh /data/svn/repos/*/这一步千万不要省。我有一次接手一个号称“只有几十个版本”的仓库，结果svnlook youngest出来修订号已经到八千多，而且里面塞了几百张产品原图，整个仓库占了20多个G。如果你用默认方式直接打dump文件，备份时间、传输时间和目标服务器磁盘空间都要乘上好几倍。
另外要摸清客户端的访问方式：团队是直接用svn://协议访问，还是走http://（Apache）？有没有配置用户权限文件？有没有写钩子脚本？这些虽然不属于“备份”本身，但迁移时漏掉任何一个，都会导致新环境跑不起来。
1.2 三种主流备份方案对比
SVN仓库备份我常用三种方式，这里直接给你一个对比表格，方便你结合实际情况选型。
| 备份方式 | 核心命令 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| svnadmin dump/load | svnadmin dump/svnadmin load | 版本历史完整保留，可跨SVN大版本、跨平台迁移，文件可压缩可增量 | 全量备份时速度偏慢，大仓库dump文件很大 | 跨服务器迁移、更换SVN主版本、整理仓库历史 |
| svnadmin hotcopy | svnadmin hotcopy | 速度快，直接复制仓库目录结构，热备不影响在线访问 | 高度依赖相同SVN版本，无法跨平台/跨版本 | 同机备份、备机容灾、快速恢复 |
| 文件系统直接拷贝 | cp/rsync | 最简单、最直接，无需额外操作 | 需要完全停服，容易拷贝到不一致状态，不推荐 | 小仓库、临时备份、死马当活马医 |
从迁移这个角度说，我百分之九十五的情况下会用dump/load。原因后面细讲，你先记住这个方向没错。
1.3 为什么迁移首选 dump/load 而不是 hotcopy
很多人问：hotcopy不是更快吗？为什么迁移不用它？
关键在于“迁移”和“备份”的目标不一样。备份是怕数据丢了，怎么快怎么稳怎么来；迁移则要考虑目标环境可能和源环境不一样。比如你原来服务器是CentOS 6上装SVN 1.6，新服务器是Ubuntu 22.04装SVN 1.14，这两者的版本库内部格式（FSFS的布局和索引方式）是有差异的。用hotcopy直接拷贝过去的仓库，新版本SVN虽然大致能读，但偶尔会有警告，高版本往低版本迁更是直接不认。
svnadmin dump导出的是纯文本格式的“修订版本数据流”，它把这些差异全部抹平了。你在1.6上dump出来的文件，拿到1.14版本上load，完全没问题；反过来，从1.14导出到1.6也能load（前提是你没用太新的特性）。这就好比你把整个房子的图纸、材料和装修记录打包成标准格式的纸箱，到新地址重新组装，而不是把整栋房子连地基一起平移。
提示：如果你确认新旧服务器SVN版本完全一致（比如都是1.11.x），那hotcopy迁移确实更省事。但即便如此，我也建议你同时用dump方式导一份完整备份存着，双保险。
2. 核心细节：读懂 dump 与 load 的关键参数
2.1 svnadmin dump 的常用参数与作用
svnadmin dump的基本用法是：
svnadmin dump /data/svn/repos/project-a > /backup/project-a.dump对一个几百M的仓库，这条命令可能要跑十几分钟甚至更久。实际生产环境中我很少直接裸用，一般会加参数：
svnadmin dump -r 0:LATEST --incremental --deltas /data/svn/repos/project-a | gzip -9 > /backup/project-a.dump.gz拆开说一下这几个参数：
-r 0:LATEST：指定导出的修订版本范围。0是起始版本，LATEST是当前最新版本。如果你只要最近100个版本，可以写成-r N:LATEST，N是你要的起始版本号。--incremental：增量导出。如果不加这个参数，dump出来的数据会包含一个“从无到有”的完整基础版本，加上之后所有版本的变化量，适合用来做镜像。加了它，导出的数据等于“基于前面某个版本的增量变化”，在合并多个dump文件时很有用。--deltas：这个参数让dump文件记录每个版本与上一版本之间的差异，而不是每个版本都存一份完整文件快照。好处是dump文件体积明显变小，坏处是load的时候需要连续算历史差异，会稍微慢一点。对远程传输来说，减小体积是实打实的收益。
还有一个我常用的组合：
svnadmin dump /data/svn/repos/project-a | gzip -9 > /backup/project-a-$(date +%Y%m%d).dump.gz先dump再管道给gzip压缩。别小看这一步，文本型的dump文件压缩率可以达到10:1。一个10G的仓库，dump出来可能也有8G，gzip之后往往不到1G。
2.2 svnadmin load 与版本号重写
备份相对简单，难点在恢复。svnadmin load的基本用法：
# 在目标服务器上创建空仓库 svnadmin create /data/svn/repos/project-a-new # 把dump文件灌进去 gunzip -c /backup/project-a.dump.gz | svnadmin load /data/svn/repos/project-a-newload的时候它可能会提示“revision 1 loaded”之类的信息，不用紧张，这是正常的。有一个细节很多人没注意：目标仓库如果之前已有版本号，load进去的数据版本号会接着已有版本号递增。所以目标仓库最好是一个“全新创建的空仓库”。
还有一个容易踩的坑：如果你导出的dump文件带了UUID，load的时候目标仓库会保留这个UUID；如果是用svnadmin create新建的仓库，它自带一个新的UUID，load完成后会被dump里的UUID覆盖。这本身没问题，但对客户端来说，仓库UUID变了，原来所有工作副本的URL定位就会失效。后面我会单独讲svn relocate的操作。
2.3 增量备份与完整备份的组合策略
上面讲的是全量dump。服务器上跑了多个仓库，或者单个仓库特别大的情况下，每次迁移/备份都全量dump显然不现实。更合理的做法是：全量+增量组合。
假设你有一个仓库，周一凌晨做了全量备份full.dump（含r0到r100），之后每天做增量：
# 周二增量备份（r101到r110） svnadmin dump -r 101:110 --incremental /data/svn/repos/project-a > inc-101-110.dump # 周三增量备份（r111到r120） svnadmin dump -r 111:120 --incremental /data/svn/repos/project-a > inc-111-120.dump恢复当天，你要按顺序load：
gunzip -c full.dump.gz | svnadmin load /data/svn/repos/project-a-new gunzip -c inc-101-110.dump.gz | svnadmin load /data/svn/repos/project-a-new gunzip -c inc-111-120.dump.gz | svnadmin load /data/svn/repos/project-a-new顺序不能乱，也不能漏。我吃过一次亏，增量包漏了中间一段，load时报错说“期望修订版本110，实际接收101”，整个恢复过程只能推倒重来。
注意：做增量dump时，命令里必须加
--incremental。不加的话，dump文件开头会带一个独立的基础版本，这会导致后续load时版本号重复，甚至直接报错。
2.4 备份文件务必验证：svnadmin verify 是你的救命稻草
备份完不是就完事了，一定要验证。svnadmin verify是检验仓库完整性的工具：
svnadmin verify /data/svn/repos/project-a它会逐版本检查仓库内部数据结构，发现问题会明确报告。“verify通过”意味着仓库本身是健康的，备份文件只要基于它dump出来，理论上也健康。
对dump文件本身的验证，我一般这样处理：load完成之后，在新仓库上再执行一次svnadmin verify。如果新仓库verify通过，同时svnlook youngest显示的版本号跟源仓库一致，那这次迁移基本就稳了。
这个双端验证的环节，看起来多花几分钟，实际上能帮你挡掉九成以上的“迁移后才发现数据不对”的灾难。
3. 按部就班：一个真实仓库的迁移过程实操
3.1 从旧服务器导出完整备份
假设我有一台老服务器，仓库路径/home/svn/repos/oa-system，需要迁到新服务器。完整操作流程如下。
第一步，在旧服务器上查看仓库状态：
svnlook youngest /home/svn/repos/oa-system # 假设输出：2456第二步，执行全量dump，带压缩：
svnadmin dump --deltas -r 0:2456 /home/svn/repos/oa-system | gzip -9 > /tmp/oa-system-$(date +%Y%m%d).dump.gz执行过程中别急着干别的，留意输出。如果中途出现* Dumped revision 0、* Dumped revision 1这样的进度，说明在正常跑。如果一直卡着不动，八成是仓库有问题或者IO瓶颈。
第三步，检查备份文件：
ls -lh /tmp/oa-system-*.dump.gz # 确认文件大小合理，比如大于0第四步，把备份包传到新服务器。我一般用rsync，断点续传比scp靠谱：
rsync -avzP /tmp/oa-system-$(date +%Y%m%d).dump.gz user@new-server:/tmp/3.2 在新服务器上创建并导入仓库
来到新服务器，先确认SVN版本：
svnadmin --version创建新仓库：
svnadmin create /data/svn/repos/oa-system这里有个小细节：svnadmin create默认会创建一套完整的仓库结构，包括hooks、conf、format等目录。如果你希望新仓库的目录布局和旧仓库完全一致，可以加上--fs-type fsfs（FSFS是默认，但显式声明更好），其他参数保持默认。
然后执行导入：
gunzip -c /tmp/oa-system-*.dump.gz | svnadmin load /data/svn/repos/oa-system导入过程会有大量输出，每加载一个版本会打印一行。看到------- Committed revision N <<<这样的字样，说明在正常推进。全部结束后，执行验证：
svnadmin verify /data/svn/repos/oa-system svnlook youngest /data/svn/repos/oa-system # 期望输出：2456，和源仓库一致到这里，仓库数据本身已经迁过来了。
3.3 权限文件、钩子脚本与配置文件的同步
仓库数据迁完，新服务器上的SVN服务要能正常对外提供服务，还差权限体系和钩子脚本。
SVN的原生权限体系依赖conf/svnserve.conf、conf/passwd和conf/authz这三个文件。其中：
svnserve.conf：定义仓库访问方式、是否启用认证、匿名访问权限等。passwd：存放用户名和密码（纯文本格式）。authz：路径级别的权限控制，比如哪些用户能读哪些目录、谁能写哪些分支。
直接把这几个文件拷贝过去覆盖即可：
cp /home/svn/repos/oa-system/conf/svnserve.conf /data/svn/repos/oa-system/conf/ cp /home/svn/repos/oa-system/conf/passwd /data/svn/repos/oa-system/conf/ cp /home/svn/repos/oa-system/conf/authz /data/svn/repos/oa-system/conf/钩子脚本在hooks目录下，常见的如post-commit（提交后触发，常用于触发构建或发送通知）、pre-commit（提交前校验，常用于检查提交信息格式）。这些脚本是Unix可执行文件，拷贝后要记得赋予执行权限：
chmod +x /data/svn/repos/oa-system/hooks/*注意：很多人在这一步只迁数据不迁钩子，导致新环境的“提交后自动部署”“邮件通知”等全部静默失效。建议迁移完把 hooks 目录逐个脚本核对一遍，确认没有遗漏。
还有一项容易被忽略：如果SVN是通过Apache的http模式访问，涉及dav_svn.conf的Location配置、SSL证书等，这些不在svnadmin的管辖范围内，需要单独在Apache配置里迁移或重配。
3.4 客户端视角：svn relocate 的正确姿势
服务器端一切就绪后，开发团队的客户端要改远程仓库地址。SVN客户端不支持像Git remote那样随意切换而不出问题，但SVN官方提供了优雅的方案：svn relocate。
老版本SVN的命令是：
svn switch --relocate http://old-server/svn/oa-system http://new-server/svn/oa-systemSVN 1.7以后，简化为：
svn relocate http://old-server/svn/oa-system http://new-server/svn/oa-systemTortoiseSVN用户更简单：右键工作副本 -> TortoiseSVN -> Relocate，填新地址即可。
执行relocate后，再执行svn update，如果没有报错且能拉取到最新代码，说明工作副本切换成功。
这里有一个容易导致团队混乱的细节：如果新旧服务器的仓库UUID不一致，relocate会失败或导致工作副本与仓库不匹配。在svnadmin load时，如果dump文件里带有原UUID，新仓库就已经自动沿用了。你可以用下面的命令确认：
svnadmin dump /data/svn/repos/oa-system --revision 0 | grep UUID如果没有沿用，需要手动设置：
svnadmin setuuid /data/svn/repos/oa-system <原仓库UUID>3.5 迁移完成后的完整验证清单
本次迁移结束前，建议按清单逐项验证：
| 检查项 | 检查方法 | 预期结果 |
|---|---|---|
| 仓库版本号 | svnlook youngest /data/svn/repos/oa-system | 与源仓库保持一致 |
| 仓库完整性 | svnadmin verify /data/svn/repos/oa-system | 无错误输出 |
| 权限控制 | 用非管理员用户checkout、commit测试 | 权限拦截生效 |
| 钩子脚本 | 执行一次提交，观察钩子输出/日志 | 钩子正常触发 |
| 工作副本 | 团队执行svn relocate+svn update | 无报错，版本一致 |
| 服务自启 | 确认svnserve或httpd开机自启配置 | 重启服务器后服务可用 |
4. 常见问题与排查技巧实录
4.1 svnadmin load 报错：版本号连续性与重复导入
load时报 “Revision 20 already exists” 是最典型的错误，通常是因为目标仓库不是空的，或者同一个dump文件被load了两次。
解决办法只有一个：新仓库必须用svnadmin create全新创建，不要在已有历史的仓库上load；load之前用svnlook youngest确认目标仓库为空（返回0）。
4.2 dump文件损坏
load过程中如果报 “Malformed dumpfile header” 或 “Unexpected end of dump file”，多半是dump文件在传输或压缩过程中损坏了。处理思路：
- 先检查源仓库本身健不健康，如果不确定就执行
svnadmin verify。 - 重新dump，这次建议不压缩（或换用
gzip -1这种低压缩比模式），再重新传输。 - 传输建议用
rsync加-P参数，确保文件完整传到目标机器后再解压。
4.3 Windows端 TortoiseSVN 的一系列客户端问题
热搜词里有一堆TortoiseSVN关键词，我猜很多读者是Windows环境下的小乌龟用户。先说和迁移最相关的几个。
rebase/update时出现 “Cannot relocate URL: previous location has different repository root” 这种报错，说明新旧URL不在同一个仓库根下。你要用仓库根URL来relocate，而不是用分支目录URL。SVN的relocate要求只是“仓库根路径”变了，内部结构和相对路径不能变。
还有另一个特别常见的是“clean up”卡死。提交或更新被中断后，工作副本被锁住，右键clean up也不动。我一般用两种方法：一是关掉所有占用该目录的编辑器/IDE进程再clean up；二是如果不行，到wc.db文件所在目录，用SQLite工具清掉work_queue表里的残留记录。
再说一个Windows安装环境相关的经典报错：安装TortoiseSVN时提示“安装程序错误2503/2502”。这个是因为Windows Installer缓存目录权限不对。处理办法：用管理员身份运行cmd，执行msiexec /package 小乌龟安装包.msi，通常能绕过报错完成安装。
4.4 迁移后权限丢失或变样
如果新环境里所有人都能访问所有仓库，或者某些用户权限突然失效，优先排查authz文件里的路径组名。SVN的authz文件里有[groups]段定义用户组，后面路径里用@组名引用。迁移过程中如果仓库根路径（如[oa-system:/]）的变化导致组名对应不上，就会出问题。
一个常见坑：旧服务器里仓库名是oa-system，新服务器里svnserve.conf配置的仓库根是/data/svn/repos/，客户端访问的URL变成了svn://new-server/oa-system，看起来名没变。但如果你把仓库改名为oa_system，authz里的路径段全部要跟着改，很多人漏了这步导致权限静默失效。
4.5 大仓库dump导出核Big文件支持
热搜词里有“svn 支持大的二进制文件存放吗”，这里给你一个明确结论：SVN支持存放任意大小的文件（理论上文件系统支持多大就存多大），但大二进制文件会显著拖慢仓库性能和dump/load速度。因为SVN是基于差异存储的，二进制文件每次变更都可能存一个完整副本，仓库体积会迅速膨胀。
迁移中如果遇到超大单文件（比如超过1G），我的建议是：
- 先确认这个文件是否真的需要入库，如果只是编译产出物或临时安装包，建议挪出版本控制，改用统一存储或制品库。
- 必须入库的话，dump时加上
--deltas参数，至少能把每次变更的体积压一压。 - load到新仓库后，定期用
svnadmin pack对FSFS仓库做一次整理，压缩历史数据。
4.6 relocate之后提交冲突
团队成员执行relocate后，如果本地工作副本还停留在旧地址，提交时会报 “Repository UUID mismatches” 或 “Working copy path ... is out of date”。这种情况我在迁移后见过不少次，多半是有人忘了执行relocate，硬用旧URL提交。
解决方案很直接，命令重新relocate一遍，然后svn update校准到最新版本。如果本地有未提交的改动，先svn status看清楚状态再操作，别莽撞地clean up。
5. 迁移后的长期维护与自动化备份建议
仓库迁到了新环境，以后不能再裸奔了。我建议你趁热打铁，把自动备份机制也搭起来。
最简单稳妥的策略是：每天凌晨用svnadmin hotcopy做一份全量镜像备份到另一块磁盘，每周做一次svnadmin dump完整归档加压缩。热点仓库（每天提交量大的）可以另外加增量dump。
Linux服务器上的定时计划，用cron：
# 每天凌晨2点热拷贝 0 2 * * * /usr/local/bin/svn-backup-hotcopy.sh # 每周日凌晨3点全量dump并压缩 0 3 * * 0 /usr/local/bin/svn-backup-dump.shWindows环境用任务计划程序，定时执行bat脚本即可。脚本逻辑很简单：先创建带日期的备份目录，执行hotcopy/dump命令，最后把超过N天的旧备份删除。
搭完定时备份之后，建议做一次演练。演练目标不是“能备份”，而是“能从备份恢复”。很多团队备份脚本写了一堆，真出故障时才发现备份文件是坏的或者恢复流程没人会。按月或按季度做一次“恢复演练”，把备份load到临时目录，确认能checkout出代码，这件事才算闭环。
聊到最后一个实际体会：SVN的备份迁移本质上不是技术难题，而是“细心活”。所有坑都出在细节上——仓库结构没摸清、权限文件漏了带、钩子脚本没同步、客户端relocate没指导到位。你只要把每个环节都当成检查点来过一遍，按本文的清单执行，这个活儿基本不会翻车。
最后再分享一个小技巧：在旧服务器正式下线之前，建议保留至少一周的只读窗口期。直接把svnserve服务停掉但别删除仓库目录，万一新环境出了什么幺蛾子，你还能重新回到旧环境救场。这一周“和平共存期”，是我踩过几次坑之后养成的习惯，成本极低，价值极高。
