SVN迁移及备份的方法【转】-白红宇

SVN迁移及备份的方法【转】

阅读量：5903 次

发布时间：2019-06-19

本文共 11405 字，大约阅读时间需要 38 分钟。

转自： http://spiritfrog.iteye.com/blog/448578 + http://magnet2008.iteye.com/blog/586578

备份策略

==============

svn备份一般采用三种方式：

1）svnadmin dump

2)svnadmin hotcopy

3)svnsync.

注意，svn备份不宜采用普通的文件拷贝方式（除非你备份的时候将库暂停），如copy命令、rsync命令。

笔者曾经用 rsync命令来做增量和全量备份，在季度备份检查审计中，发现备份出来的库大部分都不可用，因此最好是用svn本身提供的功能来进行备份。

优缺点分析

==============

第一种svnadmin dump是官方推荐的备份方式，优点是比较灵活，可以全量备份也可以增量备份，并提供了版本恢复机制。

缺点是：如果版本比较大，如版本数增长到数万、数十万，那么dump的过程将非常慢；备份耗时，恢复更耗时；不利于快速进行灾难恢复。

个人建议在版本数比较小的情况下使用这种备份方式。

第二种svnadmin hotcopy原设计目的估计不是用来备份的，只能进行全量拷贝，不能进行增量备份；

优点是：备份过程较快，灾难恢复也很快；如果备份机上已经搭建了svn服务，甚至不需要恢复，只需要进行简单配置即可切换到备份库上工作。

缺点是：比较耗费硬盘，需要有较大的硬盘支持（俺的备份机有1TB空间，呵呵）。

第三种svnsync实际上是制作2个镜像库，当一个坏了的时候，可以迅速切换到另一个。不过，必须svn1.4版本以上才支持这个功能。

优点是：当制作成2个镜像库的时候起到双机实时备份的作用；

缺点是：当作为2个镜像库使用时，没办法做到“想完全抛弃今天的修改恢复到昨晚的样子”；而当作为普通备份机制每日备份时，操作又较前2种方法麻烦。

备份的命令

==============

全备份：使用svnadmin dump或svnadmin hotcopy或svnsync来做，

hotcopy：

svnadmin hotcopy path/to/repository path/to/backup –clean-logs

dump:

svnadmin dump 版本库路径及名称 –revision 导出的版本号> 导出的命名

增量备份：使用svnadmin dump的–incremental选项来实现

svnadmin dump 版本库路径及名称 –revision 上次导出的版本号:到本次要导出到的版本号 –incremental > 导出的命名

一个技巧：如果你有一个较大的Subsersion版本库而你又想用最少的空间来将它备份下来，用这个命令（请将/repo替换成你的版本库路径）吧：

svnadmin dump –deltas /repo |bzip2 |tee dump.bz2 | md5sum >dump.md5

分步解释：最重要的一步是 -deltas,将消耗更多的CPU资源，但拥有更有效的差异存储办法。

bzip2压缩方案比gzip慢，但换来的更好的压缩率。

更有趣的是，tee方法将压缩的数据流转向到文件dump.bz2,同时将其输出到标准输出，后者有转向给了MD5摘要计算工具。

还原命令

==============

还原版本：svnadmin load 要恢复的版本库路径及名称 < 导出的命名

svnadmin hotcopy path/to/repository path/to/backup –clean-logs

svnadmin dump

==============

这是subversion官方推荐的备份方式。

1）定义备份策略：

备份频度：每周六进行一次全量备份，每周日到周五进行增量备份

备份地点：备份存储路径到/home/backup/svn/

备份命名：全量备份文件名为：weekly_fully_backup.yymmdd,增量备份文件命名为：daily-incremental-backup.yymmdd

备份时间：每晚21点开始

备份检查：每月末进行svnadmin load恢复试验。

2）建立全量备份脚本：

在~/下建立一个perl脚本文件，名为weekly_backup.pl，执行全量备份，并压缩备份文件，代码如下(本代码只针对一个库的备份，如果是多个库请做相应改动)：

#!/usr/bin/perl -w

my $svn_repos="/home/svn/repos/project1";

my $backup_dir="/home/backup/svn/";

my $next_backup_file = "weekly_fully_backup.".`date +%Y%m%d`;

$youngest=`svnlook youngest $svn_repos`;

chomp $youngest;

print "Backing up to revision $youngest\n";

my $svnadmin_cmd="svnadmin dump --revision 0:$youngest $svn_repos >$backup_dir/$next_backup_file";

`$svnadmin_cmd`;

open(LOG,">$backup_dir/last_backed_up"); #记录备份的版本号

print LOG $youngest;

close LOG;

#如果想节约空间，则再执行下面的压缩脚本

print "Compressing dump file...\n";

print `gzip -g $backup_dir/$next_backup_file`;

3）建立增量备份脚本：

在全量备份的基础上，进行增量备份：在~/下建立一个perl脚本文件，名为：daily_backup.pl，代码如下：

#!/usr/bin/perl -w

my $svn_repos="/home/svn/repos/project1";

my $backup_dir="/home/backup/svn/";

my $next_backup_file = "daily_incremental_backup.".`date +%Y%m%d`;

open(IN,"$backup_dir/last_backed_up");

$previous_youngest = <IN>;

chomp $previous_youngest;

close IN;

$youngest=`svnlook youngest $svn_repos`;

chomp $youngest;

if ($youngest eq $previous_youngest)

{

print "No new revisions to backup.\n";

exit 0;

}

my $first_rev = $previous_youngest + 1;

print "Backing up revisions $youngest ...\n";

my $svnadmin_cmd = "svnadmin dump --incremental --revision $first_rev:$youngest $svn_repos > $backup_dir/$next_backup_file";

`$svnadmin_cmd`;

open(LOG,">$backup_dir/last_backed_up"); #记录备份的版本号

print LOG $youngest;

close LOG;

#如果想节约空间，则再执行下面的压缩脚本

print "Compressing dump file...\n";

print `gzip -g $backup_dir/$next_backup_file`;

4）配置/etc/crontab文件

配置 /etc/crontab 文件，指定每周六执行weekly_backup.pl，指定周一到周五执行daily_backup.pl;

具体步骤俺就不啰嗦了.

5）备份恢复检查

在月底恢复检查中或者在灾难来临时，请按照如下步骤进行恢复：恢复顺序从低版本逐个恢复到高版本；即，先恢复最近的一次完整备份 weekly_full_backup.071201（举例），然后恢复紧挨着这个文件的增量备份 daily_incremental_backup.071202，再恢复后一天的备份071203，依次类推。如下：

user1>mkdir newrepos

user1>svnadmin create newrepos

user1>svnadmin load newrepos < weekly_full_backup.071201

user1>svnadmin load newrepos < daily_incremental_backup.071202

user1>svnadmin load newrepos < daily_incremental_backup.071203

....

如果备份时采用了gzip进行压缩，恢复时可将解压缩和恢复命令合并，简单写成：

user1>zcat weekly_full_backup.071201 | svnadmin load newrepos

user1>zcat daily_incremental_backup.071202 | svnadmin load newrepos

...

svnadmin hotcopy整库拷贝方式

==============

svnadmin hotcopy是将整个库都“热”拷贝一份出来，包括库的钩子脚本、配置文件等；任何时候运行这个脚本都得到一个版本库的安全拷贝，不管是否有其他进程正在使用版本库。

因此这是俺青睐的备份方式。

1）定义备份策略

备份频度：每天进行一次全量备份，

备份地点：备份目录以日期命名，备份路径到 /home/backup/svn/${mmdd}

备份保留时期：保留10天到15天，超过15天的进行删除。

备份时间：每晚21点开始

备份检查：备份完毕后自动运行检查脚本、自动发送报告。

2）建立备份脚本

在自己home目录 ~/下创建一个文件，backup.sh：

#!/bin/bash

SRCPATH=/home/svn/repos/; #定义仓库parent路径

DISTPATH=/home/backup/svn/`date +\%m%d`/ ; #定义存放路径;

if [ -d "$DISTPATH" ]

then

else

mkdir $DISTPATH

chmod g+s $DISTPATH

echo $DISTPATH

svnadmin hotcopy $SRCPATH/Project1 $DISTPATH/Project1 >/home/backup/svn/cpreport.log 2>&1;

svnadmin hotcopy $SRCPATH/Project2 $DISTPATH/Project2

cp $SRCPATH/access $DISTPATH; #备份access文件

cp $SRCPATH/passwd $DISTPATH; #备份passwd文件

perl /home/backup/svn/backup_check.pl #运行检查脚本

perl /home/backup/svn/deletDir.pl #运行删除脚本，对过期备份进行删除。

3）建立检查脚本

在上面指定的地方/home/backup/svn/下建立一个perl脚本：backup_check.pl

备份完整性检查的思路是：对备份的库运行 svnlook youngest，如果能正确打印出最新的版本号，则表明备份文件没有缺失；如果运行报错，则说明备份不完整。我试过如果备份中断，则运行svnlook youngest会出错。

4)定义删除脚本

由于是全量备份，所以备份不宜保留太多，只需要保留最近10来天的即可，对于超过15天历史的备份基本可以删除了。

在/home/backup/svn/下建立一个perl脚本：deletDir.pl

5）修改/etc/crontab 文件

在该文件中指定每晚21点执行“backup.sh”脚本。

svnsync备份

==============

使用svnsync备份很简单，步骤如下：

1）在备份机上创建一个空库：svnadmin create Project1

2）更改该库的钩子脚本pre-revprop-change（因为svnsync要改这个库的属性，也就是要将源库的属性备份到这个库，所以要启用这个脚本）:

cd SMP/hooks;

cp pre-revprop-change.tmpl pre-revprop-change;

chmod 755 pre-revprop-change;

vi pre-revprop-change;

将该脚本后面的三句注释掉，或者干脆将它弄成一个空文件。

3）初始化，此时还没有备份任何数据：

svnsync init file:///home/backup/svn/svnsync/Project1/ http://svntest.subversion.com/repos/Project1

语法是：svnsync init {你刚创建的库url} {源库url}

注意本地url是三个斜杠的：///

4）开始备份（同步）：

svnsync sync file:///home/backup/svn/svnsync/Project1

5）建立同步脚本

备份完毕后，建立钩子脚本进行同步。在源库/hooks/下建立/修改post-commit脚本，在其中增加一行，内容如下：

/usr/bin/svnsync sync --non-interactive file:///home/backup/svn/svnsync/Project1

你可能已经注意到上面的备份似乎都是本地备份，不是异地备份。实际上，我是通过将远程的备份机mount（请参阅mount命令）到svn服务器上来实现的，逻辑上看起来是本地备份，物理上实际是异地备份。

完！

以下是subversion官方推荐的备份方式。

关闭所有运行的进程，并确认没有程序在访问存储库（如 httpd、svnserve 或本地用户在直接访问）。
备份svn存储库
#压缩备份
svnadmin dump /home/workhome/svn/repository | gzip > ~/repository-backup.gz
#不压缩备份
svnadmin dump /home/workhome/svn/repository > ~/repository-backup.svn

恢复svn存储库

#建立新的svn存储库

svnadmin create /home/workhome/svn/newrepository

#确认成功与否

ls -l /home/workhome/svn/newrepository

#导入存储库数据

svnadmin load /home/workhome/svn/newrepository < ~/repository-backup.svn

SVN数据库迁移方法一

称之为SVN全库操作,或称SVN全局备份并恢复，版本库数据的移植:svnadmin dump、svnadmin load

导出:

$svnadmin dump repos > dumpfile //将指定的版本库导出成文件dumpfile

新建:

$svnadmin create newrepos

导入:

$svnadmin load newrepos < dumpfile

SVN数据库迁移方法二

增量备份或批次备份,批次恢复，特定reversion导出:

$svnadmin dump repos –r 23 >rev-23.dumpfile //将version23导出

$svnadmin dump repos –r 100:200 >rev-100-200.dumpfile //将version100~200导出

批次导出:对比较大的库可以批次导出，便于备份

$svnadmin dump repos –r 0:1000 >0-1000.dumpfile

$svnadmin dump repos –r 1001:2000 --incremental >1001-2000.dumpfile

$svnadmin dump repos –r 2001:3000 --incremental >2001:3000.dumpfile

批次导入，将这几个备份文件装载到一个新的版本库中

$svnadmin load newrepos < 0-1000.dumpfile

$svnadmin load newrepos < 1001-2000.dumpfile

$svnadmin load newrepos < 2001:3000.dumpfile

SVN数据库迁移方法三

导出后,在导入时对库做分库整理或其它整理操作过滤版本库历史:

假设有一个包含三个项目的版本库： calc，calendar，和 spreadsheet。它们在版本库中的布局如下：

calc/

trunk/

branches/

tags/

calendar/

trunk/

branches/

tags/

spreadsheet/

trunk/

branches/

tags/

现在要把这三个项目转移到三个独立的版本库中。首先，转储整个版本库：

$ svnadmin dump /path/to/repos > repos-dumpfile

* Dumped revision 0.

* Dumped revision 1.

* Dumped revision 2.

* Dumped revision 3.

然后，将转储文件三次送入过滤器，每次仅保留一个顶级目录，就可以得到三个转储文件：

$ cat repos-dumpfile | svndumpfilter include calc > calc-dumpfile

$ cat repos-dumpfile | svndumpfilter include calendar > cal-dumpfile

$ cat repos-dumpfile | svndumpfilter include spreadsheet > ss-dumpfile

现在你必须要作出一个决定了。这三个转储文件中，每个都可以用来创建一个可用的版本库，不过它们保留了原版本库的精确路径结构。也就是说，虽然项目calc 现在独占了一个版本库，但版本库中还保留着名为calc的顶级目录。如果希望trunk、tags和branches这三个目录直接位于版本库的根路径下，你可能需要编辑转储文件，调整Node-path和Copyfrom-path头参数，将路径calc/删除。同时，你还要删除转储数据中创建 calc目录的部分。一般来说，就是如下的一些内容：

Node-path: calc

Node-action: add

Node-kind: dir

Content-length: 0

警告:

如果你打算通过手工编辑转储文件来移除一个顶级目录，注意不要让你的编辑器将换行符转换为本地格式（比如将\r\n转换为\n）。否则文件的内容就与所需的格式不相符，这个转储文件也就失效了。

剩下的工作就是创建三个新的版本库，然后将三个转储文件分别导入：

$ svnadmin create calc; svnadmin load calc < calc-dumpfile

$ svnadmin create calendar; svnadmin load calendar < cal-dumpfile

$ svnadmin create spreadsheet; svnadmin load spreadsheet < ss-dumpfile

svndumpfilter 的两个子命令都可以通过选项设定如何处理“空”修订版本。如果某个指定的修订版本仅包含路径的更改，过滤器就会将它删除，因为当前为空的修订版本通常是无用的甚至是让人讨厌的。为了让用户有选择的处理这些修订版本，svndumpfilter提供了以下命令行选项：

--drop-empty-revs

不生成任何空修订版本，忽略它们。

--renumber-revs

如果空修订版本被剔除（通过使用--drop-empty-revs选项），依次修改其它修订版本的编号，确保编号序列是连续的。

--preserve-revprops

如果空修订版本被保留，保持这些空修订版本的属性（日志信息，作者，日期，自定义属性，等等）。如果不设定这个选项，空修订版本将仅保留初始时间戳，以及一个自动生成的日志信息，表明此修订版本由svndumpfilter处理过。

尽管svndumpfilter十分有用，能节省大量的时间，但它却是把不折不扣的双刃剑。首先，这个工具对路径语义极为敏感。仔细检查转储文件中的路径是不是以斜线开头。也许Node-path和Copyfrom-path这两个头参数对你有些帮助。

Node-path: spreadsheet/Makefile

如果这些路径以斜线开头，那么你传递给svndumpfilter include和svndumpfilter exclude的路径也必须以斜线开头（反之亦然）。如果因为某些原因转储文件中的路径没有统一使用或不使用斜线开头，也许需要修正这些路径，统一使用斜线开头或不使用斜线开头。

此外，复制操作生成的路径也会带来麻烦。Subversion支持在版本库中进行复制操作，也就是复制一个存在的路径，生成一个新的路径。问题是，svndumpfilter保留的某个文件或目录可能是由某个svndumpfilter排除的文件或目录复制而来的。也就是说，为了确保转储数据的完整性，svndumpfilter需要切断这些复制自被排除路径的文件与源文件的关系，还要将这些文件的内容以新建的方式添加到转储数据中。但是由于Subversion版本库转储文件格式中仅包含了修订版本的更改信息，因此源文件的内容基本上无法获得。如果你不能确定版本库中是否存在类似的情况，最好重新考虑一下到底保留/排除哪些路径。

备份环境注意点：

1、确保没有其他进程访问版本库，关闭apache、svnserve服务

2、成为版本库的管理员，如果以其他身份还原版本库，可能会改变版本库文件的访问权限，导致在恢复后依旧无法访问

3、svnadmin recover /path/to/repos

4、重新启动服务进程

SVN数据库整理方法

不经过dump,load操作,实现SVN数据库整理操作，先设计好调整后的目录, 然后打开版本库, 选中要调整或转移的文件(文件夹)-->右键拖住,不要松手-->然后将要转移的文件(文件夹)拖至目标文件夹-->松手--> 选择move items to here-->完成

每经过这样的调整,大家都会担心历史记录是否还会存在, TortoiseSVN在默认情况下, 是不会显示出来的,需要将一个选项去除.

如此可实现基于库的调整操作,但事事不是尽如人意的,这样的一次操作下来,revision会增长好多。

我的想法是:

停止当前 SVN服务,将当前的SVN库直接进行整理,就像整理存储在电脑中的文件夹一样,然后开启SVN服务,即时显示调整后的效果,哈哈..是不是有点异想天开,其实我也觉得这是不太可能的,除非使用工具访问,否则SVN库不是显示可见的,希望以后啥配置管理工具可以让管理员有这样的权限.

实验：