一、問題提出
門戶網(wǎng)站是向外展示企業(yè)文化的窗口，在業(yè)界得到了廣泛的應(yīng)用。我們有三臺服務(wù)器一起承擔(dān)著門戶網(wǎng)站的服務(wù)工作，兩臺是門戶基礎(chǔ)平臺WSS，一臺是SQL SERVER數(shù)據(jù)庫服務(wù)器，門戶所有的文檔存儲在數(shù)據(jù)庫服務(wù)器中的DB1和DB2兩個數(shù)據(jù)庫中。一直以來，都是對整個門戶的SQL Server數(shù)據(jù)庫進(jìn)行備份，包括所有的子站點。這種辦法的局限就是，如果某一個子站點需要恢復(fù)就只能恢復(fù)所有的站點，在時間差內(nèi)其他子站點所做的工作就會被覆蓋。曾經(jīng)某企業(yè)下屬的A單位就出現(xiàn)過這樣的問題，當(dāng)時因為沒有合適的解決辦法，為了避免覆蓋掉其他單位所做的工作，只好重做了門戶中丟掉的部分。那么如何能實現(xiàn)門戶子站點的單獨備份、單獨恢復(fù)呢？本文將結(jié)合工作實踐就門戶網(wǎng)站子站點單獨備份、單獨恢復(fù)問題提出詳細(xì)的解決思路和處理辦法。
二、門戶子站點單獨備份和恢復(fù)的思路
嚴(yán)格地講，門戶子網(wǎng)站的備份由門戶基礎(chǔ)平臺WSS和內(nèi)容管理服務(wù)CMS兩部分構(gòu)成，它們都存儲在SQL Server數(shù)據(jù)庫服務(wù)器上，其中WSS的內(nèi)容存儲在庫DB1中，CMS中的內(nèi)容存儲在庫DB2中，如圖1。庫DB1主要存儲門戶網(wǎng)站左右兩邊的部分，包括門戶網(wǎng)站所有的子站點、文檔和列表，庫DB2主要存儲門戶網(wǎng)站中間內(nèi)容部分，包括通知公告、重要信息、企業(yè)動態(tài)、綜合信息。子站點也是上述模式。
我們原有的方案是對整個SQL Server數(shù)據(jù)庫進(jìn)行備份操作，包括庫DB1和庫DB2。這樣雖然對全部門戶及子站點的備份和恢復(fù)有效，但如果需要哪一個子站點單獨恢復(fù)，就必須恢復(fù)所有站點，不可避免地要覆蓋掉時間差內(nèi)其他子站點所做的工作。
圖1 門戶存儲架構(gòu)
如果SQL Server數(shù)據(jù)庫中所有WSS和CMS的內(nèi)容有直接的歸屬，即屬于哪個網(wǎng)站或子站點，就可以通過SQL腳本逐一進(jìn)行備份，然而事實上是行不通的，因為DB1和DB2每個庫中至少包含幾十個表，如果按表進(jìn)行操作，腳本復(fù)雜、不宜于維護(hù)，而且每個表中的記錄都是以ID來標(biāo)識的，根本無法直接找到歸屬，這種子站點備份的思路是不可行的。
那么，如何找到子站點備份的最佳方案呢？經(jīng)過反復(fù)實踐，我們摸索出一套依托門戶本身的工具實現(xiàn)門戶子站點的備份和恢復(fù)的思想。
三、門戶子站點單獨備份和恢復(fù)的解決辦法
3.1 子站點門戶基礎(chǔ)平臺WSS的備份和恢復(fù)。利用門戶本身提供的實用程序Smigrate能夠很好地實現(xiàn)子站點WSS部分的備份和恢復(fù)。在一臺門戶基礎(chǔ)平臺WSS上
3.2 子站點內(nèi)容管理服務(wù)CMS的備份和恢復(fù)。同樣，SQL Server數(shù)據(jù)庫中庫DB2中也無法直接找到歸屬子站點，不能按表進(jìn)行單獨備份，雖然在數(shù)據(jù)庫中備份DB2庫對頂級站點和所有子站點的備份和恢復(fù)是有效的。為了實現(xiàn)子站點單獨備份，經(jīng)實踐，子站點CMS部分的備份和恢復(fù)也必須借助和依托門戶本身，通過CMS管理服務(wù)中的站點管理Site Manager中的頻道來進(jìn)行備份和恢復(fù)。在Site Manager中的Channels打開CMSRoot下所需要備份的子站點，通過右鍵選擇菜單中的Export to Package，選擇導(dǎo)出組權(quán)限和用戶，即可將子站點的CMS部分從SQL Server數(shù)據(jù)庫中庫DB2中備份出來，最終生成一個包含組權(quán)限和用戶的SDO文件，如圖2。
圖2 備份CMS
恢復(fù)過程，同樣利用Site Manager管理工具，應(yīng)用圖3恢復(fù)CMS組權(quán)限和用戶Package中的Import功能，選擇導(dǎo)入組權(quán)限和用戶、文件路徑，就可以實現(xiàn)子站點CMS所有內(nèi)容的恢復(fù)，如圖3-圖4。
圖3 恢復(fù)CMS組權(quán)限和用戶
圖4 配置Container規(guī)則
由于CMS組件不支持批處理，因此子站點CMS部分的備份無法進(jìn)行批處理，只能按子站點每天進(jìn)行手動備份。
3.3 子站點備份和恢復(fù)的執(zhí)行效率。子站點WSS的備份執(zhí)行效率較高，24個子站點，批處理文件backup.bat執(zhí)行完需要大概30分鐘時間。子站點WSS的恢復(fù)的執(zhí)行效率非常高，某個子站點需要恢復(fù)，應(yīng)用上文提到的指令，如果站點的內(nèi)容相對少一些，只需要10秒鐘。子站點CMS的備份和恢復(fù)，要手動操作，每個子站點需要1分鐘左右的時間，執(zhí)行效率也比較高。
四、結(jié)論及認(rèn)識
通過探索與實踐，依托門戶本身的管理工具實現(xiàn)門戶子站點的單獨備份和單獨恢復(fù)是可行有效的，解決了門戶子站點單獨備份和恢復(fù)的需求，在一定程度上提高了門戶子站點的安全性，為門戶網(wǎng)站的安全穩(wěn)定運行提供了保證。
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://m.hanmeixuan.com/
本文標(biāo)題：門戶子站點備份與恢復(fù)
本文網(wǎng)址：http://m.hanmeixuan.com/html/consultation/10839312863.html
相關(guān)文章
