- WSS使用的資料庫
由於還原的過程中，牽涉到設定新的資料庫，或指定現有的資料庫，
因此必須先了解一下到底WSS用到了那些資料庫：
- SharePoint_Admin_Content_xxx (xxx是亂數編碼的結果)：
這個DB儲存WSS Admin網站的相關內容，包含目前的Server Farm下轄多少Server、網站等資訊。 - SharePoint_Config：儲存WSS Server Farm中每個網佔有那些子網站、頁面、layout等等的資訊。
- WSS_Content_xxx：儲存每個網站中的文件資料。這部份通常最佔空間。
- WSS_Search_ServerName：每個網站啟動全文檢索服務的時候所使用的資料庫。
- SharePoint_Admin_Content_xxx (xxx是亂數編碼的結果)：
- 還原
- 想像中的作法：
一開始我嘗試還原的時候，知道前輩有每日排程跑備份，只知道DB Server沒掛，資料庫都好好的，在「SharePoint 所有的資料其實都塞在DB裡」的印象之下，藉由無數次的Google，試圖先灌好基本的WSS Service以及Default Site，再透過「指定DB」的方式來做還原，事實證明這真的是難到爆了！！整個就是失敗的！
首先在安裝WSS時，選擇的是「基本」，此時可以很順利的把 WSS Service還有Default Site裝起來，很高興的進入管理介面之後，發現可以順利把舊的「ContentDB」刪掉，指定到DB Server上活的好好的DB，這時候問題來了，要怎麼指定ConfigDB？
雖然在安裝完畢，執行「產品設定精靈」的時候可以設定要使用哪一個ConfigDB，但是會遇上DB被舊的帳號密碼鎖住的狀況（cache），因此還要以stsadm tool執行「Updateaccountpassword」、「Updatefarmcredentials」等操作，但是搞了半天最後還是失敗了。
因此結論就是，一定要透過 WSS 內建的 stsadm tool 來執行備份以及還原，其他方法都很複雜而且失敗率太高。
- 實際試驗成功的作法：
最後在努力的翻箱倒櫃以後，發現其實前輩有設定在每日排程中利用WSS內建的stsadm tool進行備份，而備份檔也存在另一台server上！有了由stsadm製作的備份檔以後，就可以比較順利的進行還原啦！
- 如何安裝standalone的WSS
- 用來還原的實體機器或VM必須要加入AD Domain中。
- 第一部分的安裝畫面參考Angi’s Tech Trace(Part I)，在Step2-3的部分，選擇「基本」即可，預設會裝好完整的Admin IIS Site和Default WSS Site。
- 第二部分 「建立網站集合」的設定繼續參考Angi’s Tech Trace(Part II)，從Step4-5開始來建立新的Web應用程式，特別注意在Step4-7的說明中提到的「主機標頭」，要設定為一個有效的DNS。請注意，在DNS設定生效之前（舊的cache update之後），即使已完成Site Collection Restore，但從intranet上還是連不到此網站。
- 完成下述的Site Collection Restore之後，從Admin Site中將原本預設安裝好的Web應用程式刪除，網址如右：http://VM_MachineName/。
- Site Collection Restore(Ref)
- 範例：stsadm -o restore -url http://myServerName.com.tw -filename C:\Site.bak –overwrite
- 這是最後測試後可以正確work的方法，但缺點是會把所有的 DB （共四個）都還原到本機的Windows Internal Database（也就是SQL Server 2005 Embedded Edition），基本上千萬不要用Embedded/Express Edition（除非是在家裡架好玩的），因為會有實體DB Size的限制，萬一爾後真的超出限制的時候應該會寫不進去，到時候要調整一定會極度的痛苦！
- 在WSS所使用的DB中，主要是WSS_Content所佔的空間是最大的，所有的文件資料都塞在裡面，因此在完成restore之後，可以利用「SharePoint 3.0 管理中心」進入WSS管理介面，在「應用程式管理」-->「Web應用程式清單」中選擇還原好的網站後（會跳回應用程式管理畫面），再進入「內容資料庫」，將現有的ContentDB刪掉，而後新增一個資料庫，指到DB Server上完好如初的ContentDB就可以了。
- Catastrophic Restore(Ref)
- 範例：stsadm –o restore –directory \\myBackupServer\temp\Site.bak -percentage 1 -suppressprompt -username theName –password theWord -preservechangelog
- 按理說，我遇到的狀況是應該採用災難復原的方式，但是在嘗試過後，用上述Site Collection Restore的方式可以讓stsadm tool正確辨認備份檔，但是stsadm工具對UNC path一直有意見，不管怎麼試就是會出現「找不到備份檔」的錯誤訊息，因此最後沒有採用這個方法來還原。
- 在同一台機器上，若曾安裝過WSS，之後又進行移除，再來要重新安裝WSS的時候，會遇到這篇TechNet KB中提到的「Install and configure WSS 3.0 with Windows Internal Database」問題，找了一下資料，在這篇TechNet文章中有提到如何移除Windows Internal Database。
以下是備份的作法：
- 備份
- 作法：利用WSS內建的stsadm tool每日執行排程來進行備份。備份的時候採用「overwrite」參數來覆蓋前一日的檔案。由於根據最後測試的結果也無法採用Catastrophic Restore，因此後來備份時也僅採用Site Collection Backup。
這部份作法的正確性（以及設定每日排程的作法)尚待確認，由於最近幾週可能都沒時間處理這個問題，因此要晚一點再另寫一篇文章補完了 ... - 範例 Command (Ref)：stsadm –o backup –url http://myServerName.com.tw –filename Site.bak -overwrite
- 作法：利用WSS內建的stsadm tool每日執行排程來進行備份。備份的時候採用「overwrite」參數來覆蓋前一日的檔案。由於根據最後測試的結果也無法採用Catastrophic Restore，因此後來備份時也僅採用Site Collection Backup。
問題是官方還是缺少一個比較完整說明如何執行還原的標準程序，
大家都是靠網路上無數的苦聖先賢的辛苦和分享，
加上自己的嘗試，才慢慢進入狀況，可見清楚的說明文件有多麼重要。
最後再次強調，you MUST use the stsadm tool to run the backup procedure,
and you better keep the backup file safe, or you will be TOTALLY SCREWED if WSS server went down!
參考資料：
- Stsadm command line tool reference
- Psconfig command line tool reference
- Install and Configure Windows SharePoint Service 3.0
1 則留言:
我好像用過wss3，除了介面跟微軟產品完美結合外，其他真是沒人性到暴，帳號還要綁windows帳號
張貼留言