一、背景
一旦系統正常運行以後，系統維護最主要工作就是數據安全與可恢復性。本方案（以下提到的數據庫均指微軟的SQL Server7.0或以上數據庫）主要探討數據庫備份與恢復。
一般的數據備份解決方案無非是以下三種：（1）、磁帶備份；（2）、雙機熱備份；（3）、手工備份。作為一般的中小型政府部門和企業采用磁帶備份，代價太高，性能價格比不高；普遍采用的可能是雙機熱備份方案，但是用戶可能依然不放心，還需要手工備份，把數據存放到一個與外界斷絕聯系的可控環境中，這種情況是普通存在的。所以作為雙機熱備份方案的輔助方案或者在條件限制的情況下，作為雙機熱備份的替代方案，有必要整理出一套手工備份方案。
二、設計思路
Sql Server數據庫本身提供非常方便強大的備份功能（DTS），可以以向導的方式引導用戶備份到本地局域網的機器或者遠程的機器上，但是現在出現一個問題：就是一旦數據庫大了的話，本地局域網備份速度可以接受，可是遠程備份，尤其是撥號上網，速度就可能慢，一旦時間過長，網絡可能斷掉，又得重新備份，能否提出一種方案充分利用SQL Server數據庫本身已有的備份功能（DTS），同時又解決備份速度慢的問題，考慮到數據庫備份文件的可壓縮比率非常高，可以直接對備份文件進行壓縮操作，是否更有效率？
下面是設計思路，最後定型取決於兩種方式效率的高低。
第一步：利用SQL Server本身帶有的備份功能（DTS）把數據庫全部或者差額定時備份到某個目錄，一旦備份成功，這時候在指定的備份目錄下有.bak文件存在；
第二步：利用公司自開發的解壓縮組件RichZip把.bak文件壓縮成另一個文件.zip文件，RichZip的壓縮比等同於WinZip；
第三步：通過Http協議下載.zip文件到本地，按照不同的項目和日期保存；
第四步：如果需要恢復，把.zip文件解壓縮成.bak文件，然後再用SQL Server的工具把備份文件恢復；
需要實驗解決的幾個問題：
1、在同一環境下，直接使用SQL Server的備份工具與這種方案所需要的時間哪一個更長？是否在不同量級裡面有不同的結果？
2、是自己利用組件開發一個基於http協議的下載程序，還是直接采用其它的共享下載工具是否更有效率？比如說NetAnts（網絡螞蟻）或者其它下載工具。
說明：
1、該方案只在微軟平台上做過實際操作：操作系統Window NT4.0或者以上（推薦使用Win2000），數據庫SQL Server6.5或者以上（推薦使用Sql7.0）。
三、實際情況
3.1 實驗結果
3.1.1 實驗一結果：無論在哪種連接環境下，局域網還是撥號上網，直接使用SQL Server的備份工具與本方案的效率差距都比較大，只是由於數據庫小時，直接使用SQL Server的備份工具比本方案方便一些。
以下是一些簡單的、不完整的實際操作數據，僅供參考。
操作環境：聯想56K調制解調器，上網速度52K，通過SysGate上網，平均3K左右。
庫名 備份文件大小 壓縮文件大小 下載時間
Sql備份工具 本方案
SoftEnterPrise 27970Kb 2109Kb(13.26倍) 沒有耐心等待，強行中斷 12分鐘
SoFTProduct 10265Kb 739Kb（13.89倍） 18分鐘 3分鐘
SoFTProductHz 11948Kb 930Kb(12.85倍) 25分鐘 5分鐘
實際操作過程中是使用網絡螞蟻下載的，三個庫的備份文件一共50MB，壓縮後一共不到4MB；使用Sql備份工具，至少需要一個小時左右，而使用要方案最多不超過20分鐘，這中間的效率是不可比擬的，還不包括在使用Sql備份工具時如果斷網造成的延時。
3.1.2 實驗二結果：建議使用專門的下載工具，如網絡螞蟻或者其它下載工具，是基於如下考慮：A、專門的下載工具功能強大，提供斷點續傳、多線程、定時下載等許多功能；B、許多用戶都會使用，而且非常熟練，不需要再培訓；C、比較穩定，如果自己要開發下載程序的話，一個是功能不強大，另外需要一段相當長的測試時間，需要投入時間與精力，不合算。如果是因為集成或者產品化的原因，可以考慮做一個相對簡單的下載程序，與其它應用結合，或者開發一個管理備份文件的程序，管理起來比較方便。
3.2 服務器配置及源碼
3.2.1 服務器端配置
3.2.1.1 SQL Server的配置：
-先建立Device(設備)；
-然後備份具體的數據庫到Device(設備)中，可以選擇備份的時間及備份的方式；
重復上述操作，直到做好所有需要備份的數據庫配置。
注意事項：
1、 備份文件存在的目錄不要讓用戶能通過Http協議訪問到；
2、 根據實際需要選擇全額備份還是差額備份以及定時操作；
3、 如果系統備份以後，
