公司有一個行業性的招商網站,放在萬網的獨享主機上,萬網的機房在北京. 公司在浙江,本來是一月手動備份一次網站跟資料庫的,現在需要更頻繁的備份資料庫跟網站檔案,如果還是按手動在伺服器上打包網站與資料庫,然後ftp下來,由於現在網站資料庫記錄在10萬+,網站檔案總大小也過10G,壓縮後的大小也在5G左右,因此每天ftp下載很占時間,況且公司上網是ADSL,10台電腦頻寬一分,ftp下載速度經常在10kb-200kb之間,200kb只在早上9:00前才有的速度.因此每天來一次整站打包壓縮後再下載根本不合適,況且公司沒專門網管,一邊做備份,一邊還要寫程式根本就忙不過來.
基於以上原因,採用整體打包的辦法,一個月來一次還好,但是一天來一次就不行了,於是就考慮增量備份,即每天把變化的檔案下載下來,那些沒變動的就不去下載,這樣一來每天需要下載的資料量就很少了,按照這樣的思路我在網上找了些備份工具,比如:super Flexible File Synchronizer ,一個很不錯的軟體,因為備份伺服器(公司裡的電腦)ADLS上網,沒固定IP,於是就把SFFS按裝在本地電腦,web伺服器配置ftp,但是問題來了由於公司網站目錄裡檔案太多,SFFS經常出現無法響應,因為SFFS是一次性擷取目錄裡的所有檔案清單,接著跟本地的檔案比較修改時間,因目錄裡檔案已經過幾萬,一個列表擷取操作經常無法完成,導致同步無法繼續,其他一些能找到的ftp軟體也是因為不是專門為網站備份設計的,往往存在這樣那樣的問題,3天時間找下了,我決定放棄使用現成的軟體而是自己使用.net開發一套.
既然決定自己開發了,那麼幾個技術點必需解決,首先是大檔案下載. 要有續傳功能,另外要確定增量備份時那些檔案需要備份,
這個首先想到的是採用FileSystemWatch記錄目錄裡的檔案變動,在把變動的資訊發送的用戶端,而用戶端根據變動做相應的操作. 然而目錄是連續變動的,fsw就需要連續記錄變化並把變化反映到用戶端,因此只要期間出現錯誤,將影響到後繼的同步,即兩次同步操作間有比較大的聯絡,具體的在電腦上測試了下
使用FileSystemWatch監視網站目錄,將變動記錄到MSSQ(訊息佇列),然後備份伺服器定期訪問隊列,根據裡面的資訊進行檔案同步,每處理一條資訊就移動掉,感覺很簡單,不過處理起來就不那麼容易了,FSW產生的命令你不能簡單的在用戶端重複,你需要對這些命令的先後順序,組合做一些處理,比方你修改個檔案,那麼FileSystemWatche經常會觸發2-10次不等的同一事件,當時我還考慮記錄重名命等操作,結果搞的是燒焦爛額,情急下不得不尋求另外簡單的解決辦法(當然上面的方法是可行的,只是你需要考慮的東西比較多).
新想到辦法是採用資料庫,因為目錄裡的檔案是按時間聯絡變化的,那麼在某個時間點我們記錄下目錄裡檔案的狀態,待下次同步時只要比較目錄裡的檔案跟,資料庫裡的記錄則可以得出那些檔案是修改了,那些檔案是增加的, 需要注意的是,由於是備份,網站上那些被刪除的檔案(不管是有意無意,還是惡意的)是不做記錄的,另外對於檔案重名,可以不去管,當新檔案下載就是,公司網站多是些圖片或文字檔,多一個少一個下載不是問題,而檔案夾同重新命名基本是不會發生的,尤其是那些有幾萬個檔案的檔案夾一旦重新命名將會導致幾萬個檔案下載,但是這個情況多半發生在惡意重新命名,好在檔案夾一但被重新命名經常導致網站訪問問題,或者同步程式出問題,這個很容易就能被發現,並及時得到處理,而且,同步程式不是比較目錄下全部的檔案,而是按照檔案更新時間前後取前幾個檔案(具體的看這個檔案夾每天具體的增量,公司目前前取100則可),因此即使含有大量檔案的檔案夾被重新命名,造成的檔案下載也就在指定範圍內,即使全部下載,由於同步程式採用單線下載,只開通一個tcp串連,對一台web伺服器來說並不會造成多少影響, 一般來說網站穩定運行後很少會去改目錄名稱,除非程式被重新開發或部屬,在這樣的情況下只要重新初始化下資料庫裡記錄的檔案狀態即可繼續運行.
以上方式的好處時,簡單化了同步操作,並且使2次同步操作之間的影響降低