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

  • 發行項

 

**適用版本：**SharePoint Server 2016

**上次修改主題的時間：**2018-01-03

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

本文提供您可以使用擬定SharePoint Server中的搜尋支援嚴重損壞修復 (DR) 策略的最佳作法指導。使用較早版本的SharePoint Server嚴重損壞復原方法的許多不提供同等級的復原SharePoint Server 2016和SharePoint Server 2013。我們檢查這些方法，並提供與的好處及限制您需要知道的替代選項。

本文內容：

  • 簡介

  • 搜尋服務應用程式架構

  • 搜尋服務應用程式索引結構的概觀 （英文)

  • 一般嚴重損壞修復技巧 （英文)

  • 復原支援技術 （英文)

  • 其他資源

簡介

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

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

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

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

  • 您復原至位置

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

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

重要

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

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

搜尋服務應用程式架構

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

搜尋服務元件

元件或資料庫 描述

索引元件

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

索引元件包括：

  • 索引分割區

    您可以將索引分割成不連續的部分，每個保留不同的組件的索引。

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

  • 索引複本

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

查詢處理元件

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

管理元件

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

編目元件

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

內容處理元件

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

分析處理元件

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

搜尋管理資料庫

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

編目資料庫

儲存的編目歷程記錄以及管理編目作業。

連結資料庫

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

分析報表資料庫

儲存流量分析的結果。

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

具有多餘元件的搜尋拓撲

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

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

搜尋服務應用程式索引結構的概觀 （英文)

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

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

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

  • **路徑及標題：**包含的路徑及標題。

  • **建議：**記下此資料每日更新。

  • **社交同事 （人員）：**涉及不同的更新群組的人員欄位。

  • **社交標記：**包含社交標記。

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

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

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

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

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

  • 適當地與右元件數目以支援搜尋服務的大小調整目標 DR 伺服器陣列。

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

一般嚴重損壞修復技巧 （英文)

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

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

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

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

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

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

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

設定及搜尋經驗的功能變更

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

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

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

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

搜尋分析驅動的使用者建議

SharePoint Server搜尋中搜尋和流量分析處理為處理呼叫分析處理器的元件。此元件有下列責任：

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

  • 流量分析處理

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

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

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

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

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

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

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

選項 限制

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

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

  •  

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

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

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

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

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

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

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

復原支援技術 （英文)

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

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

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

最後一個方法是實際合併成單一的策略，提供容錯移轉高搜尋索引新鮮度，但會新增在其中也執行完整還原至兼具分析資訊及搜尋先前所述的兩個技術透過 DR 伺服器陣列的設定。

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

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

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

服務應用程式備份與還原

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

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

備份 search service 應用程式

若要備份 search service 應用程式，您可以使用Microsoft 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檔案儲存備份檔案。

還原 search service 應用程式

若要還原SharePoint Server 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>REDMOND\pkmacct</SPRequestedBy>
 <SPBackupMethod>Full</SPBackupMethod>
 <SPRestoreMethod>None</SPRestoreMethod>
 <SPStartTime>01/11/2016 02:30:27</SPStartTime>
 <SPFinishTime>01/11/2016 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 service 應用程式，可以使用 [覆寫] 選項。通常使用此選項只還原至同一個伺服器陣列備份的來源時。

注意

若要使用 [覆寫] 選項，那里具有已至少一個還原使用新的選項。如果不是這樣，現有的 Search service 應用程式使用相同的設定和命名必須提供 DR 伺服器陣列上。

當還原 search service 應用程式，它會自動暫停期間和之後還原。若要繼續之服務應用程式還原完成之後，請使用下列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列舉以取得這些設定： SSA、 SPSiteSubscription、 SPSite及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 應用程式的所有內容資料庫上的下列PowerShell命令。

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

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

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

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

這個合併的方法是清楚較複雜較簡單的備份與還原]，但優點高於挑戰如果公司需要符合需求，才能實作這類的解決方案。

其他資源

如需詳細資訊，建議您使用下列資源。

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

相關主題

規劃 SharePoint Server 的高可用性與災害復原