SVN 增量备份与灾难恢复：dump、hotcopy 与 svnsync 实践

版本控制系统是研发团队的核心资产，一旦 SVN 仓库因磁盘故障、误操作或勒索软件而损毁，代码历史与分支结构可能瞬间归零。备份不是可选项，而是生存底线。本文从实战角度出发，系统讲解 svnadmin dump 增量备份、svnadmin hotcopy 热备以及 svnsync 远程镜像三种主流方案，并给出可落地的灾难恢复流程。

一、备份前必须明确的三个问题

在动手之前，先回答以下问题，它们直接决定你该选哪种方案：

1. 备份窗口有多长？ 仓库是否允许停机？不允许停机则不能使用冷备。
2. 恢复点目标（RPO）是多少？ 能容忍丢失多少小时甚至多少分钟的数据？
3. 恢复时间目标（RTO）是多少？ 灾难发生后，多久必须恢复服务？

没有这三个答案，任何备份策略都是盲目的。

二、svnadmin dump：最灵活的增量备份

svnadmin dump 是 SVN 官方提供的逻辑备份工具，它将仓库内容导出为可读的文本流。其最大优势是支持增量导出，只备份指定版本区间的变更。

2.1 全量备份

svnadmin dump /var/svn/repos > /backup/repos-full-$(date +%Y%m%d).dump

2.2 增量备份

假设上次备份到版本 1000，当前最新版本为 1050：

svnadmin dump /var/svn/repos -r 1001:1050 --incremental \
  > /backup/repos-inc-1001-1050.dump

--incremental 参数是关键：它告诉 SVN 只导出变更部分，而不是每个版本都包含完整快照。没有这个参数，增量文件会异常庞大。

2.3 恢复流程

恢复时需要按顺序加载：先加载全量，再依次加载各增量文件。

svnadmin create /var/svn/repos-restored
svnadmin load /var/svn/repos-restored < /backup/repos-full.dump
svnadmin load /var/svn/repos-restored < /backup/repos-inc-1001-1050.dump

优点： 跨版本兼容性好，可跨平台迁移，支持过滤（如只备份某个目录）。
缺点： 导出和加载速度较慢，大仓库全量 dump 可能耗时数小时。

三、svnadmin hotcopy：最快的物理热备

hotcopy 直接复制仓库的物理文件（包括 Berkeley DB 或 FSFS 数据），无需停机，速度远快于 dump。

svnadmin hotcopy /var/svn/repos /backup/repos-hotcopy-$(date +%Y%m%d)

如果目标目录已存在且需要更新，可加 --clean-logs 清理日志：

svnadmin hotcopy /var/svn/repos /backup/repos-hotcopy --clean-logs

恢复流程

hotcopy 的恢复极其简单——直接替换即可：

svnadmin hotcopy /backup/repos-hotcopy /var/svn/repos
# 或直接 mv，然后修正权限
chown -R www-data:www-data /var/svn/repos

优点： 速度快，恢复简单，适合每日全量备份。
缺点： 不支持增量，每次都是全量复制，占用空间大；跨平台兼容性不如 dump。

3.1 实践建议

对于中小型仓库（几 GB 以内），hotcopy 是最省心的方案。可以结合硬链接工具（如 rsync --link-dest）实现类似快照的效果，节省空间：

rsync -a --link-dest=/backup/repos-hotcopy-latest \
  /backup/repos-hotcopy-20240101/ /backup/repos-hotcopy-latest/

四、svnsync：远程实时镜像

svnsync 用于在两个 SVN 仓库之间同步版本，适合构建异地灾备中心。它通过 SVN 协议拉取变更，天然支持增量。

4.1 初始化镜像仓库

svnadmin create /var/svn/repos-mirror
echo '#!/bin/sh' > /var/svn/repos-mirror/hooks/pre-revprop-change
chmod +x /var/svn/repos-mirror/hooks/pre-revprop-change

svnsync init file:///var/svn/repos-mirror https://svn.example.com/repos

4.2 执行同步

svnsync sync file:///var/svn/repos-mirror

可放入 crontab 定时执行：

*/10 * * * * svnsync sync file:///var/svn/repos-mirror >> /var/log/svnsync.log 2>&1

4.3 故障切换

当主仓库不可用时，将镜像仓库的同步属性清除，即可作为主库使用：

svn propset svn:sync-from-url --revprop -r 0 "" file:///var/svn/repos-mirror

优点： 近实时同步，RPO 极低；镜像仓库可直接对外提供只读服务。
缺点： 需要网络和源仓库可访问；同步延迟取决于频率；配置相对复杂。

五、组合策略：分层备份架构

单一方案难以覆盖所有场景，推荐采用分层策略：

配合监控告警：检查备份文件大小是否异常、svnsync 日志是否有错误、hotcopy 是否成功退出。

六、灾难恢复演练清单

备份未经验证等于没有备份。每季度至少执行一次恢复演练：

1. 从 hotcopy 恢复一个仓库，验证 svn log 和 svn checkout 正常。
2. 从 dump 全量+增量恢复，比对最新版本号与主库一致。
3. 模拟主库宕机，将 svnsync 镜像切换为主库，验证客户端可正常提交。
4. 记录每次演练的 RTO，持续优化。

七、常见陷阱与注意事项

• dump 增量必须连续： 如果中间缺失某个增量文件，后续增量无法加载。建议每次增量文件命名包含版本区间，便于核对。
• hotcopy 不复制钩子脚本的某些状态： 恢复后检查 hooks 目录权限和可执行位。
• svnsync 不能同步 revprop 变更： 如果团队频繁修改版本属性，需额外备份 revprop。
• 权限与 SELinux： 恢复后务必修正仓库目录的属主和 SELinux 上下文，否则 Apache 或 svnserve 无法访问。
• 存储空间监控： dump 和 hotcopy 都会快速增长，设置磁盘配额和清理策略。

结语

SVN 备份没有银弹。dump 胜在灵活与兼容，hotcopy 胜在速度与简单，svnsync 胜在实时与异地。将三者组合成分层架构，配合定期恢复演练，才能真正确保代码资产在灾难面前安然无恙。记住：备份的价值不在于文件存在，而在于恢复成功。

未经允许不得转载：任鹏个人博客 » SVN 增量备份与灾难恢复：dump、hotcopy 与 svnsync 实践