移动并升级 Subversion 服务器

移动并升级 Subversion 服务器

我有一个非常老旧的服务器(ubuntu 9.04),上面运行着很多其他东西以及 SubVersion。

我现在计划将 subversion 移至更好更快的服务器,但当然不想丢失任何数据或历史记录。许多人都可以访问 SVN,我不希望他们做出任何更改(我还会将域移至新服务器)。

最好的办法是什么?在迁移过程中,我还想将旧的 svn 版本 1.5.4 更新到最新的稳定版本 1.7.0

在执行此操作之前我应该​​注意哪些可能的问题? 有什么指南可以帮助我吗

谢谢

答案1

  • 在目标服务器上安装最新的 Subversion
  • svnadmin dump|svnadmin load(可能在创建 repo 之后,记不清了)或
  • svnadmin 热复制

对于源服务器上的每个 repo

  • 将服务器配置文件从源移动到目标(用户、组、ACL)
  • 将目标主机名更改为源主机名
  • open 用于 SVN 端口
  • 测试提交+签出

答案2

我建议首先在新服务器上安装 SVN 1.7.0 实例。然后,您可以开始将存储在旧 SVN 存储库中的所有信息复制到新存储库。

正如 David Spillet 对此所解释的那样回答rsync只要您没有备份当前处于活动状态的存储库,就应该可以完美地备份/复制 svn 存储库。我怀疑您正在尝试备份有问题的活动存储库。

我猜报告的问题与文件丢失(它们在初始扫描时存在,但在备份完成之前被移动/重命名/删除)、被锁定或在 rsync 读取它们时明显被更改有关。如果备份实时 svn 服务并且在开始备份运行之前没有完全停止 svn 服务,您将在大多数备份技术中看到类似的错误(或更糟糕的是:相关但未报告的问题)。

在备份运行时停止对存储库的所有访问可能不是您的选择,即使是在深夜进行(因为您可能有在不同时间工作的远程开发人员)。如果是这种情况,那么有几个选项,包括:

  1. 用于hot-backup.py在存储库处于活动状态时对其进行完整备份本节中描述免费提供的使用 Subversion 进行版本控制这通常被认为是推荐阅读。这不适用于您的远程备份,因为它会导致每次都通过线路发送完整的存储库,但您可以将备份备份到临时本地区域并在此rsync而不是实时存储库上执行(或其他任何)基于备份的操作。

  2. 如果您在 Linux 上运行并使用 LVM 对驱动器进行分区,则可以使用 LVM 的快照功能执行与选项 1 中所述的类似操作。请参阅此处和此处的示例技术文档。这确实意味着在创建快照所需的时间内短时间停止对 SNV 服务的访问,但这几乎是即时的,因此不太可能成为问题,而需要在整个备份操作期间停止它。

  3. 使用实时存储库的增量备份,上述 SVN 书中也提到过。

LVM 技术比 -then-sync 更快hot-backup.py,但除非您已经使用并熟悉 LVM,否则您无需付出大量额外的工作和学习就无法使用。它的优点是它几乎肯定会快得多,并且占用更少的磁盘空间(尽管现在磁盘空间非常便宜)。LVM 快照确实会影响写入性能,但除非您的存储库非常繁忙,并且当您删除快照时,性能在备份运行结束时会恢复正常,否则差异不太可能明显。

如果您还没有本地备份,此hot-backup.py方法的优点是它还能为您提供本地备份 - 如果您将“热副本”版本存储在另一台计算机上,那么如果主机在不影响其他计算机的事件中死机(例如,驱动器控制器故障),您可以比恢复远程副本更快地恢复该副本。除非您已经使用过 LVM 并且熟悉它,否则它可能也更易于实施。

增量备份比这两种技术都快,但不如热复制-同步简单,而且彻底灾难后的恢复可能更复杂,除非您使用增量备份在另一端构建完整的存储库副本(而不仅仅是存储增量信息)。无论如何,建议在另一端重建存储库,因为这是测试备份是否有效的一种方式 - 即使使用其他技术,您也应该定期测试备份(口头禅:未经测试的备份不是好的备份)。

总之,rsync只要您没有备份当前处于活动状态的存储库,备份或复制 svn 存储库就应该完全没问题 - 您需要停止服务或从某种形式的快照备份。

始终记住通过比较 SVN 存储库中的信息、使用重定位选项、检查日志文件等来测试一切是否正常。

相关内容