轉自： http://spiritfrog.iteye.com/blog/448578 + http://magnet2008.iteye.com/blog/586578
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種方法麻煩。
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 hotcopy path/to/repository path/to/backup –clean-logs
svnadmin dump
==============
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
...
因此這是俺青睞的備份方式。
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
fi
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”腳本。
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庫不是顯示可見的,希望以后啥配置管理工具可以讓管理員有這樣的權限.
實驗：
一、在遷出服務器執行：
svn@Africa:~/csvn/bin> csvn stop
Stopping CSVN Console...
Waiting for CSVN Console to exit...
Waiting for CSVN Console to exit...
Stopped CSVN Console.
svn@Africa:~/csvn/bin> csvn-httpd stop
Stopping Subversion Edge Apache Server: done
svn@Africa:~/csvn/data/repositories> svnadmin dump /home/svn/csvn/data/repositories/camp | gzip >camp_dumpfile_20130610.gz
......
* Dumped revision 4495.
* Dumped revision 4496.
svn@Africa:~/csvn/data/repositories> ls
camp camp_dumpfile_20130610.gz cpst csvn csvn-httpd docm
二、在遷入服務器執行：
取遷出服務器上導出的文件camp_dumpfile_20130610.gz；
csvn@campostdev:~/data/repositories> svnadmin create /home/csvn/data/repositories/newcamp
csvn@campostdev:~/data/repositories> gzip -d camp_dumpfile_20130610.gz
csvn@campostdev:~/data/repositories> svnadmin load /home/csvn/data/repositories/newcamp < camp_dumpfile_20130610
......
<<< Started new transaction, based on original revision 4495
* editing path : trunk/site/campost/src/dsp/frmDomItemMod.mcpp ... done.
* editing path : trunk/site/campost/src/dsp/frmIntItemMod.mcpp ... done.
------- Committed revision 4495 >>>
<<< Started new transaction, based on original revision 4496
* editing path : trunk/site/campost/src/dsp/frmDspInterCloseDisp.mcpp ... done.
------- Committed revision 4496 >>>
csvn@campostdev:~/bin> csvn start
Starting CSVN Console......
CSVN Console started
Waiting for application to initialize (this may take a minute)...............................................
CSVN Console is ready at http://localhost:3343/csvn
csvn@campostdev:~/bin> csvn-httpd start
Starting Subversion Edge Apache Server:
參考：
http://developer.51cto.com/art/201005/202261.htm
http://www.cnblogs.com/itech/archive/2011/10/11/2206988.html
http://www.cnblogs.com/jifeng/p/4196238.html