Backup Specified Revision

1. Backup specified revision (here is 20):

$ cd /opt/svnRepo

$ svnadmin dump deployTest/ -r 20 > deploy-r20.dump

1. Restore backup:

$ mv deploy-r20.dump /opt/Gcp/tmp

$ cd /opt/Gcp/tmp

$ svnadmin create deploy20

$ svnadmin load deploy20 < deploy-r20.dump

Verify

1. Get revision 20 of "deploy.exp" in original repository

$ svn cat -r 20 file:///opt/svnRepo/deployTest/CalcServer/deploy.exp > r20

1. Get "deploy.exp" in restored repository

$ svn cat file:///opt/Gcp/tmp/deploy20/CalcServer/deploy.exp > restore20

1. Compare them:

$ diff r20 restore20

They are identical.

1. Compare logs:

[root@cloud141 /opt/svnRepo]$ svn log -r 20 file:///opt/svnRepo/deployTest/

r20 | bvt | 2013-08-30 17:30:03 +0800 (Fri, 30 Aug 2013) | 1 line remove unittest in source file

[root@cloud141 /opt/svnRepo]$ svn log file:///opt/Gcp/tmp/deploy20

r1 | bvt | 2013-08-30 17:30:03 +0800 (Fri, 30 Aug 2013) | 1 line remove unittest in source file

So you can see the restored repository is identical to that part of original repository except the revision number.

Backup Specified Revisions

$ svnadmin dump deployTest/ -r 10:20 > deploy-r20.dump

Incremental Backup

1. Backup:

$svnadmin dump myrepos -r 0:1000 > 0-1000.dumpfile $svnadmin dump myrepos -r 1001:2000 --incremental > 1001-2000.dumpfile $svnadmin dump myrepos -r 2001:3000 --incremental > 2001:3000.dumpfile

1. Restore:

$svnadmin load myrepos < 0-1000.dumpfile $svnadmin load myrepos < 1001-2000.dumpfile $svnadmin load myrepos < 2001:3000.dumpfile

Experiment on incremental dump

1. Create a incremental backup: [root@cloud141 /opt/svnRepo]$ svnadmin dump deployTest/ --incremental -r 9:11 > r9-11.dump
2. Create a full backup: [root@cloud141 /opt/svnRepo]$ svnadmin dump deployTest/ -r 9:11 > backup9-11.dump
3. Compare the size of these two dump files, full backup is obviously larger than the incremental counterpart: [root@cloud141 /opt/svnRepo]$ ll total 984 -rw-r--r-- 1 root root 997105 Oct 31 19:08 backup9-11.dump drwxr-xr-x 6 root root 4096 Aug 22 18:09 deployTest -rw-r--r-- 1 root root 2509 Oct 31 19:07 r9-11.dump
4. Restore a incremental backup in a fresh repository: [root@cloud141 /opt/svnRepo]$ mv r9-11.dump ../Gcp/tmp [root@cloud141 /opt/Gcp/tmp]$ svnadmin create new9 [root@cloud141 /opt/Gcp/tmp]$ svnadmin load new9 < r9-11.dump <<< Started new transaction, based on original revision 9 svnadmin: File not found: transaction ‘0-0‘, path ‘CalcServer/src/com/boco/deploy/ConfigLoader.java‘
5. editing path : CalcServer/src/com/boco/deploy/ConfigLoader.java ...[root@ You can see the restore failed.
6. Restore a incremental backup (revision 9~11) in a "root" repository (restored from revision 8) : [root@cloud141 /opt/Gcp/tmp]$ svnadmin load backup8 < r9-11.dump ... [root@cloud141 /opt/Gcp/tmp]$ svn log file:///opt/Gcp/tmp/backup8

r4 | bvt | 2013-08-30 16:35:10 +0800 (Fri, 30 Aug 2013) | 1 line initial import project

r3 | bvt | 2013-08-30 15:31:47 +0800 (Fri, 30 Aug 2013) | 1 line make new project basedir

r2 | bvt | 2013-08-29 14:32:15 +0800 (Thu, 29 Aug 2013) | 1 line remove unittest in source file to pass compile without junit

r1 | bvt | 2013-08-29 14:31:10 +0800 (Thu, 29 Aug 2013) | 1 line remove unittest in source file to pass compile without junit

Now the restore succeed.

Summary

Backup a huge repository in the following steps:

1. Execute a full backup at a revision. If the revision n is not 0, you will lose all revisions from 0 to n-1;

2. Execute incremental backups weekly, use the revision arrange as file name: "inc-rev-from-to.dump", like "inc-rev-35-46.dump";

3. When original repository corrupts, first load the full backup, then load the incremental ones according to their revision numbers;

Ref:

• SVN版本库的备份、还原、移植（初级篇、中级篇和高级篇）

• SVN备份及其还原——dump/load方法

Subversion Backup and Restore,布布扣,bubuko.com

Subversion Backup and Restore

原文：http://www.cnblogs.com/darkmatter/p/3606753.html