svn備份到伺服器

1、SVN的操作說明以及備份策略

百萬級訪問量網站的技術准備工作
當今從純網站技術上來說，因為開源模式的發展，現在建一個小網站已經很簡單也很便宜，所以很多人都把創業方向定位在互聯網應用。這些人里大多數不是很懂技術，或者不是那麼精通，而網站開發維護方面的知識又很分散，學習成本太高，所以這篇文章將這些知識點結合起來，系統的來說，一個從日幾千訪問的小小網站，到日訪問一兩百萬的小網站，中間可能會產生什麼問題，以及怎麼才能在一開始做足工作盡量避免這些問題。

你的網站因為努力經營，訪問量逐漸升高，在升高的過程中，問題也可能開始顯現了。因為帶寬的增加、硬體的擴展、人員的擴張所帶來的成本提高是顯而易見的，而還有相當大的一部分成本是因為代碼重構、架構重構，甚至底層開發語言更換引起的，最壞的情況就是數據丟失，所有努力付之一炬。這類成本支出大多數在一開始就可以避免，先打好基礎，往後可以省很多精力，少操很多心。

對於不同的初期投資成本，技術路線的選擇是不同的。這里假設網站剛剛只是一個構想，計劃第一年伺服器硬體帶寬投入5萬左右。對於這個資金額度，有很多種方案可選擇，例如租用虛擬主機、租用單獨伺服器，或者流行的私有雲，或者託管伺服器。前兩種選擇，網站發展到一定規模時需遷移，那時再重做規劃顯然影響更大。伺服器託管因為配置自主、能完全掌握控制權，所以有一定規模的網站基本都是這種模式。採用自己託管伺服器的網站，一開始要注意以下幾點——

一、開發語言
一般來說，技術人員（程序員）都是根據自己技術背景選擇自己最熟悉的語言，不過不可能永遠是一個人寫程序，所以在語言的選擇上還要是要費些心思。首先明確一點，無論用什麼語言，最終代碼質量是看管理，因此我們從前期開發成本分析。現在國內流行的適用於網站的語言，大概有java、php、.net、 python、ruby這五大陣營。python和ruby因為在國內流行的比較晚，現在人員還是相對難招一些。.net平台的人相對多，但是到後期需要解決性能問題時，對人員技能的要求比較高。剩餘的java、php用人可以說是最多的。java和php無法從語言層面做比較，但對於初期，應用幾乎都是靠前端支撐的網站來說，php入門簡單、編寫快速，優勢相對大一點。至於後端例如行為分析、銀行介面、非同步消息處理等，等真正需要時，就要根據不同業務需求來選擇不同語言了。

二、代碼版本管理
稍微有點規模的網站就需要使用代碼版本管理了。代碼版本管理兩點最大的好處，一是方便協同工作，二是有歷史記錄可查詢比較。代碼版本管理軟體有很多，vss/cvs/svn/hg等，目前國內都比較流行，其中svn的普及度還是很高的。

假設選了svn，那麼有幾點考慮。一是採用什麼樹結構。初期可能只有一條主幹，往後就需要建立分支，例如一條開發分支，一條上線分支，再往後，可能要每個小組一個分支。建議一開始人少時選擇兩條分支，開發和線上，每個功能本地測試無誤後提交到開發分支，最後統一測試，可以上線時合並到上線分支。如果每人都建自己的分支，合並時會浪費很大精力，對於幾乎每天都要修改幾次的WEB應用來說，所費時間太多。

向伺服器部署代碼，可以手工部署也可以自動部署。手工部署相對簡單，一般可直接在伺服器上svn update，或者找個新目錄svn checkout，再把web root給ln -s過去。應用越復雜，部署越復雜，沒有什麼統一標准，只是別再用ftp上傳那種形式，一是上傳時文件引用不一致錯誤率增加，二是很容易出現開發人員的版本跟線上版本不一致，導致本來想改個錯字結果變成回滾。如果有多台伺服器還是建議自動部署，更換代碼的機器從當前服務池中臨時撤出，更新完畢後再重新加入。

三、伺服器硬體
在各個機房裡，靠一台伺服器孤獨支撐的網站數不清，但如果資金稍微充足，建議至少三台的標准配置，分別用作web處理、資料庫、備份。web伺服器至少要8G內存，雙sata raid1，如果經濟稍微寬松，或靜態文件或圖片多，則15k sas raid10。資料庫至少16G內存，15k sas raid 10。備份伺服器最好跟資料庫伺服器同等配置。硬體可以上整套品牌，也可以兼容機，也可以半品牌半組裝，取決於經濟能力。當然，這是典型的搭配，有些類型應用的性能瓶頸首先出現在web上，那種情況就要單獨分析了。

web伺服器可以既跑程序又當內存緩存，資料庫伺服器則只跑主資料庫（假如是MySQL的話），備份伺服器所承擔就相對多一些，web配置、緩存配置、資料庫配置都要跟前兩台一致，這樣WEB和資料庫任意一台出問題，很容易就可以將備份伺服器切換過去臨時頂替，直到解決完問題。要注意，硬體是隨時可能壞掉的，特別是硬碟，所以寧可WEB伺服器跟資料庫伺服器放在一起，也一定不能省掉備份，備份一定要異機，並且有非同步，電力故障、誤操作都可能導致一台機器上的所有數據丟失。很多的開源備份方案可選擇，最簡單的就是rsync，寫crontab里，定時同步。備份和切換，建議多做測試，選最安全最適合業務的，並且盡可能異地備份。

四、機房
三種機房盡量不要選：聯通訪問特別慢的電信機房、電信訪問特別慢的聯通機房、電信聯通訪問特別慢的移動或鐵通機房。機房要盡可能多的實地參觀，多測試，找個網路質量好，管理嚴格的機房。機房可以說是非常重要，直接關繫到網站訪問速度，網站訪問速度直接關繫到用戶體驗，訪問速度很慢的網站，很難獲得用戶青睞。

五、架構
在大方向上，被熟知的架構是web負載均衡+資料庫主從+緩存+分布式存儲+隊列。在一開始，按照可擴展的原則設計和編程就可以。只是要多考慮緩存失效時的雪崩效應、主從同步的數據一致性和時間差、隊列的穩定性和失敗後的重試策略、文件存儲的效率和備份方式等等意外情況。緩存失效、資料庫復制中斷、隊列寫入錯誤、電源損壞，在實際運維中經常發生，如果不注意這些，出現問題時恢復期可能會超出預期很長時間。

六、伺服器軟體
操作系統Linux很流行。在沒有專業運維人員的情況下，應傾向於擇使用的人多、社區活躍、配置方便、升級方便的發行版，例如RH系列、 debian、ubuntu server等，硬體和操作系統要一起選擇，看是否有適合的驅動，如果確定用某種商業軟體或解決方案，也要提前知曉其對哪種操作系統支持最佳。web伺服器方面，apache、nginx、lighttpd三大系列中，apache佔有量還是最大，但是想把性能調教好還是需要很專業的，nginx和 lighttpd在不需要太多調整的情況下可以達到一個比較不錯的性能。無論選擇什麼軟體，除非改過這些軟體或你的程序真的不兼容新版本，否則盡量版本越新越好，版本新，意味著新特性增多、BUG減少、性能增加。一個典型的php網站，基本上大多數人都沒改過任何伺服器軟體源代碼，絕大多數情況是能平穩的升級到新版本的。類似於jdk5到 jdk6，python2到python3這類變動比較大的升級還是比較少見的。看看ChangeLog，看看升級說明，結合自己情況評估測試一下，越早升級越好，升級的越晚，所花費的成本越高。對於軟體包，盡量使用發行版內置的包管理工具，沒有特殊要求時不建議自己編譯，那樣對將來運維不利。

七、資料庫
幾乎所有操作最後都要落到資料庫身上，它又最難擴展（存儲也挺難）。資料庫常見的擴展方法有復制、分片，設計時要考慮到每種應用的數據如何復制、分片，當然這種考慮一般會推遲到技術設計時期。在初期進行資料庫結構設計時，要根據不同的業務類型和增長量預期來考慮是否要分庫、分區，並且盡量不要使用聯合查詢、不使用自增ID以方便分片。復制延時問題、主從資料庫數據一致性問題，可以自己寫或者用已有的運維工具進行檢測。

用存儲過程是比較難擴展的，這種情形多發生於傳統C/S，特別是OA系統轉換過來的開發人員。低成本網站不是一兩台小型機跑一個資料庫處理所有業務的模式，是機海作戰。方便水平擴展比那點預分析時間和網路傳輸流量要重要的多的多。

另外，現在流行一種概念叫NoSQL，可以理解為非傳統關系型資料庫。實際應用中，網站有著越來越多的密集寫操作、上億的簡單關系數據讀取、熱備等，這都不是傳統關系資料庫所擅長的，於是就產生了很多非關系型資料庫，比如Redis/TC&TT/MongoDB/Memcachedb等，在測試中，這些幾乎都達到了每秒至少一萬次的寫操作，內存型的甚至5萬以上。在設計時，可根據業務特點和性能要求來選擇是否使用這類資料庫。例如 MongoDB，幾句配置就可以組建一個復制+自動分片+failover的環境，文檔化的存儲也簡化了傳統設計庫結構再開發的模式。但是當你決定採用一項技術時，一定要真正了解其優劣，例如可能你所選擇的技術並不能支持你所需要的事務和數據一致性要求。

八、文件存儲
存儲的分布幾乎跟資料庫擴展一樣困難，不過只有百萬的PV的情況下，磁碟IO方面一般不會成大問題，一兩台採用SATA做條帶RAID的機器可以應付，反而是自己做非同步備份比較復雜，因為小文件多。如果只有一台機器做存儲，可以做簡單的優化，例如放最小縮略圖的分區和放中等縮略圖的分區，根據平均大小調整一下塊大小。存儲要規劃好目錄結構，否則文件增多後維護起來復雜，也不利於擴展。同時還要考慮將來擴容，例如採用LVM，或者把文件根據不同規則散列到不同機器。磁碟IO繁重的情況下更容易出現故障，所以要做好備份，若發現有盤壞掉，要馬上行動更換，很多人的硬碟都是壞了一塊之後，接二連三的壞下去。

為了將來圖片走cdn做准備，一開始最好就將圖片的域名分開，且不用主域名。因為很多網站都將cookie設置到了.domain.ltd，如果圖片也在這個域名下，很可能因為cookie而造成緩存失效，並且佔多餘流量，還可能因為瀏覽器並發線程限製造成訪問緩慢。

九、程序
一定硬體條件下，應用能承載多少訪問量，很大一部分也取決於程序如何寫。程序寫的不好，可能一萬的訪問都承載不了，寫的好，可能一兩台機器就能承擔幾百萬PV。越是復雜、數據實時性要求越高的應用，優化起來越難，但對普通網站有一個統一的思路，就是盡量向前端優化、減少資料庫操作、減少磁碟IO。向前端優化指的是，在不影響功能和體驗的情況下，能在瀏覽器執行的不要在服務端執行，能在緩存伺服器上直接返回的不要到應用伺服器，程序能直接取得的結果不要到外部取得，本機內能取得的數據不要到遠程取，內存能取到的不要到磁碟取，緩存中有的不要去資料庫查詢。減少資料庫操作指減少更新次數、緩存結果減少查詢次數、將資料庫執行的操作盡可能的讓你的程序完成（例如join查詢），減少磁碟IO指盡量不使用文件系統作為緩存、減少讀寫文件次數等。程序優化永遠要優化慢的部分，換語法是無法「優化」的。

然而編程時不應該把重點放在優化上，應該關注擴展性。當今的WEB應用，需求變化非常之快，適應多種需求的架構是不存在的，我們的擴展性就要把要點放在跟底層交互的架構上，例如持久化數據的存取規則、緩存的存取規則等，還有一些共用服務，例如用戶信息等。先把不變的部分做完善，剩下的部分就很容易將精力放在業務邏輯上面了。

2、您好，請問能詳細解說一下windows下SVN備份嗎？如何詳細操作？謝謝您

SVN有兩種備份機制：
1、hotcopy，可以實現增量或全庫的熱備，具體的指令參數可以查看svn hotcopy的幫助；
2、svnsync，本用作svn伺服器間的同步，也常被用作備份。我個人喜歡這種備份方式，我詳細說一下這種方法吧。
svnsync是用作將源伺服器的某個版本庫同步到備份伺服器，同步完成後兩個伺服器的內容是完全一樣的，免去了將hotcopy的結果進行還原的操作。
我一般將這個命令放在post-commit這個鉤子里（伺服器端該版本庫hooks文件夾下post-commit.bat），這樣的話每次有人進行commit操作就會觸發這個鉤子，就會自動執行同步操作，這樣就實現了實時備份。
要用svnsync實現實時備份需要這么操作：
1、在備份伺服器（其實也可以是同一個伺服器上的另一個版本庫，比如源版本庫是放在D盤上，備份版本庫我放在移動硬碟上）上創建備份版本庫，空的，什麼都不要添加，配置該版本庫的許可權為只有用於備份的ID可以讀寫，其他人頂多給個只讀許可權，絕對不要給別人寫的許可權，因為一旦有人往這個版本庫做了commit操作，就會無法繼續同步了。
2、給備份版本庫的hooks文件夾下加一個pre-revprop-change.bat鉤子，鉤子內容就一句exit 0
3、執行svnsync init操作，將源版本庫、目標版本庫關聯起來
4、在源版本庫的hooks文件夾下加一個post-commit.bat鉤子，內容一般兩句就夠了：
svnsync sync XXXXXXXXXXXXXXX
svnsync copy-revprops XXXXXXXXXXXXXXX
關於svnsync init、svnsync sync、svnsync copy-revprops 後面的參數，查看隨機幫助吧。

3、svn伺服器的代碼可以同步到伺服器嗎

開發過程中，需要經常將SVN伺服器上的代碼同步到測試伺服器上，一般做法，需要人工手工更新，這樣很浪費工夫。下面的腳本為svn server的鉤子程序，放在svn伺服器上，只要代碼更新，就會自動提交的測試伺服器上。

使用條件：

1、SVN主機是WIN系統，如果要在LINUX的SVN主機上用，需要修改下面的代碼為sh腳本，道理類似，代碼不同。有需要的自行更改吧。

2、SVN主機上需要安裝完整版的PUTTY安裝包，而不是一個EXE.

3、測試伺服器可以用putty登錄

@echo off

setlocal enableDelayedExpansion

rem 本腳本實現將SVN伺服器A(win環境)上提交的代碼，自動上傳(通過pscp)到測試環境的伺服器B(linux)上，如果SVN在LINUX環境下，根據本代碼自行調整。

rem svn伺服器上版本庫地址

set reposLoc=%1

set REV=%2

rem ---------------------------------------------------------------------- 配置開始

rem svn伺服器上putty的路徑

set puttyPath="D:Program Files (x86)PuTTY"

rem 測試環境putty登錄的用戶名

set username=root

rem 測試環境putty登錄的密碼

set password=password

rem 測試環境IP

set host=10.1.1.1

rem 測試環境代碼根地址

set remoteRootPath=/var/www/htdocs/test

rem ---------------------------------------------------------------------- 配置結束

cd /d %puttyPath%

rem 遍歷提交了的代碼

for /f "tokens=2 delims= " %%i in ('svnlook changed %reposLoc%') do (

set "var=%%i"

svnlook cat !reposLoc! !var! > temp.txt

rem 替掉路徑中的trunk

set newPath=!var:trunk=!

rem 通過pscp提交到測試伺服器

echo y | pscp -l  !username! -pw !password! temp.txt !host!:!remoteRootPath!!newPath!

)

使用方法：

將上面的代碼中配置區的變數修改，並將內容保存成bat文件，命名為post-commit.bat，放在SVN伺服器上版本庫的hooks目錄下。提交代碼試試看吧。經測試可行。

當然，這個腳本可以再做的牛比點兒，可以針對某個用戶的提交做更新，也可以分析SVN提交時的日誌，只有當日誌中有特定的字元時更新。

另外，由於上面的腳本，只更新當前的提交，所以假設只針對某個用戶的提交做更新時，不能只更新當前提交，這樣其它用戶的提交就落掉了，需要更新整個工程。

4、SVN伺服器如何備份與還原

我是全部獲取最新，復制到備份目錄。
還原嗎，刪除有問題的文件或目錄，復制備份的文件或目錄到svn的工作目錄，選擇增加就上傳了。

5、SVN 文件同步到伺服器問題

你需要更加詳細的描述這幾個伺服器之間的關系，那才好判斷問題出在內哪裡。

從你現在描述容的信息來看，似乎是相互矛盾的，你描述的這個系統是沒法正常工作的。

一般來說，架構和流程會是這樣的，SVN伺服器會通過post-commit鉤子，自動將更新後的文件部署到測試伺服器，在測試伺服器上測試通過沒有問題後，將當前版本再部署到主伺服器上對外發布（這一步一般不會是SVN自動執行的，應該是由另一個工具來發起的）。

詳細描述以下問題吧：
1、測試伺服器、主伺服器分別是做什麼用的？
2、你測試伺服器和主伺服器之間SVN是用什麼機制同步的？
3、主伺服器除了從測試伺服器同步數據過來之外，還有沒有其他方式會修改上面的文件？

6、visual svn把項目服務端保存在哪裡了，備份的時候備份哪個文件夾？

問題一：

具體路徑是在檢出的時候設置的，如果不知道的話，可以通過電腦全盤搜索「.svn」文件進行svn檢出路徑定位（因為所有的svn文件都有有一個.svn文件）。

問題二：

備份的時候，先復制項目到想備份的位置，全項目搜索「.svn」文件，之後刪除此類型的所有問題，備份剩下的文件即可。

7、公司里有台機器作為SVN的伺服器，現在我想另找一台電腦，然後將SVN中的數據備份到這台電腦上，該怎麼辦？

1.把你的另一台電腦的硬碟拔下來

2.拔下來的硬碟插到要拷貝伺服器的主板介面

3.打開伺服器的電腦後會多出個盤

4.把所有東西全部拷貝到新盤上（通俗點剪切復制）

5.拷貝好後拔下來在裝回原電腦

妥了，希望幫到你。

8、怎麼svn伺服器上的 資料庫備份到本地？

將本地的記錄修改成與伺服器上的一致。也就是說，將本地與伺服器上不同的地方，改成與伺服器上的一樣。
svn備份一般採用三種方式：
1）svnadmin mp
2)svnadmin hotcopy
3)svnsync.

注意，svn備份不宜採用普通的文件拷貝方式（除非你備份的時候將庫暫停），如copy命令、rsync命令。
筆者曾經用 rsync命令來做增量和全量備份，在季度備份檢查審計中，發現備份出來的庫大部分都不可用，因此最好是用svn本身提供的功能來進行備份。

優缺點分析
==============
第一種svnadmin mp是官方推薦的備份方式，優點是比較靈活，可以全量備份也可以增量備份，並提供了版本恢復機制。
缺點是：如果版本比較大，如版本數增長到數萬、數十萬，那麼mp的過程將非常慢；備份耗時，恢復更耗時；不利於快速進行災難恢復。
個人建議在版本數比較小的情況下使用這種備份方式。
第二種svnadmin hotcopy原設計目的估計不是用來備份的，只能進行全量拷貝，不能進行增量備份；
優點是：備份過程較快，災難恢復也很快；如果備份機上已經搭建了svn服務，甚至不需要恢復，只需要進行簡單配置即可切換到備份庫上工作。
缺點是：比較耗費硬碟，需要有較大的硬碟支持（俺的備份機有1TB空間，呵呵）。
第三種svnsync實際上是製作2個鏡像庫，當一個壞了的時候，可以迅速切換到另一個。不過，必須svn1.4版本以上才支持這個功能。
優點是：當製作成2個鏡像庫的時候起到雙機實時備份的作用；
缺點是：當作為2個鏡像庫使用時，沒辦法做到「想完全拋棄今天的修改恢復到昨晚的樣子」；而當作為普通備份機制每日備份時，操作又較前2種方法麻煩。

9、TortoiseSVN的伺服器如何轉移到另一台電腦?

遷移的3種方法：
1、直接拷貝原庫的目錄到另一台伺服器，然後啟動服務，即可版使用。
2、使用備份命令權svnsync備份的目標庫，與直接copy的區別在於版本號0，需要重新配置下許可權，啟動服務，即可訪問；
3、在另一台伺服器上create一個新庫，使用命令行：svnadmin mp 舊庫路徑 |svnadmin load 新庫路徑，啟動服務後，即可訪問；
遷移之前，通知使用庫的所有人員，先行暫停對版本庫的操作，然後停止該庫的svn服務（若svn服務為命令行窗口，關閉即可；若為系統服務，cmd-〉services.msc，找到對應庫的svn服務，右鍵菜單「停止」）。