svn備份的方式有三種:
1svnadmin dump
2)svnadmin hotcopy
3)svnsync.
優缺點分析
==============
第一種svnadmin dump是官方推薦的備份方式,優勢是比較靈活,能夠全量備份也能夠增量備份,並提供了版本恢復機制。
缺點是:若是版本比較大,如版本數增加到數萬、數十萬,那麼dump的過程將很是慢;備份耗時,恢復更耗時;不利於快速進行災難恢復。
我的建議在版本數比較小的狀況下使用這種備份方式。
第二種svnadmin hotcopy原設計目的估計不是用來備份的,只能進行全量拷貝,不能進行增量備份;
優勢是:備份過程較快,災難恢復也很快;若是備份機上已經搭建了svn服務,甚至不須要恢復,只須要進行簡單配置便可切換到備份庫上工做。
缺點是:比較耗費硬盤,須要有較大的硬盤支持)。
第三種svnsync其實是製做2個鏡像庫,當一個壞了的時候,能夠迅速切換到另外一個。不過,必須svn1.4版本以上才支持這個功能。
優勢是:當製做成2個鏡像庫的時候起到雙機實時備份的做用;
以上不是本身觀點,下面真實記錄個人svn sync實驗過程
兩臺機器
server1: 192.168.1.224
server2: 192.168.1.225
都是centos6.5環境
首先在sever1上搭建好了一個svn,而後模擬提交了一些東西
而後在sever2上搭建了一個如出一轍的svn,保持空的
如今的目的是將server1同步備份到server2
在server1上直接運行:
svnsync init svn://192.168.1.225/ svn://192.168.1.224/
即svnsync init 目標svn連接 源svn連接,執行同步以前的初始化
這一步失敗了,報以下錯誤:
svnsync: Repository has not been enabled to accept revision propchanges;
ask the administrator to create a pre-revprop-change hook
提示須要在hooks下面建立一個pre-revprop-change hook
簡單解釋下,hook相似於操做系統的勾子,svn會在收到一些操做請求的時候執行hooks目錄下的對應的腳本,例如想要commit的時候作一些事情就能夠在對應的腳本下面添加你要執行的命令,下一次在commit 的時候就會觸發執行
一開始沒明白,不知道應該在源機器上建立仍是在目標機器上建立,實際上是在目標機器上建立的
而後在目標機器上copy了一份pre-revprop-change.tmpl成pre-revprop-change
再次執行初始化命令
依然報錯,此次的錯誤不同了
svnsync: Revprop change blocked by pre-revprop-change hook (exit code 255) with no output.
大概就是同步的過程當中剛剛建立的hook調用沒有成功,而後嘗試給pre-revprop-change添加可執行權限,依然失敗
依然失敗,依然失敗,在stack overflow上看到有人提出的解決方法是把pre-revprop-change改爲下面這個樣子:
再次初始化,終於成功,提示先讓你輸入用戶名密碼,最後一步的輸出以下:
後來通過驗證,確實須要可執行權限,改了以後仍是失敗的緣由是hooks執行的結果是失敗的,確實執行了
這一步成功以後,下一步同步就直接成功了:
svnsync sync svn://192.168.1.225/
執行這個命令會把沒有同步的版本都同步過去
而後爲了讓server1每次有更新以後都自動同步到server2,能夠在server1的commit的hooks最後加上執行一下同步的命令:
svnsync sync svn://192.168.1.225/
這樣就完美實現了實時備份,並且在server1出現問題的時候隨時均可以直接切換到server2喲
最後有一點要注意的是,我嘗試備份到一個不爲空的svn,也就是目標svn已經存在要備份的repos的時候,是會失敗的,所以,只能備份到一個空的svn
最後還有一個很是重要的要注意的問題就是,若是在直接在目標在作了修改的話,那麼後面就沒有辦法同步了,都會失敗,因此,禁止在備份svn上直接作任何操做,這裏的花建議專門寫一個腳本,在post-commit勾子裏面調用,經過腳原本同步,而後判斷一下是否同步成功,若是同步失敗了須要及時處理,好比能夠給相關人員發郵件通知及時處理,防止同步失敗了致使server1一旦宕機以後忽然發現server2早就沒有同步了就晚了。