嚴重損壞復原最佳作法及 SharePoint 2016 搜尋的策略Disaster recovery best practices and strategies for SharePoint 2016 search

了解如何在 SharePoint Server 2016 或 SharePoint Server 2013 伺服器陣列中實作搜尋的最佳作法是嚴重損壞修復。Learn how to implement best practice disaster recovery for search in a SharePoint Server 2016 or SharePoint Server 2013 farm.

本文提供您可以使用擬定 search in SharePoint Server 支援的嚴重損壞修復 (DR) 策略的最佳作法指導。使用較早版本的 SharePoint Server 的嚴重損壞復原方法的許多不提供同等級的復原 SharePoint Server 2016 與 SharePoint Server 2013。我們檢查這些方法,並提供與的好處及限制您需要知道的替代選項。This article gives best practice guidance that you can use to develop a supported disaster recovery (DR) strategy for search in SharePoint Server. Many of the approaches used for disaster recovery in earlier versions of SharePoint Server don't provide the same level of recovery for SharePoint Server 2016 and SharePoint Server 2013. We examine these approaches and provide replacement options together with the benefits and limitations that you need to know about.

簡介Introduction

本文等提供藍圖實作嚴重損壞修復策略的文件和文件可讓您設定 SharePoint ServerSearch 服務應用程式 (如嚴重損壞修復的特定命令的間距SSA)。我們是數個一般嚴重損壞修復案例的說明及檢查的好處及限制每一種方法。它是不實際考量這些案例是完美適合您的組織,但您可以使用其作為指南 DR 策略符合貴組織的特定需求。This article bridges the gap between documentation that provides a roadmap for implementing a disaster recovery strategy and documentation that gives you the specific commands to configure disaster recovery for the SharePoint ServerSearch Service Application (SSA). We describe several typical disaster recovery scenarios and examine the benefits and limitations of each approach. It's unrealistic to think that these scenarios are a perfect fit for your organization, but you can use them as a guide for a DR strategy that meets your organization's specific requirements.

嚴重損壞修復 SharePoint Server 及及其支援的技術是一個複雜的主題,且有許多專用解釋以協助確保您的業務目標符合啟動事件時所需的規劃資訊來源在災害復原計劃。Disaster recovery for SharePoint Server and its supporting technologies is a complex topic, and there are many sources of information dedicated to explaining the planning needed to help ensure that your business objectives are met if there is an event that activates your disaster recovery plan.

最佳作法是建議您在您開始清楚識別並量化復原時間目標 (Rto) 及復原點目標 (RPOs) 您的組織。Rto 愈短,才可從損毀及 RPO,您可以從相同的損毀、 遺失的時間單位的資料復原時間是嚴重損壞復原規劃中的關鍵評量值。下列兩種商務導向評量設定下列階段:As a best practice, we recommend that you start by clearly identifying and quantifying Recovery Time Objectives (RTOs) and Recovery Point Objectives (RPOs) for your organization. RTO, the time that is required to recover from a disaster, and RPO, the data measured in time that you can lose from the same disaster, are key metrics for disaster recovery planning. These two business-driven metrics set the stage for the following:

  • 備份及還原程序、 媒體及儲存Backup and restore procedures, media, and storage

  • 您復原至位置Location where you recover to

  • 大小與複雜性復原解決方案Size and complexity of your recovery solution

您不能開發有效復原策略及評估技術解決方案而這些基準。You can't develop an effective recovery strategy and evaluate technical solutions without these benchmarks.

重要

整個計畫重心在營運持續力和 IT 復原需求,而不是建立 DR 策略所需的步驟。Focus on business continuity and IT recovery requirements, instead of the required steps to create a DR strategy.

雖然本文的範圍是 SharePoint Server 搜尋的嚴重損壞修復,我們建議您閱讀選擇 SharePoint Server 嚴重損壞修復策略開發嚴重損壞修復策略的準備。Although the scope of this article is disaster recovery for SharePoint Server search, we recommend that you read Choose a disaster recovery strategy for SharePoint Server in preparation for developing a disaster recovery strategy.

搜尋服務應用程式架構Search service application architecture

再查看開發嚴重損壞修復策略的不同方式下, 表提供在 SharePoint Server 搜尋及如何他們參與使用者搜尋體驗的元件的描述。搜尋應用程式元件和資料庫,如下表所述提供內容的嚴重損壞修復策略。Before looking at the different ways to develop a disaster recovery strategy, the following table provides a description of the components in SharePoint Server search and how they contribute to the end-user search experience. The search application components and databases described in the following table provide a context for a disaster recovery strategy.

搜尋服務元件Search service components

元件或資料庫Component or database 描述Description
索引元件Index component 擔任邏輯的表示法的索引複本。Serves as the logical representation of an index replica.

索引元件包括:The index component includes:

索引分割區Index partitions

您可以將索引分割成不連續的部分,每個保留不同的組件的索引。You can divide the index into discrete portions, each holding a separate part of the index.

搜尋索引為所有的索引分割區的彙總。索引分割區會儲存在一組的磁碟上的檔案。The search index is the aggregation of all index partitions. An index partition is stored in a set of files on a disk.

索引複本Index replicas

每個索引分割區都有一個以上的索引複本。Each index partition holds one or more index replicas that contain the same information.
查詢處理元件Query processing component 分析及處理搜尋查詢與結果]。Analyzes and processes search queries and results.
管理元件Administration component 執行所需的搜尋系統處理序。可以有多個搜尋管理元件每個 Search service 應用程式,但只能有一個作用中一次。Runs system processes that are required for search. There can be more than one search administration component per Search service application, but only one is active at a time.
編目元件Crawl component 根據項目中的編目資料庫所指定的內容進行編目。Crawls content based on what is specified in the crawl database.
內容處理元件Content processing component 執行編目的項目,例如文件剖析與屬性對應的各種程序。Carries out various processes on the crawled items, such as document parsing and property mapping.
分析處理元件Analytics processing component 執行搜尋分析與流量分析。Carries out search analytics and usage analytics.
搜尋管理資料庫Search administration database 儲存搜尋組態資料。有一個搜尋管理資料庫每個 search service 應用程式。Stores the search configuration data. There is only one search administration database per search service application.
編目資料庫Crawl database 儲存的編目歷程記錄以及管理編目作業。Stores the crawl history and manages crawl operations.
連結資料庫Link database 會儲存某些內容處理元件所擷取的資訊。它也會儲存點選連結資訊。Stores some of the information extracted by the content processing component. It also stores clickthrough information.
分析報表資料庫Analytics reporting database 儲存流量分析的結果。Stores the results of usage analytics.

有多種方式來分散搜尋元件以提供高可用性及可高度擴充搜尋拓撲],如下圖所示。在此圖表中,搜尋元件部署在不同的應用程式伺服器,以提供備援。此外,提供其他層級的容錯能力及延展性的不同的虛擬化主機伺服器上部署應用程式伺服器。There are multiple ways to distribute search components to provide a highly available and highly scalable search topology, as shown in the following diagram. In this diagram, search components are deployed on different application servers to provide redundancy. In addition, the application servers are deployed on different virtualization host servers, which provides another level of fault tolerance and provides scalability.

具有多餘元件的搜尋拓撲

如需散佈伺服器陣列伺服器上的搜尋元件的詳細資訊,請參閱規劃在 SharePoint Server 2016 中的企業搜尋架構及搜尋技術圖表在Search in SharePoint Server 2016For more information about distributing search components on farm servers, see Plan enterprise search architecture in SharePoint Server 2016 and search technical diagrams at Search in SharePoint Server 2016.

若要欣賞開發搜尋嚴重損壞修復策略的複雜性,您必須了解如何參照文件內的 Search Service 應用程式索引和資料庫。它是複寫的目前進行不使用任何格式或記錄傳送技術以複製 SharePoint 伺服器陣列之間的搜尋索引可能此參照系統。To appreciate the complexities of developing a search disaster recovery strategy, you must understand how documents are referenced within the Search Service Application index and databases. It is this referencing system that currently makes it impossible to use any form of replication or log shipping technology to copy the search indexes between SharePoint Server farms.

搜尋服務應用程式索引結構的概觀 (英文)Overview of the Search service application index structure

因為 SharePoint 搜尋服務應用程式索引的結構過於複雜,所以深入的描述會超出本文範圍。簡單合約索引所組成的一系列的資料無法更新群組的許多小部分。這可更新的群組可以視為的分割區透過 table 中的欄。根據預設,有六個搜尋索引中的這些群組。這些群組如下所示:Because the structure of the SharePoint Search service application index is so complex, an in-depth description is beyond the scope of this article. In simple terms, the index consists of many small pieces that are a series of updatable groups of data. These updatable groups can be thought of as partitions over columns in a table. By default, there are six of these groups in the search index. These groups are as follows:

  • 主要:包含大量的欄位中,儲存在此處的全文檢索。Main: contains the bulk of the fields, full text stored here.

  • Acl:涉及安全性修剪和 fast 編目的安全性。ACLs: involves security trimming and fast security crawling.

  • 路徑及標題:包含的路徑及標題。Path and Title: contains the path and the title.

  • 建議:記下此資料每日更新。Recommendations: note that this data is updated daily.

  • 社交同事 (人員):涉及不同的更新群組的人員欄位。Social Colleagues (People): involves a separate update group for people fields.

  • 社交標記:包含社交標記。Social Tags: contains social tagging.

每個更新群組設想為該群組類似結構中的 SQL Server 資料庫中的欄位索引結構。更新群組的每個包含索引結構的區塊的檔案分割儲存層級。每個這些檔案包含不同的整體索引的一部分。內容會分散這些分割區識別碼使用的每個唯一的文件。此識別碼為DocID、 也是效能計數器。Think of each update group as an index structure for the fields within that group, similar in structure to a SQL Server database. The update groups are partitioned at the storage level into files that each contains a chunk of the index structure. Each of these files contains a different piece of the overall index. Content is distributed over these partitions by using an identifier for each unique document. This identifier is the DocID, which is also a counter.

建立新的 search service 應用程式之後,計數器從零開始。DocID會加上遞增值其中每個編目期間發現的新項目時和效能計數器會繼續以發現新項目時增加一段時間的時間。效能計數器值永遠不會遞減。即使刪除文件,其對應的效能計數器值永遠不會重複使用。新增及移除項目或文件庫和清單一段時間也表示DocID不連續內任何網站或文件庫。因此,即無法預測DocID的任何搜尋主體中的文件。When a new search service application is created, the counter starts at zero. The DocID is incremented by one every time that a new item is discovered during a crawl, and the counter continues to increase over time as new items are discovered. The counter value is never decremented. Even if a document is deleted, its corresponding counter value is never reused. Adding and removing documents or items from libraries and lists over time also means that the DocID is not consecutive within any site or library. Therefore, it's impossible to predict the DocID of any document in the search corpus.

這會呈現任何搜尋複寫策略的挑戰是任何兩個伺服器陣列中有不是保證或甚至是DocID值會比對伺服器陣列中任何一份文件的機率。因為DocID值不相符,就不能索引資料或分析資料連結至DocID值進行複寫。搜尋結果不是有效,因為對每個伺服器陣列相同的文件會有不同的DocIDWhere this presents a challenge for any search replication strategy is the fact that in any two farms, there is no guarantee or even the probability that the DocID values will match for any one document in the farm. Because the DocID values won't match, it's impossible to replicate index data or analytic data that is linked to the DocID value. Search results won't be valid because the same document will have a different DocID on each farm.

當我們檢查如何建立 Search Service 應用程式的完整不失真的 DR 策略時,請務必下列兩件事發生:When we examine how to create a full fidelity DR strategy for the Search Service Application, it's important that the following two things occur:

  • 元件和資料庫所儲存的資料設定和查詢所需的識別並正確地還原至目標 DR 伺服器陣列使用適當的方法。The components and databases that are storing data needed for configuration and querying are identified and correctly restored to the target DR farm using an appropriate method.

  • 適當地與右元件數目以支援搜尋服務的大小調整目標 DR 伺服器陣列。The target DR farm is appropriately scaled with the right number of components to support the size of the search service.

這兩個這些活動會參照中的下列各節和實作各節中所包含的技術詳細資料。Both of these activities will be referenced in the following sections and technical details included in the implementation sections.

一般嚴重損壞修復技巧 (英文)Common disaster recovery techniques

在舊版 SharePoint 中,有多種方式協助確保您有容錯移轉填入與最新的索引與接近 100%搜尋時效性的 Search Service 應用程式。下列範例會顯示已通常用於嚴重損壞修復的方式。In earlier versions of SharePoint, there are multiple ways to help ensure that you had a failover Search Service Application populated with up-to-date indexes and near 100 percent search freshness. The following examples show approaches that were typically used for disaster recovery.

  • 編目唯讀內容資料庫已] 選項,SQL Server 記錄傳送方法用於維護實際執行內容資料庫的複本附加至 DR 伺服器陣列以唯讀模式。這表示 DR 伺服器陣列上裝載 SSA 的可設定為唯讀的 web 應用程式透過編目資料庫 DR 伺服器陣列上。任何設定變更都 SSA 層級上以協助確保使用者的完整不失真的體驗發生容錯移轉時的兩個伺服器陣列中實作。Crawling read-only content databases was an option, where SQL Server Log shipping methods were used to maintain a copy of the production content databases attached to the DR farm in read-only mode. This means that an SSA hosted on the DR farm could be configured to crawl the databases via a read-only web application on the DR farm. Any configuration changes had to be implemented at the SSA level on both farms to help ensure a full fidelity experience for end users in the event of a failover.

  • 具有雙重編目] 選項,也復原伺服器陣列上進行編目實際執行伺服器陣列與因此相同的內容已發現及編製索引。設定變更 managed 屬性或編目檔案類型,已安裝 Ifilter 和等鎖實際執行和 DR 伺服器陣列中實作,但這輕鬆已使用適當的變更控制原則來管理。With the dual-crawl option, the recovery farm also crawls the production farm, and therefore the same content was discovered and indexed. Configuration changes to managed properties or crawled file types, installed IFilters, and so on had to be implemented in both production and DR farms, but this was easily managed by using a suitable change control policy.

嚴重損壞修復策略時的其他選項不會提供相同的層級的搜尋索引新鮮度,但如果索引新鮮度或復原時間已不具關鍵性,則他們是有效的選項。一般而言,則較複雜設定及實作這些選項。下列範例為一般的方法。Other options for disaster recovery strategies did not offer the same level of search index freshness, but if index freshness or the time to recover was not mission critical, then they are valid options. Typically, these options are more complex to configure and implement. The following examples are typical of approaches.

  • SSA 搜尋管理資料庫無法備份單獨。SSA 搜尋管理資料庫已備份單獨使用慣用的 SQL Server 備份方法及 DR 伺服器陣列上用來建立使用 Microsoft PowerShell SSA。這會還原的搜尋設定,但不是的索引。填入搜尋索引及完成復原需要完整編目。The SSA Search Administration database could be backed up independently. The SSA Search Administration database is backed up independently using conventional SQL Server backup approaches and used on the DR farm to create a SSA using Microsoft PowerShell. This restores the search configuration but not the indexes. A full crawl is needed to populate the search indexes and complete the recovery.

  • 完整的 SSA 備份與還原。使用 Microsoft PowerShell 或使用執行完整的 SSA 備份及還原 SharePoint 管理中心網站介面。這會備份 SSA 資料庫和搜尋索引,讓它們可以還原以填入該伺服器陣列的 SSA DR 伺服器陣列上。A full SSA backup and restore. A full SSA backup and restore is performed using Microsoft PowerShell or using the the SharePoint Central Administration website interface. This backs up the SSA databases and search indexes, which enables them to be restored on the DR farm to populate the SSA on that farm.

在 SharePoint Server 2016 或 SharePoint Server 2013 中,搜尋架構中的重大變更及如何儲存組態元素表示我們必須以不同方式考慮搜尋嚴重損壞修復。下列各節說明這些變更及其如何影響,可用的災害復原選項。In SharePoint Server 2016 or SharePoint Server 2013, significant changes in the search architecture and how configuration elements are stored means we have to think differently about search disaster recovery. The following sections describe these changes and how they affect the disaster recovery choices that are available.

設定及搜尋經驗的功能變更Configuration and functional changes to the search experience

SharePoint Server 中的 [網站管理] 頁面提供支援的搜尋經驗的彈性設定的選項。網站和網站集合的新組態選項表示網站管理員可以將搜尋先前可能只是伺服器陣列或搜尋系統管理員所做的組態變更。下一個螢幕擷取畫面顯示您可以在此設定搜尋選項的兩個位置 —網站集合管理搜尋之下。The Site Administration pages in SharePoint Server provide options that support a flexible configuration of the search experience. The new configuration options for sites and site collections means that site administrators can make search configuration changes that previously could only be made by farm or search administrators. The next screen capture shows the two locations where you can configure search options—under Site Collection Administration or under Search.

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

您可以進行組態變更搜尋項目,例如查詢規則] 或 [結果來源] 從 [網站集合管理] 或 [搜尋] 下的清單和結果會是相同。不過,將變更儲存的位置直接影響嚴重損壞修復。所有網站集合或 web 應用程式、 變更所做的變更只會儲存在 Search Service 應用程式 (SSA) 管理資料庫。除非此資料庫從備份還原至嚴重損壞修復伺服器陣列,設定的變更將不會是復原環境中可用的。You can make a configuration change to a search item, such as Query Rules or Result Sources, from the list under Site Collection Administration or Search, and the result will be the same. However, the location where a change is stored directly affects disaster recovery. All of the changes made in a site collection or a web application, the change will only be stored in the Search Service Application (SSA) administration database. Unless this database is restored from a backup to the disaster recovery farm, then configuration changes won't be available in the recovered environment.

SharePoint Server 搜尋中另一個新的功能會立即重新編製索引] 功能,可讓網站集合、 Web 及清單層級管理員要求容器的下一個編目期間重新索引。這項功能完全管理內容資料庫中並要求此 DR 伺服器陣列內的管理員因此觸發下次編目執行 DR 伺服器陣列上的實際執行伺服器陣列中的相同事件。Another new feature in SharePoint Server Search is the ReIndex Now capability that allows administrators at the Site Collection, Web, and List levels to request a reindex of the container during the next crawl. This feature is managed completely within the content database, and therefore an administrator requesting this within the DR farm will trigger the same event in the Production farm when the next crawl runs on the DR farm.

搜尋分析驅動的使用者建議Search analytics-driven user recommendations

在 SharePoint Server 搜尋的搜尋與流量分析處理為處理呼叫分析處理器的元件。此元件有下列責任:In SharePoint Server Search the processing of search and usage analytics is handled by a component called the Analytics processor. This component has the following responsibilities:

  • 處理搜尋分析資訊的處理Handles the processing of Search Analytic information

  • 流量分析處理Processes usage analytics

  • 提供內容的處理器用來支援搜尋建議功能的關聯式資訊Provides relational information that the content processor uses to support the search recommendations feature

  • 提供內容的處理器使用以改善相關性與排名計算的文件常用性 (例如頁面造訪和點選) 的統計資訊Provides statistical information about document popularity (for example, page visits and clicks) that the content processor uses to improve relevancy and ranking calculations

閱讀更多在個別的分析處理程序,請參閱 < Overview of analytics processing in SharePoint Server的詳細資訊。To read more on the individual analytics processes, see Overview of analytics processing in SharePoint Server for detailed information.

在搜尋索引和報告與連結資料庫所儲存的已處理的資訊。因此,雖能夠同時務必使用這項處理的資訊已複寫至 DR 在伺服器陣列中的同步處理狀態的唯一方法是完整的 Search Service 應用程式備份與還原。The processed information is stored in the Search Index and also by the Reporting and Links databases. Therefore, the only method capable of making sure that this processed information is replicated to the DR farm in a synchronized state is a full Search Service Application backup and restore.

服務應用程式備份及還原增強功能Service application backup and restore improvements

滿足所有 DR 需求擷取設定和索引資料的方法是服務應用程式備份與還原。這些作業是經過精心大幅減少 RTO 及 RPO 相較於舊版 SharePoint。變更的執行緒數目的支援用於備份與還原程序加上的改良功能支援完整及差異備份與還原作業會在此區域中的所有按鍵提升。The approach that satisfies all of the DR requirements for capturing configuration and index data is service application backup and restore. These operations were invested in significantly to reduce the RTO and RPO compared to earlier versions of SharePoint. Support for changing the number of threads used in the backup and restore processes plus improvements in supporting both full and differential backup and restore operations are all key gains in this area.

當採用完整的搜尋服務應用程式備份和還原成 DR 策略的方法,整體 RPO 是由兩件事管理。自上次完整的服務時間是在應用程式備份 RPO 和是為了真的還原服務應用程式所需的時間是 rto 愈短。這兩個上述時間都有可能因此發生災害時所宣告的服務還原期望小心管理需要增加為 Search service 應用程式增加時,已編製索引內容的持續時間。我們建議進行經常測試才會還原以確認仍可符合任何 SLA 所需的 RTO 及 RPO 對您服務連續性管理練習的一部分。下表摘要說明 Search service 應用程式的備份與還原選項。When adopting the approach of a full Search service application backup and restore as the DR strategy, overall RPO is governed by two things. The time since the last full service application backup is the RPO, and the time that is required to actually carry out a service application restore is the RTO. Both of these times are likely to increase in duration as the indexed content in the Search service application increases, so careful management of the expectation for service restoration in the event of a disaster being declared is needed. We recommended conducting frequent test restores as part of your service continuity management exercises to make sure that any SLA against required RTO and RPO can still be met. The following table summarizes the backup and restore options for the Search service application.

選項Option 限制Limitations
編目 DR 伺服器陣列中的唯讀資料庫。Crawl the read-only databases in the DR farm. 沒有網站集合或 web 層級搜尋設定的變更會複寫到 DR 伺服器陣列。No site collection or web level search configuration changes are replicated to the DR farm.
執行雙編目實際執行伺服器陣列。Performa dual-crawl production farm. 沒有網站集合或 web 層級搜尋設定的變更會複寫到 DR 伺服器陣列。No site collection or web-level search configuration changes are replicated to the DR farm.

分析導向搜尋索引更新不會複寫到 DR 伺服器陣列。Analytics-driven search index updates are not replicated to the DR farm.
還原 DR 伺服器陣列上的搜尋管理資料庫並重新建立服務。Restore the Search Administration database on the DR farm and re-create the service. 分析導向搜尋索引更新不會還原至 DR 伺服器陣列。這是因為索引將會是空時建立的服務應用程式時,同時將需要完整編目。Analytics-driven search index updates are not restored to the DR farm. This is because the index will be empty when the service application is created, and a full crawl will be needed.
執行完整的 SSA 備份與還原]。Do a full SSA backup and restore. 在搜尋索引不失真但還原大型的服務應用程式沒有限制可能會需要多種小時和容錯移轉期間影響 rto 愈短。No limitations on search index fidelity but restoring a large service application may take serveral hours and impact the RTO during a failover.

復原支援技術 (英文)Supported techniques for recovery

沒有只有一個會提供完整不失真的復原,包括所有分析處理搜尋索引及服務應用程式、 網站集合和 web 層級的所有搜尋設定項目改良功能的支援嚴重損壞修復技巧在實際執行伺服器陣列。這個方法需在後面接著要 DR 伺服器陣列的服務應用程式的完整還原 Search service 應用程式的完整備份。索引及設定將會還原至相同點備份的時間讓新的編目如果備份數天,是需要將最新的索引。這個方法的特定步驟稍後所述的紙張。There is only one supported disaster recovery technique that will provide a full fidelity recovery, including all analytics processing improvements to the search index and all search configuration items at the Service Application, Site Collection, and web levels within the production farm. This approach requires a full backup of the Search service application followed by a full restore of the service application to the DR farm. The indexes and configuration will be restored to the same point in time that the backup was taken, so if the backup was several days old, a new crawl will be required to bring the indexes up to date. The specific steps for this approach are described later in the paper.

它也支援以取得 Search service 應用程式管理資料庫的備份及還原的 DR 網站中。使用 Microsoft PowerShell,管理員可以使用備份來建立新的 Search service 應用程式。但是,這只會復原 search service 應用程式與 SharePoint 網站及 web 中的任何自訂的搜尋設定的實際設定 — 它不會復原搜尋索引。需要完整編目將填入主體進行搜尋。此外,無法復原搜尋索引分析增強因為在實際執行伺服器陣列上用來產生的信號只有駐留。It is also supported to take a backup of the Search service application administration database and restore that in the DR site. By using Microsoft PowerShell, administrators can create a new Search service application by using the backup. However, this will only recover the actual configuration of the search service application and any customized search settings within the SharePoint sites and webs—it won't recover the search index. A full crawl will be required to populate the corpus for searching. In addition, it can't recover the analytical augmentation of the search indexes because the signals used to generate that are only resident on the production farm.

沒有如果不必 DR 策略中包含搜尋的主要目的是為了確保搜尋索引新鮮度在容錯移轉階段可能會採用的另一種方式。藉由使用兩種方法之一,索引可以維護非常新鮮狀態,但隨著複雜的組態和數限制。因為 DR 伺服器陣列中的編目程式必須設定為編目實際執行伺服器陣列或將內容資料庫已複寫至 DR 伺服器陣列以支援本機編目可讀取狀態而言複雜度。這個方法會有所限制,因為在生產環境中的 Search service 應用程式的設定不會複寫以任何方法來 DR,而且搜尋索引更新的分析資料處理也會遺失。如果這些限制是可接受的這是非常大的彈性的方式來協助確保高索引新鮮度及 DR 伺服器陣列中的搜尋可用性。There is another approach that might be employed if the main purpose of having to include search in the DR strategy is to help guarantee search index freshness at failover time. By using one of two methods, the index can be maintained in a very fresh state but with the introduction of complex configuration and several limitations. The complexity comes in because either the crawlers in the DR farm have to be configured to crawl the production farm or the content databases have to be replicated in a readable state to the DR farm to support local crawling. This approach has limitations in that the configuration of the Search service application in production is not replicated in any way to DR, and search index updates from the processing of analytic data is also missing. If these limitations are acceptable, then this is a very flexible way to help guarantee high index freshness and search availability in the DR farm.

最後一個方法是實際合併成單一的策略,提供容錯移轉高搜尋索引新鮮度,但會新增在其中也執行完整還原至兼具分析資訊及搜尋先前所述的兩個技術透過 DR 伺服器陣列的設定。A final approach is to actually combine the two techniques described earlier into a single strategy that provides high search index freshness on failover but adds the possibility of also performing a full restore to bring the analytics information and search configuration over to the DR farm.

在此例中,會採用的完整備份和遠端或本機編目和還原程序可使用如果需要。若要啟動完整的還原程序一般原因是如果 DR 網站容錯移轉大於一般服務在暫時中斷與容錯回復至實際執行環境不可能在所同意的期間。在此情況下,還原程序會叫用來協助確保 DR 網站中所提供完整不失真的搜尋體驗。然後會將移到完整時效性的搜尋索引起始新的編目。In this case, both a full backup and remote or local crawling would be employed and a process for the restore made available if it is needed. A typical reason to start the full restore process is if the failover to the DR site is more than a temporary interruption to normal service and failing back to production isn't possible in an agreed time period. In that case, the restore process would be invoked to help ensure that the full fidelity search experience was available in the DR site. A new crawl would then be initiated to bring the search index up to full freshness.

有還原 Search service 應用程式使用 [覆寫] 選項時要考慮的隱含意義。服務應用程式還原,這表示沒有更新期間都會離線或處理的查詢。企業版搜尋是不重要的函數,這是可能不是發生問題。但如果還原期間必須提供搜尋查詢功能,然後另一個作法可視為。永遠建立新的搜尋服務應用程式還原程序期間及還原完成後,執行 [取得最新索引新鮮度的新編目是的替代選項。編目完成之後,請切換至新的服務應用程式的服務應用程式關聯並不會中斷工作上執行。無法再刪除舊的服務應用程式。最大的挑戰是其中一個容量,基本上雙索引及資料庫就所需的空間來裝載平行的兩個服務應用程式。搜尋服務的重要性會規定這是否必須配合公司的內容。There are implications to consider when restoring a Search service application that uses the overwrite option. The service application will be offline during the restore, which means no updates or queries will be processed. For a business where search is not a critical function, this is likely not to be a problem. But if search query functionality must be available during the restore, then another option can be considered. The alternative option is to always create a new Search service application during the restore process, and when the restore is complete, run a new crawl to get the index freshness up to date. After the crawl finishes, switch the service application association to the new service application and carry on working without interruption. The older service application could then be deleted. The biggest challenge is one of capacity in that basically double the index and database space would be required to host two service applications in parallel. The criticality of search services will dictate whether this is something that the business must accommodate.

所有這些事項視為,它是值得調查 Search service 應用程式的預期的 RPO 和 RTO 需求。目前 Office 365 SharePoint search service 應用程式支援 RPO 和 rto 愈短的一週。如果您考慮這意味著,它表示該組態的項目、 分析處理資訊及搜尋時效性所有可能最大值為一週過期還原的時機。再次依據的預期在環境中的變更速率和搜尋安裝程式的重要性,則可能審慎執行以協助確保可以達到最佳的 RPO 和 RTO 適用於企業的每日或甚至是 subdaily 備份。沒有方式您一樣與內容的備份因為搜尋內容是非常液維護多個備份複本的需求和暫時性,所以最一或兩個完整備份會保留。With all these things considered, it is worth investigating the expected RPO and RTO requirements of the Search service application. Currently, Office 365 SharePoint supports an RPO and RTO of one week for the search service application. If you consider what this means, it implies that configuration items, analytics processed information, and search freshness could all be a maximum of one week out of date when a restore is performed. Once again, depending on the expected rate of change in the environment and the criticality of the search setup, it may be prudent to run daily or even subdaily backups to help make sure that an optimal RPO and RTO can be achieved for the business. There is no requirement to maintain multiple backup copies as you would do with content backups because the search content is very fluid and transient, so at most one or two full backups would be retained.

服務應用程式備份與還原Service application backup and restore

下列資訊會包含在搜尋備份及還原文章中的關鍵點的簡短摘要:The following information is a brief summary of the key points contained in the Search Backup and Restore articles:

在哪個搜尋服務備份必須採取的頻率會將會受到影響許多事項,但主要商務所需的 RPO 將會是主要的驅動程式。備份及還原服務應用程式所需的時間為搜尋索引較大,取得更久及更久。只有一個搜尋備份,即會發生一次並完成備份的時間是在即可達到基本 RPO。DR 伺服器陣列上完成還原持續時間因此是可以即可達到基本 rto 愈短,像備份的時間,這會擴充一段時間。如果備份或還原時間開始 encroach 所需的服務等級協定 (Sla) 上的搜尋 RPO 和 rto 愈短,則商務必須制定一些追蹤更靈活如果中較小一個逼真度方法,如下所述更新版本,或調整 Sla 上的決策若要符合可以達成目標。The frequency at which search service backups must be taken will be influenced by many things, but primarily the RPO required by the business will be the key driver. As the search index becomes larger, the time taken to both back up and restore the service application will get longer and longer. Only one search backup can occur at a time, and the time for the backup to complete is the minimum RPO that can be achieved. The duration for the restore to complete on the DR farm is therefore the minimum RTO that can be achieved, and like backup time, this will extend over time. If the backup or restore times begin to encroach on the required service level agreements (SLAs) for search RPO and RTO, then the business must make some decisions on following a more flexible if lesser fidelity approach, as described here later, or adjusting the SLAs to meet an achievable target.

備份 search service 應用程式Backing up the search service application

若要備份 search service 應用程式,您可以使用 Microsoft PowerShell 或管理中心的管理使用者介面。所需的 PowerShell 指令程式是如下:To back up the search service application, you can use either Microsoft PowerShell or the Central Administration User Interface. The PowerShell cmdlet required is as follows:

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

以下是範例:Here's an example:

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。This example will take a full backup of the Search service application named Contoso Search Service Application and store the backup files in the location \server\searchbackup.

注意

BackupMethod參數只會套用至搜尋資料庫。在所有的情況下,搜尋索引完整備份無論選擇這個選項。The BackupMethod switch will only apply to the search databases. In all cases, the search indexes are fully backed up regardless of the option chosen.

您可以檢視上方的 [備份與還原工作狀態] 頁面上的所有備份工作的一般狀態的 [整備] 區段。您可以在頁面的 [備份] 區段中的下半部檢視目前的備份工作的狀態。[狀態] 頁面會自動更新每 30 秒。您可以按一下 [重新整理手動更新狀態的詳細資訊。備份及復原是計時器服務工作。因此,可能需要幾秒開始備份。若收到任何錯誤,可以檢閱 [備份與還原工作狀態] 頁面上的 [失敗訊息] 欄中。您也可以找到更多詳細資料中所指定的 UNC 路徑的Spbackup.log檔案儲存備份檔案。You can view the general status of all backup jobs at the top of the Backup and Restore Job Status page in the Readiness section. You can view the status for the current backup job in the lower part of the page in the Backup section. The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. Backup and recovery are timer service jobs. Therefore, it might take several seconds for the backup to start. If you receive any errors, you can review them in the Failure Message column of the Backup and Restore Job Status page. You can also find more details in the Spbackup.log file at the UNC path that you specified for storing the backup file.

還原 search service 應用程式Restoring the search service application

若要還原 SharePoint Server 搜尋服務應用程式、 備份必須已成功完成,且如果經常採取備份,然後要還原之特定備份的識別碼需要。在第幾種方法可以輕鬆地取得此識別碼。最簡單是開啟拍攝備份實際執行伺服器陣列上的 [備份與還原歷程記錄] 頁面上,然後輸入備份目錄位置。這會提供備份及還原資訊清單檔案 (psbrtoc.xml) 的所有項目的清單。下列螢幕擷取畫面中,可以輕鬆地呈現 {149fc816-8927-4a32-9437-6e05c2869ab7} 的備份識別碼。To restore a SharePoint Server Search service application, the backup must have completed successfully, and if backups are taken frequently, then the ID of the specific backup to be restored is needed. This ID can be easily obtained in several ways. The simplest is to open the Backup and Restore History page on the production farm where the backup was taken and enter the Backup Directory Location. This provides a list of all the entries in the backup and restore manifest file (psbrtoc.xml). In the following screen shot, a backup ID of {149fc816-8927-4a32-9437-6e05c2869ab7} can be easily seen.

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

若要使用備份與還原歷程記錄] 頁面上的替代名稱是直接開啟 [製作備份及還原資訊清單和檢查所需的項目。因為此檔案的大小會成長與每個備份及還原執行、 檢查此檔案可能有最佳的方法,特別是如果有高頻率的備份與還原作業。The alternative to using the backup and restore history page is to directly open the backup and restore manifest and examine it for the desired entry. Because the size of this file will grow with every backup and restore performed, examining this file may not be the optimum approach—especially if there is a high frequency of backup and restore operations.

下列範例會顯示典型的項目中spbrtoc.xml,且您可以檢視可以輕易識別的備份識別碼。The following example shows typical entries in spbrtoc.xml, and you can see that the backup ID can easily be identified.

<?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檔案相同。Another available method is to use the Get-SPBackupHistory cmdlet, which can also provide the same information as the spbrtoc.xml file.

下一步] 兩個範例說明如何執行還原作業使用Restore-SPFarm指令程式。The next two examples show how to perform the restore operation using the Restore-SPFarm cmdlet.

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"

注意

如果不提供任何備份的識別碼,則會使用最近的可用備份從目錄。If no backup ID is provided, then the most recent available backup from the directory is used.

RestoreMethod您使用決定如何處理程序將流程之後執行Restore-SPFarm指令程式。The RestoreMethod you use determines how the process will flow after it runs the Restore-SPFarm cmdlet.

如果選擇 [新增] 選項,以提供新的伺服器陣列上的位置備份中的每個元件和資料庫提示您執行此指令程式的系統管理員。這可以是伺服器陣列拓撲和 DR 伺服器陣列中的命名慣例不完全符合實際執行,這是常見的案例的特別有用。若要建立對應的名稱和伺服器拓撲的伺服器陣列還原 Search service 應用程式,可以使用 [覆寫] 選項。通常使用此選項只還原至同一個伺服器陣列備份的來源時。If the new option is chosen, then the administrator running the cmdlet is prompted to provide a location on the new farm for each component and database in the backup. This can be especially useful if the server farm topology and naming convention in the DR farm does not exactly match production, which is a frequently encountered scenario. If the Search service application is being restored to a farm that was built with matching names and server topology, then the overwrite option can be used. Typically this option is only used when restoring to the same farm that is the source of the backup.

注意

若要使用 [覆寫] 選項,那里具有已至少一個還原使用的選項。如果不是這樣,現有的 Search service 應用程式使用相同的設定和命名必須提供 DR 伺服器陣列上。To use the overwrite option, there has to have been at least one restore using the new option. If this is not the case, an existing Search service application that uses identical configuration and naming must be available on the DR farm.

當還原 search service 應用程式,它會自動暫停期間和之後還原。若要繼續之服務應用程式還原完成之後,請使用下列 PowerShell 命令。When restoring a search service application, it will be automatically paused during and after the restore. To resume the service application after the restore finishes, use the following PowerShell command.

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

特定給系統管理員也是記事的用來還原 Search service 應用程式具有每個分割區的多個複本的程序。還原程序只會還原為其中一個內每個分割區,複本及背景工作會處理複寫的每個分割區的所有其他複本的分割區資訊。搜尋索引和查詢在線上並功能在此程序,但 Search service 應用程式的管理頁面也可能會顯示複本為等到此作業完成後變慢。Also of particular note to the administrator is the process that is used to restore a Search service application that has multiple replicas per partition. The restore process will only restore to one of the replicas within each partition, and a background task will handle the replication of the partition information to all other replicas for each partition. Search indexing and querying is online and functional during this process, but the administration pages for the Search service application may well show the replicas as degraded until this operation is complete.

合併的嚴重損壞復原方法Combined disaster recovery approach

如前所述,與服務應用程式備份與還原所維護完整不失真的 DR 解決方案唯一支援的方法,會變成特別面對以達到低 RPO/RTO 搜尋的項目。如已編製索引的主體變成較大,備份及還原時間的時間可以成為擴充一段時間。這可能會導致較超過所需的 RPO 和 RTO。As already mentioned, with service application backup and restore being the only supported approach to maintaining a full fidelity DR solution, it becomes especially challenging to achieve a low RPO/RTO for search. Time to back up and time to restore can become extended over time as the indexed corpus becomes larger. This could lead to a much longer than desired RPO and RTO.

若要克服達成低的 RPO RTO 的挑戰,可以使用的一種方式就是採用解決方案的兩個尖端方法。下列清單顯示此解決方案。One approach that can be employed to overcome the challenges of achieving low RPO/RTO is to adopt a two-pronged approach to the solution. The following list shows this solution:

  • 使用唯讀內容資料庫或雙重編目實際執行網站編目來維護 DR 伺服器陣列中的搜尋索引新鮮度的可接受的程度。Use crawling of read-only content databases, or dual-crawl the production site to maintain an acceptable level of search index freshness in the DR farm.

  • 讓搜尋服務應用程式備份,以及定期還原至 DR 陣列或有提供這些以防主要網站不是可復原。Take Search service application backups, and either periodically restore them to the DR farm or have them available in case the primary site is not recoverable.

若編目唯讀資料庫 DR 在伺服器陣列是好的選擇,則您必須考慮在實際執行伺服器陣列中變更事實將不會複寫到的復原伺服器陣列。我們所述,這包括索引的搜尋服務分析更新並設定項目例如結果來源、 查詢規則與結構描述修改的變更。如果您採用合併的方法,最好是非常重要了解所有要點並放入進行適當的策略。目前沒有支援的方法規避分析更新遺失但是可以採取步驟來解決組態變更的更新。您可以嘗試執行類似下列的範例。If crawling read-only databases in the DR farm is the preferred choice, then you must consider the fact that changes in the production farm won't be replicated to the recovery farm. As we mentioned, this includes the search service analytics updates to the index and changes to configuration items such as result sources, query rules, and schema modifications. If you adopt a combined approach, then it's very important to understand all the implications and put in place a suitable strategy. Currently, there is no supported way to circumvent the loss of the analytics updates, but steps can be taken to work around updates to configuration changes. You could try actions similar to the following examples.

請確定所有自訂的結果來源、 查詢規則以及重要的搜尋結構描述變更會在 search service 應用程式層級管理中心而不在網站集合或子網站進行。例如,請考慮特定的查詢規則來管理 [首頁] 頁面上的內容有相依性的公司內部網路入口網站。這些規則會在實際執行伺服器陣列上建立和手動複製到以協助確保此設定是可用的 DR 伺服器陣列。同樣地,自訂對應的編目屬性至 managed 屬性必須實作在兩個伺服器陣列中的服務應用程式層級。Ensure that all custom result sources, query rules, and search schema changes regarded as business critical are made at the search service application level in Central Administration and not within site collections or subsites. For example, consider a corporate intranet portal that has a dependency on specific query rules to manage the content on the home page. These rules would be created on the production farm and manually replicated to the DR farm to help make sure that this configuration is available. Similarly, custom mappings of crawled properties to managed properties must be implemented at the service application level in both farms.

很可能擷取站台層級與 web 層級搜尋設定項目並將其匯出至 XML 檔案中使用 PowerShell。例如下, 一個 PowerShell 範例會從網站匯出設定項目"http://intranet.contoso.com"intranetcontosocom.xml 上名為 XML 檔案。這個方法發佈至 SharePoint 社群並搭配其權限。您可以在匯入及匯出的搜尋組態設定 SharePoint 2013 中檢視此部落格文章It is possible to capture the site-level and web-level search configuration items and export them to an XML file by using PowerShell. For example, the next PowerShell example will export configuration items from the site "http://intranet.contoso.com" to an XML file that is named intranetcontosocom.xml. This approach was published to the SharePoint community and is used with their permission. You can view this blog post at Importing and Exporting Search Configuration Settings in 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、 及SPWebIn the previous example, we export the configuration from SPSite. You can use the SearchObjectLevel enumeration to obtain these settings: SSA, SPSiteSubscription, SPSite, and SPWeb.

下一個範例會示範如何匯入您取得從另一個環境的設定。The next example shows how to import the settings that you obtain from another environment.

[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()

您可以自訂這些範例以開發支援需求的合併的災害復原解決方案的搜尋組態匯出/匯入程序。You can customize these examples to develop a search configuration export/import process that supports your requirements for a combined disaster recovery solution.

當編目 DR 伺服器陣列中的唯讀內容資料庫、 站台對應表 SharePoint 設定資料庫中的將不會更新在實際執行伺服器陣列中登錄新建立的網站。這表示這些網站以及內它們的內容會未編製索引完整或累加編目期間。若要克服這,請務必定期執行會重新整理網站地圖 DR 伺服器陣列上指定的 web 應用程式的所有內容資料庫上的下列 PowerShell 命令。When crawling read-only content databases in the DR farm, the site map table in the SharePoint configuration database will not be updated to register newly created sites in the production farm. This means that those sites plus the content within them will not be indexed during full or incremental crawls. To overcome this, it is important to periodically run the following PowerShell command that will refresh the site map on the DR farm for all content databases on the given web application.

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

唯讀資料庫進行編目,並定期更新網站對應、 索引新鮮度高層級可以維護 DR 伺服器陣列中。合併方法的第二階段是如何處理搜尋服務應用程式備份。有兩個實際選擇以下,是由下列清單但選取的選擇取決於的業務需求的附註所示。By crawling the read-only databases and updating the site map periodically, a high level of index freshness can be maintained in the DR farm. The second stage of the combined approach is what to do with the Search service application backups. There are two real choices here, shown in the following list but note that the selected choice will depend on the needs of the business.

  • 如果公司可以成功地運作且符合其主要功能而不需要完整不失真的搜尋-核心設定元素中的搜尋管理員服務應用程式和能夠維護高搜尋索引新鮮度亦即允許業務 DR 網站中的運作 — 然後他們可能永不還原服務應用程式到 DR.還原 search service 應用程式僅可能需要如果變成清楚的主要站台將無法使用長時間。這表示容錯回復至主要網站不是可行的與因此完整還原 search service 應用程式將取決於搜尋重新連線的所有業務功能所需。在特定時間期間無法選取要還原工作流程觸發。If the business can operate successfully and meet its primary functions without having full fidelity search—that is, the core configuration elements in the search admin service application and the ability to maintain a high search index freshness allow the business to function in the DR site—then they may never restore the service application into DR. Restoring the search service application may only be required if it becomes clear that the primary site will not be available for a long time. This means that a failback to the primary site is not possible, and therefore restoring the search service application fully is needed to bring all business functions that depend on search back online. A specific time period could be selected to trigger the restore.

  • 如果將維護量完整不失真的需求搜尋儘可能在 DR 站台,若有容錯移轉],然後定期備份和還原程序無法執行。可能的情況是每天或每週的備份及還原程序一起唯讀資料庫進行編目維護時效性盡可能 100%。搜尋索引為大型花費許多小時才能完成還原,因此向 RTO/RPO 目標介紹一些風險時問題。If there will be a requirement to maintain as much full fidelity search as possible at the DR site if there is failover, then periodic backup and restore processes could be performed. Possible scenarios are daily or weekly backup and restore procedures that are used together with read-only database crawling to maintain freshness as close as possible to 100 percent. The problem is when the search index is so large that it takes many hours to complete the restore, therefore introducing some risk to the RTO/RPO objectives.

這個合併的方法是清楚較複雜較簡單的備份與還原],但優點高於挑戰如果公司需要符合需求,才能實作這類的解決方案。This combined approach is clearly more complex than a simple backup and restore, but the benefits outweigh the challenges if the business needs meet the requirements to implement such a solution.

其他資源Additional resources

如需詳細資訊,建議您使用下列資源。For additional information, we recommend that you use the following resources.

除了本白皮書及這些文章中所提供的選項,有其他方法可用於備份及還原 SharePoint Server 搜尋服務應用程式。這些方法會更細緻粗略涉及單獨還原搜尋索引和搜尋資料庫放到新的伺服器陣列。我們尚未涵蓋下列步驟,但如果您考慮以指令碼執行的方法,我們建議在您開始透過檢閱下列資源。In addition to the options that are provided in these articles and in this paper, there are other methods that you can use to back up and restore the search service application in SharePoint Server. These methods are more fine grained and involve independently restoring the search indexes and search databases to a new farm. We haven't covered these steps, but if you are considering a scripted approach, we recommend that you start by reviewing the following resources.