本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

嚴重損壞復原最佳作法與 SharePoint 2013 搜尋的策略

SharePoint 2013
 

適用版本:Search Server 2013, SharePoint 2013

上次修改主題的時間:2016-10-04

了解如何實作 SharePoint Server 2013 伺服器陣列中搜尋的最佳作法是嚴重損壞修復。

本文提供您可以使用擬定SharePoint Server 2013中的搜尋支援嚴重損壞修復 (DR) 策略的最佳作法指導。許多用於較早版本的SharePoint Server嚴重損壞修復的方法不提供SharePoint Server 2013復原的相同層級。我們檢查這些方法,並提供的優點與您需要了解的限制與取代選項。

本文內容:

本文等藍圖提供實作災害復原策略的文件與可讓您設定SharePoint 2013 Search Service 應用程式 (SSA) 的嚴重損壞修復的特定命令的文件的間距。我們是幾個一般嚴重損壞修復案例的說明及檢查的好處及限制每一種方法。它是不實際考量這些案例是完美適合您的組織,但您可以使用其作為指南 DR 策略符合貴組織的特定需求。

嚴重損壞修復SharePoint Server 2013和其支援的技術是一個複雜的主題,並有許多專用解釋以協助確保您的業務目標符合啟動災害復原計劃事件時所需的規劃資訊來源。

最佳作法是建議您在您開始由清楚識別和量化復原時間目標 (Rto) 及復原點目標 (RPOs) 來組織。Rto 愈短,才可從嚴重損壞、 及 RPO,您可以從相同損毀、 遺失的時間單位資料復原時間是嚴重損壞復原規劃中的關鍵評量值。下列兩種商務導向評量設定下列階段:

  • 備份及還原程序、 媒體及存放區

  • 您復原至位置

  • 大小與複雜性復原解決方案

您不能開發有效復原策略及評估技術解決方案而這些基準。

重要事項 重要事項:
整個計畫重心在營運持續力和 IT 復原需求,而不是建立 DR 策略所需的步驟。

雖然本文範圍是SharePoint Server 2013搜尋的嚴重損壞修復,我們建議您閱讀選擇 SharePoint 2013 的災害復原策略開發嚴重損壞修復策略的準備。

再查看開發嚴重損壞修復策略的不同方式下, 表提供在SharePoint 2013搜尋及如何他們參與使用者搜尋體驗的元件的描述。搜尋應用程式元件和資料庫,如下表所述提供內容的嚴重損壞修復策略。

搜尋服務元件

元件或資料庫 描述

索引元件

擔任邏輯的表示法的索引複本。

索引元件包括:

  • 索引分割區

    您可以分成每個保留不同的組件的索引的分散部分的索引。

    搜尋的索引為所有索引分割區的彙總。索引分割區會儲存在一組的磁碟上的檔案。

  • 索引複本

    每個索引分割區保留一或多個索引複本包含相同的資訊。

查詢處理元件

分析及處理搜尋查詢和結果。

管理元件

執行所需的搜尋系統處理序。可以有多個搜尋管理元件每個 Search service 應用程式,但只能有一個作用中一次。

編目元件

根據項目中的編目資料庫所指定的內容進行編目。

內容處理元件

執行編目的項目,例如文件剖析與屬性對應的各種程序。

分析處理元件

執行搜尋分析與流量分析。

搜尋管理資料庫

儲存搜尋組態資料。有一個搜尋管理資料庫每個 search service 應用程式。

編目資料庫

編目記錄會儲存及管理編目作業。

連結資料庫

會儲存某些內容處理元件所擷取的資訊。它也會儲存點選連結資訊。

分析報表資料庫

儲存流量分析的結果。

有多個方式可以分散搜尋元件以提供高可用性及可高度擴充搜尋拓撲],如下圖所示。在此圖表中,搜尋元件部署在不同的應用程式伺服器,以提供備援。此外,提供其他層級的容錯能力及延展性的不同的虛擬化主機伺服器上部署應用程式伺服器。

具有多餘元件的搜尋拓撲

如需散佈伺服器陣列伺服器上的搜尋元件的詳細資訊,請參閱在 SharePoint Server 2013 中規劃企業搜尋架構及搜尋技術圖表在搜尋

若要欣賞開發搜尋嚴重損壞修復策略的複雜性,您必須瞭解如何將文件參照的 Search Service 應用程式索引和資料庫中。它是複寫的目前會無法使用任何格式或記錄傳送至複製SharePoint 2013伺服器陣列之間的搜尋索引的技術運用這個參照系統。

因為 SharePoint 搜尋服務應用程式索引的結構過於複雜,所以深入的描述會超出本文範圍。簡單合約索引所組成的一系列可更新群組的資料的許多小型部分。這些可更新的群組可以視為的分割區透過 table 中的欄。根據預設,有六個這些群組中的搜尋索引。這些群組如下所示:

  • 主要︰包含大量欄位的全文檢索儲存在此處。

  • Acl:涉及安全性修剪和 fast 安全性編目。

  • 路徑及標題:包含的路徑及標題。

  • 建議︰請注意此資料每日更新。

  • 社交同事 (人員)︰涉及不同更新群組人員欄位。

  • 社交標記:包含社交標記。

每個更新群組設想為該群組結構類似SQL Server資料庫中欄位的 index 結構。更新群組的每個包含索引結構的區塊的檔案分割儲存層級。每個這些檔案會包含不同的整體索引的一部分。內容會分散這些分割區識別碼使用的每個唯一的文件。此識別碼為DocID、 也是效能計數器。

建立新的 search service 應用程式之後,計數器從零開始。DocID就會遞增其中每個編目期間發現的新項目時] 計數器繼續發現新項目時增加一段時間的時間。效能計數器值永遠不會遞減。即使在文件,但刪除相對應的效能計數器值永遠不會重複使用。新增及移除項目或文件庫與清單一段時間也表示DocID不連續內任何網站或文件庫。因此,即無法預測DocID搜尋主體中的任何文件。

這會呈現任何搜尋複寫策略的挑戰為任何兩個伺服器陣列中有不是保證或甚至是DocID值會比對伺服器陣列中任何一份文件的機率。由於DocID值將不相符,就不能索引資料或分析DocID值所連結的資料進行複寫。搜尋結果不是有效,因為相同文件會對每個伺服器陣列的不同DocID

當我們檢查如何建立 Search Service 應用程式的完整不失真的 DR 策略時,請務必下列兩件事發生:

  • 元件和資料庫所儲存的資料所需的設定和查詢的識別並正確地還原至目標 DR 在伺服器陣列使用適當的方法。

  • 適當地與右元件數目以支援搜尋服務的大小調整目標 DR 伺服器陣列。特定的附註的以下是的前 10 2013年累計更新 (CU) SharePoint Server,它已僅支援每個伺服器的主機一個索引分割區複本。如果年 10 月 2013 CU 版本或更新版本已部署,最多個複本可以主控於單一伺服器上,並適當地調整式的平台的四個分割區都必須 DR 伺服器陣列中。請參閱SharePoint 更新可用SharePoint 2013版本的清單。

兩個這些活動會參照中的下列各節和實作各節中所包含的技術詳細資料。

在舊版 SharePoint 中,有多種方式協助確保您有容錯移轉填入與最新的索引與接近 100%搜尋時效性的 Search Service 應用程式。下列範例會顯示已通常用於嚴重損壞修復的方式。

  • 編目唯讀內容資料庫已] 選項, SQL Server記錄傳送方法用於維護是實際執行內容資料庫複本附加到 DR 伺服器陣列以唯讀模式。這表示 SSA DR 陣列上的可設定為唯讀的 web 應用程式透過編目資料庫 DR 陣列上。任何設定變更都 SSA 層級上以協助確保使用者的完整不失真的體驗容錯移轉的情況下兩個伺服器陣列中實作。

  • 雙編目] 選項,也會在 [伺服器陣列復原到進行編目實際執行伺服器陣列與因此相同的內容已探索到及編製索引。設定變更 managed 屬性或編目檔案類型,已安裝 Ifilter 和等鎖實際執行和 DR 伺服器陣列中實作,但這輕鬆已使用適當的變更控制原則來管理。

嚴重損壞修復策略時的其他選項不會提供相同的層級的搜尋索引新鮮度,但如果索引新鮮度或復原時間已不具關鍵性,則他們是有效的選項。一般而言,這些選項的設定及實作更複雜。下列範例為一般的方法。

  • SSA 搜尋管理資料庫無法備份單獨。SSA 搜尋管理資料庫已備份單獨使用慣用SQL Server備份方法及 DR 伺服器陣列上用來建立使用Windows PowerShellSSA。這會還原的搜尋設定,但不是的索引。填入搜尋索引及完成復原需要完整編目。

  • 完整的 SSA 備份與還原。完整的 SSA 備份與還原為執行使用Windows PowerShell或使用SharePoint 管理中心網站介面。這備份的 SSA 資料庫與搜尋的索引,讓它們還原填入該伺服器陣列的 SSA DR 伺服器陣列上。

在SharePoint Server 2013、 搜尋架構中的重大變更及如何儲存組態元素表示我們需要以不同方式考慮搜尋嚴重損壞修復。下列各節說明這些變更及其如何影響,可用的嚴重損壞復原選項。

SharePoint Server 2013中的 [網站管理] 頁面會提供新支援搜尋體驗的彈性設定的選項。網站和網站集合的新組態選項表示網站管理員可以讓搜尋先前無法只是伺服器陣列或搜尋系統管理員所做的組態變更。下一個螢幕擷取畫面顯示您可以在此設定搜尋選項的兩個位置 —網站集合管理搜尋之下。

在 [網站設定] 頁面上設定搜尋

您可以進行組態變更搜尋項目,例如查詢規則] 或 [結果來源] 從 [網站集合管理] 或 [搜尋] 下的清單和結果會是相同。不過,將變更儲存的位置直接影響嚴重損壞修復。所有網站集合或 web 應用程式、 變更所做的變更只會儲存在 Search Service 應用程式 (SSA) 管理資料庫。除非此資料庫會從備份還原嚴重損壞復原伺服器陣列,設定的變更將不會是復原之環境中可用。

中SharePoint 2013搜尋另一個新的功能是立即重新編製索引] 功能,可讓網站集合、 Web 和清單層級的管理員以要求容器的下一個編目期間重新索引。這項功能完全管理內容資料庫中並要求此 DR 伺服器陣列內的管理員因此觸發下次編目執行 DR 伺服器陣列上的實際執行伺服器陣列中的相同事件。

SharePoint Server 2013 Enterprise搜尋中搜尋和流量分析處理的處理方式呼叫分析處理器元件。這個元件有下列職責:

  • 處理搜尋分析資訊的處理

  • 流量分析處理

  • 提供內容的處理器用來支援搜尋建議功能的關聯式資訊

  • 提供內容的處理器使用以改善相關性與排名計算的文件常用性 (例如頁面造訪及點選) 的統計資訊

閱讀更多在個別的分析處理序請參閱SharePoint Server 2013 的分析處理概觀如需詳細資訊。

已處理的資訊會儲存在搜尋索引和報告與連結 」 資料庫所。因此,雖能夠同時務必使用這項處理的資訊已複寫至 DR 在伺服器陣列中的同步處理狀態的唯一方法是完整的 Search Service 應用程式備份與還原。

服務應用程式備份及還原增強功能

滿足所有 DR 需求擷取設定與索引資料的方法是服務應用程式備份與還原。這些作業是經過精心大幅減少 RTO 及 RPO 相較於舊版 SharePoint。備份與還原程序中使用的支援變更執行緒數目加上的改良功能支援完整及差異備份與還原作業所這個區域中的所有按鍵提升。

當採用完整的搜尋服務應用程式備份和還原成 DR 策略的方法,整體 RPO 是由兩件事管理。自上次完整的服務時間是在應用程式備份 RPO 和是為了真的還原服務應用程式所需的時間是 rto 愈短。兩個這些時間都有可能因此發生災害時所宣告的服務還原期望小心管理需要增加工期為 Search service 應用程式增加,已編製索引內容中。我們建議進行經常測試才會還原以確定仍然可以符合任何 SLA 所需的 RTO 及 RPO 對您服務連續性管理練習的一部分。下表摘要說明搜尋服務應用程式的備份和還原選項。

 

選項 限制

編目 DR 陣列中的唯讀資料庫。

  • 沒有網站集合或 web 層級搜尋設定的變更會複寫到 DR 伺服器陣列。

  •  

執行雙編目實際執行伺服器陣列。

  • 沒有網站集合或 web 層級搜尋設定的變更會複寫到 DR 伺服器陣列。

  • 分析導向搜尋索引更新不會複寫到 DR 陣列。

還原 DR 陣列上的搜尋管理資料庫並重新建立該服務。

  • 分析導向搜尋索引更新不會還原至 DR 陣列。這是因為索引將會是空時建立的服務應用程式時,同時將需要完整編目。

進行完整的 SSA 備份與還原]。

  • 在搜尋索引不失真但還原大型服務應用程式沒有限制可能採用多種小時與容錯移轉期間影響 rto 愈短。

沒有只有一個會提供完整不失真的復原,包括所有分析處理搜尋索引及在服務應用程式、 網站集合與 web 層級實際執行伺服器陣列內的所有搜尋設定項目改良功能的支援嚴重損壞修復技巧。這個方法需在後面接著要 DR 伺服器陣列的服務應用程式的完整還原 Search service 應用程式的完整備份。索引和設定將還原至相同點備份的時間所以新編目若備份數天,請是需要將最新的索引。這個方法的特定步驟稍後所述的紙張。

它也支援為 Search service 應用程式管理資料庫進行備份與還原的 DR 網站中。藉由使用Windows PowerShell,管理員可以建立新的 Search service 應用程式所使用之備份。不過,這只還原搜尋服務應用程式與 SharePoint 網站和 web 內任何自訂的搜尋設定的實際設定 — 它不會復原 search 索引。需要完整編目將填入主體進行搜尋。此外,無法復原搜尋索引分析增強因為在實際執行伺服器陣列上用來產生的信號僅駐留。

沒有如果不必 DR 策略中包含搜尋的主要目的是為了確保搜尋索引新鮮度在容錯移轉階段可能會採用的另一種方式。藉由使用兩種方法之一,可以在非常新鮮狀態,但隨著複雜的設定與數個限制維護索引。因為 DR 陣列中的編目程式必須設定為編目實際執行伺服器陣列或內容資料庫已複寫至 DR 陣列支援本機編目可讀取狀態而言複雜度。這個方法會有所限制,因為在生產環境中的 Search service 應用程式的設定不會複寫以任何方法來 DR,而且搜尋索引更新的分析資料處理也會遺失。如果這些限制是可接受的這是非常大的彈性的方式來協助確保高索引新鮮度及 DR 伺服器陣列中的搜尋可用性。

最後一個方法是實際合併到單一策略提供高搜尋索引新鮮度容錯移轉但將在其中也執行完整整合分析資訊並搜尋設定的優先順序 DR 陣列還原先前所述的兩個技術。

在此例中,會採用的完整備份和遠端或本機編目和還原程序可使用如果需要。若要啟動完整還原程序一般原因是如果 DR 網站容錯移轉大於一般服務在暫時中斷與容錯回復至實際執行環境不可能同意的時間期間內。在該情況下,還原程序會叫用來協助確保 DR 網站中所提供完整不失真的搜尋體驗。然後將將移到完整的新鮮度 search 索引起始新編目。

有還原 Search service 應用程式使用要覆寫選項時要考慮的隱含意義。服務應用程式還原,這表示沒有更新期間都會離線或處理的查詢。企業版搜尋是不重要的功能,這是可能不是發生問題。但是如果搜尋查詢功能必須具備還原期間,然後另一個作法可視為。永遠建立新的搜尋服務應用程式還原程序期間及還原為完成時執行以取得最新索引新鮮度的新編目為的替代選項。編目完成之後,切換至新的服務應用程式的服務應用程式關聯並不會中斷工作上執行。無法再刪除舊的服務應用程式。最大的挑戰是其中一個容量,基本上雙索引及資料庫就所需的空間來裝載平行的兩個服務應用程式。搜尋服務的重要性會規定這是否必須配合公司的內容。

所有這些事項視為,它是值得調查 Search service 應用程式的預期的 RPO 和 RTO 需求。目前Office 365 SharePoint search service 應用程式支援 RPO 和 rto 愈短的一週。如果您在考慮這意味著,就表示的設定項目、 分析處理資訊及搜尋時效性所有可能最大值為一週過期還原的時機。再次依據的預期在環境中的變更速率和搜尋安裝程式的重要性,則可能審慎執行每日或甚至是 subdaily 以協助確保可以達到最佳的 RPO 和 RTO 適用於企業的備份。沒有方式您一樣與內容的備份因為搜尋內容是非常液維護多個備份複本的需求和暫時性,所以最一或兩個完整備份會保留。

下列資訊是包含在搜尋備份和還原 TechNet 文章中的關鍵點簡短摘要:

在哪個搜尋服務備份必須採取的頻率會受到許多事項,但主要商務所需的 RPO 將是主要驅動程式。為搜尋索引較大,同時備份及還原服務應用程式所需的時間將會得到較長及更久。只能有一個搜尋備份,即會發生一次並完成備份的時間是即可達到基本 RPO。若要完成 DR 陣列上的還原持續時間因此即可達到、 最小 rto 愈短且如備份的時間,這會擴充一段時間。若備份或還原時間開始 encroach 上的必要的服務等級協定 (Sla) 搜尋 RPO 和 rto 愈短,則商務必須制定一些追蹤更靈活如果中較小一個逼真度方法,如下所述更新版本,或調整 Sla 上以符合可以達成目標的決策。

若要備份 search service 應用程式,您可使用Windows PowerShell或管理中心使用者介面。所需的 PowerShell 指令程式是如下:

Backup-SPFarm -Directory <Backup Folder> - BackupMethod <Full | Differential> -Item <Full Path to Search Service Application>

以下為範例:

Backup-SPFarm -Directory \\server\searchbackup - BackupMethod Full -Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application"

本範例會將完整備份名為 Contoso Search Service 應用程式 Search service 應用程式並將備份檔案儲存在位置 \\server\searchbackup。

注意事項 附註:
BackupMethod參數只會套用至搜尋資料庫。在所有的情況下,搜尋索引完整備份無論選擇這個選項。

您可以檢視上方的 [備份與還原工作狀態] 頁面上的所有備份工作的一般狀態的 [整備] 區段。您可以在頁面的 [備份] 區段中的下半部檢視目前的備份工作的狀態。[狀態] 頁面會自動更新每 30 秒。您可以按一下 [重新整理手動更新狀態的詳細資訊。備份及復原是計時器服務工作。因此,可能需要幾秒開始備份。若收到任何錯誤,可以檢閱 [備份與還原工作狀態] 頁面上的 [失敗訊息] 欄中。您也可找到更多詳細資料中所指定的 UNC 路徑的Spbackup.log檔案儲存備份檔案。

若要還原SharePoint Server 2013 Enterprise Search service 應用程式、 備份必須已成功完成,且如果經常進行備份,然後要還原之特定備份的識別碼需要。在第幾種方法可以輕鬆地取得此識別碼。最簡單是開啟拍攝備份實際執行伺服器陣列上的 [備份與還原歷程記錄] 頁面上,然後輸入備份目錄位置。這會提供備份及還原資訊清單檔案 (psbrtoc.xml) 的所有項目的清單。下列螢幕擷取畫面中,可以輕鬆地呈現 {149fc816-8927-4a32-9437-6e05c2869ab7} 的備份識別碼。

SharePoint 備份與還原歷程記錄頁面

使用 [備份與還原歷程記錄] 頁面上的替代名稱是直接開啟 [製作備份和還原資訊清單和檢查所需的項目。由於此檔案的大小會成長與每個備份與還原執行、 檢查此檔案可能不是最佳方法 — 特別是如果有高頻率的備份與還原作業。

下列範例會顯示典型的項目中spbrtoc.xml,且您可以檢視可以輕易識別的備份識別碼。

<?xml version="1.0" encoding="utf-8"?>
<SPBackupRestoreHistory>
 <SPHistoryObject>
 <SPId>149fc816-8927-4a32-9437-6e05c2869ab7</SPId>
 <SPRequestedBy>CONTOSO\administrator</SPRequestedBy>
 <SPBackupMethod>Full</SPBackupMethod>
 <SPRestoreMethod>None</SPRestoreMethod>
 <SPStartTime>01/11/2014 02:30:27</SPStartTime>
 <SPFinishTime>01/11/2014 02:38:48</SPFinishTime>
 <SPIsBackup>True</SPIsBackup>
 <SPConfigurationOnly>False</SPConfigurationOnly>
 <SPBackupDirectory>\\server\backups\spbr0000\</SPBackupDirectory>
 <SPDirectoryName>spbr0000</SPDirectoryName>
 <SPDirectoryNumber>0</SPDirectoryNumber>
 <SPTopComponent>Farm\Shared Services\Shared Services Applications\Search Service Application Prod</SPTopComponent>
 <SPTopComponentId>013aa694-673d-46d1-9313-fbba6df691e7</SPTopComponentId>
 <SPWarningCount>0</SPWarningCount>
 <SPErrorCount>0</SPErrorCount>
 </SPHistoryObject>
</SPBackupRestoreHistory>

另一種可用的方法是使用Get-SPBackupHistory指令程式,也可以提供資訊與spbrtoc.xml檔案相同。

下一步] 兩個範例說明如何執行還原作業使用Restore-SPFarm指令程式。

Restore-SPFarm -Directory <BackupFolder> -Item "<ServiceApplicationName>" -RestoreMethod Overwrite [-BackupId <GUID>]

Restore-SPFarm -Directory \\server\searchbackup - Item "Farm\Shared Services\Shared Services Applications\Contoso Search Service Application" -RestoreMethod New -BackupID "149fc816-8927-4a32-9437-6e05c2869ab7"

注意事項 附註:
如果不提供任何備份的識別碼,則會使用最近的可用備份從目錄。

您使用RestoreMethod決定如何處理程序將流程後加以執行Restore-SPFarm指令程式。

如果選擇這個選項至新伺服器陣列上提供的位置中備份的每個元件和資料庫提示您執行此指令程式的系統管理員。這可以如果伺服器陣列拓撲和 DR 陣列中的命名慣例不完全符合實際執行,會經常時發生的案例特別有用。如果要建立對應的名稱和伺服器拓撲的伺服器陣列還原 Search 服務應用程式,可以使用 [覆寫] 選項。通常使用此選項只還原至相同的伺服器陣列的備份來源時。

注意事項 附註:
若要使用 [覆寫] 選項,那里具有已至少一個還原使用的選項。如果不是這樣,現有的 Search service 應用程式使用相同的設定和命名必須可用 DR 陣列上。

時還原 search service 應用程式,它會自動暫停期間和之後還原。若要繼續將服務應用程式還原完成之後,使用下列Windows PowerShell命令。

$ssa = Get-SPEnterpriseSearchServiceApplication <SearchServiceApplicationName> $ssa.ForceResume($ssa.IsPaused())

特定給系統管理員也是記事的用來還原 Search service 應用程式具有每個分割區的多個複本的程序。還原程序只會還原為其中一個內每個分割區,複本及背景工作會處理複寫的每個分割區的所有其他複本的分割區資訊。搜尋索引和查詢在線上並功能在此程序,但 Search service 應用程式的管理頁面也可能會顯示複本為等到此作業完成後變慢。

如前所述,與服務應用程式備份與還原所維護完整不失真的 DR 解決方案唯一支援的方法,會變成特別面對以達到低 RPO/RTO 搜尋的項目。如已編製索引的主體變成較大,時間來備份和還原時間可以成為擴充一段時間。這可能會導致較超過所需的 RPO 和 rto 愈短。

可以採用來克服挑戰達到低的 RPO RTO 的一種方式就是採用解決方案的兩個尖端方法。下列清單顯示此解決方案。

  • 使用唯讀內容資料庫或雙重編目的編目實際執行網站來維護 DR 伺服器陣列中的搜尋索引新鮮度的可接受的程度。

  • 讓搜尋服務應用程式備份,以及定期還原至 DR 陣列或有提供這些以防主要網站不是可復原。

若編目唯讀資料庫 DR 在伺服器陣列是好的選擇,則您必須考慮在實際執行伺服器陣列中變更事實將不會複寫到的復原伺服器陣列。我們所述,這包括索引的搜尋服務分析更新及例如結果來源、 查詢規則及結構描述修改的設定項目的變更。如果您採用混合方法時,最好是非常重要了解所有含意並放入進行適當的策略。目前沒有支援的方法規避的分析更新遺失但是可以採取步驟來解決組態變更的更新。您可以嘗試執行類似下列的範例。

確定所有自訂的結果來源、 查詢規則以及重要的搜尋結構描述變更會在 search service 應用程式層級中管理中心而不在網站集合或子網站進行。例如,請考慮特定的查詢規則來管理 [首頁] 頁面上的內容有相依性的公司內部網路入口網站。這些規則會在實際執行伺服器陣列上建立並手動複寫到 DR 在伺服器陣列以協助請確定此組態已就緒。同樣地,自訂對應的編目屬性至 managed 屬性必須實作在兩個伺服器陣列中的服務應用程式層級。

很可能擷取站台層級與 web 層級搜尋設定項目並將其匯出至 XML 檔案中使用 PowerShell。例如下, 一個 PowerShell 範例將組態項目匯出的網站 」 http://intranet.contoso.com"intranetcontosocom.xml 上名為 XML 檔案。這個方法發佈至 SharePoint 社群並搭配其權限。您可以在匯入及匯出的搜尋組態設定 SharePoint 2013 中

Add-PSSnapin Microsoft.SharePoint.PowerShell-ea 0
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://intranet.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
$value = $searchConfigurationPortability.ExportSearchConfiguration($owner)
$context.ExecuteQuery()
[xml]$schema = $value.Value
$schema.OuterXml | Out-File intranetcontosocom.xml -Encoding UTF8

注意事項 附註:
在上述範例中,我們會從 SPSite 匯出組態。您可以使用SearchObjectLevel列舉以取得這些設定: SSASPSiteSubscriptionSPSite、 及SPWeb

下一個範例會示範如何匯入您取得從另一個環境的設定。

[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client") | Out-Null
[reflection.assembly]::LoadWithPartialName("Microsoft.SharePoint.Client.search") | Out-Null
$context = New-Object Microsoft.SharePoint.Client.ClientContext("http://dr.contoso.com")
$searchConfigurationPortability = New-Object Microsoft.SharePoint.Client.Search.Portability.searchconfigurationportability($context)
$owner = New-Object Microsoft.SharePoint.Client.Search.Administration.searchobjectowner($context,"SPSite")
[xml]$schema = gc .\schema.xml
$searchConfigurationPortability.ImportSearchConfiguration($owner,$schema.OuterXml)
$context.ExecuteQuery()

您可以自訂這些範例以開發支援需求的混合式嚴重損壞復原解決方案的搜尋組態匯出/匯入程序。

當編目唯讀 DR 陣列中的內容資料庫、 網站對應表格在 SharePoint 設定資料庫將不會更新在實際執行伺服器陣列中登錄新建立的網站。這表示這些網站以及內它們的內容會未編製索引完整或累加編目期間。要克服此問題,請務必定期執行將重新整理網站地圖 DR 適用於伺服器陣列上指定的 web 應用程式的所有內容資料庫上的下列Windows PowerShell命令。

Get-SPContentDatabase -WebApplication https://intranet.contoso.com | % {$_.refreshsitesinconfigurationdatabase()}

透過編目唯讀資料庫並定期更新網站對應,索引新鮮度高層級可以維護 DR 陣列中的伺服器。混合方法的第二階段是如何處理搜尋服務應用程式備份。有兩個實際選擇以下,是由下列清單中但選取的選擇取決於的業務需求的附註所示。

  • 如果商務可以成功地運作且符合其主要功能而不需要完整不失真的搜尋-核心組態元素中的搜尋管理員服務應用程式和能夠維護高搜尋索引新鮮度亦即允許函數 DR 網站中的商務 — 然後他們永不可能會還原服務應用程式至 DR.還原 search service 應用程式僅可能需要如果變成清楚無法使用的主要站台長的時間。這表示容錯回復至主要網站不是可行的與因此還原 search service 應用程式完全整合取決於搜尋重新連線的所有商務功能所需。在特定時間期間無法以觸發還原選取。

  • 如果將維護方式,儘完整不失真的需求若有容錯移轉],然後定期備份和還原程序無法執行搜尋儘可能在 DR 站台。可能的情況是每天或每週的備份及還原程序一起唯讀資料庫進行編目維護時效性盡可能 100%。搜尋索引為大型花費許多小時才能完成還原,因此向 RTO/RPO 目標介紹一些風險時問題。

清楚更複雜比簡單的備份及還原此混合方法但優點高於挑戰如果商務需求符合需求,才能實作此類的解決方案。

如需詳細資訊,我們建議您使用下列資源。

除了本白皮書及這些文章中所提供的選項,有其他方法可用於備份及還原SharePoint 2013的 search service 應用程式。這些方法所更細緻細微涉及單獨還原搜尋索引和搜尋資料庫放到新伺服器陣列。我們尚未涵蓋下列步驟,但如果您考慮以指令碼執行的方法,我們建議在您開始透過檢閱下列資源。

https://technet.microsoft.com/zh-tw/library/jj715263.aspx
顯示: