一、問題提出

    門戶網(wǎng)站是向外展示企業(yè)文化的窗口，在業(yè)界得到了廣泛的應(yīng)用。我們有三臺(tái)服務(wù)器一起承擔(dān)著門戶網(wǎng)站的服務(wù)工作，兩臺(tái)是門戶基礎(chǔ)平臺(tái)WSS，一臺(tái)是SQL SERVER數(shù)據(jù)庫服務(wù)器，門戶所有的文檔存儲(chǔ)在數(shù)據(jù)庫服務(wù)器中的DB1和DB2兩個(gè)數(shù)據(jù)庫中。一直以來，都是對(duì)整個(gè)門戶的SQL Server數(shù)據(jù)庫進(jìn)行備份，包括所有的子站點(diǎn)。這種辦法的局限就是，如果某一個(gè)子站點(diǎn)需要恢復(fù)就只能恢復(fù)所有的站點(diǎn)，在時(shí)間差內(nèi)其他子站點(diǎn)所做的工作就會(huì)被覆蓋。曾經(jīng)某企業(yè)下屬的A單位就出現(xiàn)過這樣的問題，當(dāng)時(shí)因?yàn)闆]有合適的解決辦法，為了避免覆蓋掉其他單位所做的工作，只好重做了門戶中丟掉的部分。那么如何能實(shí)現(xiàn)門戶子站點(diǎn)的單獨(dú)備份、單獨(dú)恢復(fù)呢？本文將結(jié)合工作實(shí)踐就門戶網(wǎng)站子站點(diǎn)單獨(dú)備份、單獨(dú)恢復(fù)問題提出詳細(xì)的解決思路和處理辦法。

二、門戶子站點(diǎn)單獨(dú)備份和恢復(fù)的思路

    嚴(yán)格地講，門戶子網(wǎng)站的備份由門戶基礎(chǔ)平臺(tái)WSS和內(nèi)容管理服務(wù)CMS兩部分構(gòu)成，它們都存儲(chǔ)在SQL Server數(shù)據(jù)庫服務(wù)器上，其中WSS的內(nèi)容存儲(chǔ)在庫DB1中，CMS中的內(nèi)容存儲(chǔ)在庫DB2中，如圖1。庫DB1主要存儲(chǔ)門戶網(wǎng)站左右兩邊的部分，包括門戶網(wǎng)站所有的子站點(diǎn)、文檔和列表，庫DB2主要存儲(chǔ)門戶網(wǎng)站中間內(nèi)容部分，包括通知公告、重要信息、企業(yè)動(dòng)態(tài)、綜合信息。子站點(diǎn)也是上述模式。

    我們?cè)�有的方案是�?duì)整個(gè)SQL Server數(shù)據(jù)庫進(jìn)行備份操作，包括庫DB1和庫DB2。這樣雖然對(duì)全部門戶及子站點(diǎn)的備份和恢復(fù)有效，但如果需要哪一個(gè)子站點(diǎn)單獨(dú)恢復(fù)，就必須恢復(fù)所有站點(diǎn)，不可避免地要覆蓋掉時(shí)間差內(nèi)其他子站點(diǎn)所做的工作。

圖1 門戶存儲(chǔ)架構(gòu)

    如果SQL Server數(shù)據(jù)庫中所有WSS和CMS的內(nèi)容有直接的歸屬，即屬于哪個(gè)網(wǎng)站或子站點(diǎn)，就可以通過SQL腳本逐一進(jìn)行備份，然而事實(shí)上是行不通的，因?yàn)镈B1和DB2每個(gè)庫中至少包含幾十個(gè)表，如果按表進(jìn)行操作，腳本復(fù)雜、不宜于維護(hù)，而且每個(gè)表中的記錄都是以ID來標(biāo)識(shí)的，根本無法直接找到歸屬，這種子站點(diǎn)備份的思路是不可行的。

    那么，如何找到子站點(diǎn)備份的最佳方案呢？經(jīng)過反復(fù)實(shí)踐，我們摸索出一套依托門戶本身的工具實(shí)現(xiàn)門戶子站點(diǎn)的備份和恢復(fù)的思想。

三、門戶子站點(diǎn)單獨(dú)備份和恢復(fù)的解決辦法

    3.1 子站點(diǎn)門戶基礎(chǔ)平臺(tái)WSS的備份和恢復(fù)。利用門戶本身提供的實(shí)用程序Smigrate能夠很好地實(shí)現(xiàn)子站點(diǎn)WSS部分的備份和恢復(fù)。在一臺(tái)門戶基礎(chǔ)平臺(tái)WSS上

    3.2 子站點(diǎn)內(nèi)容管理服務(wù)CMS的備份和恢復(fù)。同樣，SQL Server數(shù)據(jù)庫中庫DB2中也無法直接找到歸屬子站點(diǎn)，不能按表進(jìn)行單獨(dú)備份，雖然在數(shù)據(jù)庫中備份DB2庫對(duì)頂級(jí)站點(diǎn)和所有子站點(diǎn)的備份和恢復(fù)是有效的。為了實(shí)現(xiàn)子站點(diǎn)單獨(dú)備份，經(jīng)實(shí)踐，子站點(diǎn)CMS部分的備份和恢復(fù)也必須借助和依托門戶本身，通過CMS管理服務(wù)中的站點(diǎn)管理Site Manager中的頻道來進(jìn)行備份和恢復(fù)。在Site Manager中的Channels打開CMSRoot下所需要備份的子站點(diǎn)，通過右鍵選擇菜單中的Export to Package，選擇導(dǎo)出組權(quán)限和用戶，即可將子站點(diǎn)的CMS部分從SQL Server數(shù)據(jù)庫中庫DB2中備份出來，最終生成一個(gè)包含組權(quán)限和用戶的SDO文件，如圖2。

圖2 備份CMS

    恢復(fù)過程，同樣利用Site Manager管理工具，應(yīng)用圖3恢復(fù)CMS組權(quán)限和用戶Package中的Import功能，選擇導(dǎo)入組權(quán)限和用戶、文件路徑，就可以實(shí)現(xiàn)子站點(diǎn)CMS所有內(nèi)容的恢復(fù)，如圖3-圖4。

圖3 恢復(fù)CMS組權(quán)限和用戶

圖4 配置Container規(guī)則

    由于CMS組件不支持批處理，因此子站點(diǎn)CMS部分的備份無法進(jìn)行批處理，只能按子站點(diǎn)每天進(jìn)行手動(dòng)備份。

    3.3 子站點(diǎn)備份和恢復(fù)的執(zhí)行效率。子站點(diǎn)WSS的備份執(zhí)行效率較高，24個(gè)子站點(diǎn)，批處理文件backup.bat執(zhí)行完需要大概30分鐘時(shí)間。子站點(diǎn)WSS的恢復(fù)的執(zhí)行效率非常高，某個(gè)子站點(diǎn)需要恢復(fù)，應(yīng)用上文提到的指令，如果站點(diǎn)的內(nèi)容相對(duì)少一些，只需要10秒鐘。子站點(diǎn)CMS的備份和恢復(fù)，要手動(dòng)操作，每個(gè)子站點(diǎn)需要1分鐘左右的時(shí)間，執(zhí)行效率也比較高。

四、結(jié)論及認(rèn)識(shí)

    通過探索與實(shí)踐，依托門戶本身的管理工具實(shí)現(xiàn)門戶子站點(diǎn)的單獨(dú)備份和單獨(dú)恢復(fù)是可行有效的，解決了門戶子站點(diǎn)單獨(dú)備份和恢復(fù)的需求，在一定程度上提高了門戶子站點(diǎn)的安全性，為門戶網(wǎng)站的安全穩(wěn)定運(yùn)行提供了保證。

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的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)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：門戶子站點(diǎn)備份與恢復(fù)

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839312863.html