SharePoint 搜索的灾难恢复最佳做法和策略

2023-03-08

适用于： no-img-13 2013 yes-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

了解如何在 SharePoint Server 场中实现搜索的最佳做法灾难恢复。

本文提供了最佳做法指导，可用于开发支持的灾难恢复 (DR) 策略，以便在 SharePoint Server 中搜索。早期版本的 SharePoint Server 中用于灾难恢复的许多方法都不为 SharePoint Server 提供相同级别的恢复。我们研究这些方法，并向您提供替代选项以及其需要被了解的优点和局限性。

简介

本文弥合了提供实现灾难恢复策略路线图的文档和提供特定命令来配置 SharePoint ServerSearch Service 应用程序 (SSA) 灾难恢复的文档之间的差距。我们介绍了几种典型的灾难恢复方案，并研究了每个方法的优点和限制。认为这些方案非常适合你的组织是不现实的，但你可以将它们用作满足组织特定要求的 DR 策略的指南。

SharePoint Server 的灾难恢复及其支持技术是一个复杂的主题，有许多信息来源专用于解释在发生激活灾难恢复计划的事件时所需的规划，以帮助确保实现业务目标。

作为最佳实践，我们建议您首先明确确定并量化组织的恢复时间目标 (RTO) 和恢复点目标 (RPO)。 RTO（是从灾难恢复所需的时间）和 RPO（以时间衡量的从相同灾难丢失的数据）是灾难恢复计划的关键指标。这两个业务驱动的指标为下列内容设置阶段：

备份和还原过程、媒体与存储
恢复到的位置
恢复解决方案的大小和复杂性

如果没有这些基准，就无法制定有效的恢复策略并评估技术解决方案。

重要

重点关注业务连续性和 IT 恢复要求，而不是创建 DR 策略的所需步骤。

尽管本文的范围是 SharePoint Server 搜索的灾难恢复，但我们建议你阅读为制定灾难恢复策略做准备时为 SharePoint Server 选择灾难恢复策略。

Search Service 应用程序体系结构

在查看开发灾难恢复策略的不同方法之前，下表介绍了 SharePoint Server 搜索中的组件及其如何为最终用户搜索体验做出贡献。下表中所述的搜索应用程序组件和数据库提供了灾难恢复策略的上下文。

搜索服务组件

组件或数据库	说明
索引组件	作为索引副本的逻辑表示形式。索引组件包括：索引分区您可以将索引划分为离散部分，每个保留索引的不同部分。搜索索引是所有索引分区的聚合。索引分区存储于磁盘上的文件集。索引副本每个索引分区保留一个或多个包含相同信息的索引副本。
查询处理组件	分析并处理搜索查询和结果。
管理组件	运行搜索所需的系统处理。每个 Search Service 应用程序拥有多个搜索管理组件，但每次只有一个处于活动状态。
爬网组件	对基于在爬网数据库中指定的内容进行爬网。
内容处理组件	在已爬网项目（如文档分析和属性映射）上执行各种处理。
分析处理组件	执行搜索分析和使用情况分析。
搜索管理数据库	存储搜索配置数据。每个 Search Service 应用程序只有一个搜索管理数据库。
爬网数据库	存储爬网历史记录和管理爬网操作。
链接数据库	存储由内容处理组件提取的信息。还存储点击率信息。
分析报告数据库	存储使用情况分析的结果。

如以下图表所示，有多种方法分发搜索组件以提供高度可用且可扩展性高的搜索拓扑。在此图表中，搜索组件部署在不同应用程序服务器上来提供冗余。此外，应用程序服务器部署在不同的虚拟化主机服务器，以便提供其他级别的容错能力和可伸缩性。

使用冗余组件搜索拓扑

有关在场服务器上分发搜索组件的详细信息，请参阅在 SharePoint Server 2016 中规划企业搜索体系结构和搜索 SharePoint Server 2016 中的搜索技术关系图。

要理解制定搜索灾难恢复策略的复杂性，您必须了解如何在 Search Service 应用程序索引和数据库内引用文档。正是这种引用系统目前无法使用任何形式的复制或日志传送技术在 SharePoint Server 场之间复制搜索索引。

Search Service 应用程序索引结构概述

由于 SharePoint Search Service 应用程序索引的结构非常复杂，在本文中将不做深入介绍。用简单的术语来说，索引由一系列数据可更新组的许多小部分组成。这些可更新组可被看作表中列的分区。默认情况下，搜索索引中有六个组。这些组如下所示：

主要：包含大量字段，完整文本存储于此。
ACL：涉及安全修整和快速安全爬网。
路径和标题：包含路径和标题。
建议：请注意此数据每天更新。
社会同事（人员）：涉及人员字段的单独更新组。
社会性标签：包含社会标签。

将每个更新组视为该组中字段的索引结构，其结构类似于SQL Server数据库。将更新组在存储级别分区到每个包含大量索引结构的文件中。其中的每个文件都包含整个索引的不同部分。通过为每个唯一文档使用标识符将内容分布于这些分区。此标识符为 DocID，这也是计数器。

创建新的搜索服务应用程序时，计数器从零开始。每次在爬网过程中发现新项时 ，DocID 都会递增 1，并且计数器会随着时间推移而增加，因为发现新项。计数器值永远不会递减。即使删除了文档，其相应的计数器值也永远不会重复使用。随着时间的推移，在库和列表中添加和删除文档或项目也意味着 DocID 在任何网站或库中不是连续的。因此，无法预测搜索料料库中任何文档的 DocID 。

这对任何搜索复制策略提出的挑战就是，实际上在任意两个服务器场中，DocID 值与服务器场中的任意文档相匹配，这一点无法保证或甚至是不可能的。由于 DocID 值不匹配，因此无法复制链接到 DocID 值的索引数据或分析数据。搜索结果无效，因为同一文档在每个场上都有不同的 DocID 。

当我们检查如何为搜索服务应用程序创建完全保真 DR 策略时，请务必注意以下两点：

识别存储配置和查询所需数据的组件和数据库，使用适当的方法正确地还原为目标 DR 服务器场。
目标 DR 服务器场与组件的正确数量适当按比例缩放以支持搜索服务的大小。

以下部分和实施部分中包含的技术详细信息将引用这两种活动。

常见灾难恢复技术

在 SharePoint 的早期版本中，有多种方法帮助确保您的故障转移 Search Service 应用程序填充了最新的索引和接近 100% 的搜索新鲜度。以下示例说明为灾难恢复所使用的典型方法。

对只读内容数据库进行爬网是一个选项，其中SQL Server日志传送方法用于在只读模式下维护附加到 DR 场的生产内容数据库的副本。这意味着 DR 服务器场上承载的 SSA 可以配置为通过 DR 服务器场上的只读 Web 应用程序对数据库进行爬网。任何配置更改都必须以两个服务器场的 SSA 级别实施，以帮助确保最终用户在故障转移事件中得到全保真体验。
通过双爬网选项，恢复服务器场对生产服务器场进行爬网，因此，会发现相同内容并对其进行索引。必须在生产和 DR 两个服务器场中实施对托管属性或已爬网文件类型、安装的 IFilter 等的配置更改，但是使用合适的更改控制策略可以对其进行轻松管理。

灾难恢复策略的其他选项并不提供相同级别的搜索索引新鲜度，但是如果索引新鲜度或恢复时间不是关键任务，则它们是有效选项。通常情况下，这些选项配置和实施起来更复杂。以下示例是典型的方法。

SSA 搜索管理数据库可进行独立备份。 SSA 搜索管理数据库使用传统的SQL Server备份方法独立备份，并在 DR 场上使用 Microsoft PowerShell 创建 SSA。这将还原搜索配置，但并不还原索引。需要完全爬网填充搜索索引并完成此恢复。
完整的 SSA 备份和还原。使用 Microsoft PowerShell 或使用 SharePoint 管理中心网站界面执行完整的 SSA 备份和还原。这将备份 SSA 数据库和搜索索引，这使它们能在 DR 服务器场上进行还原以填充该服务器场上的 SSA。

从 SharePoint Server 2013 开始，搜索体系结构的重大更改和配置元素的存储方式意味着我们必须以不同的方式思考搜索灾难恢复。以下部分说明了这些更改以及它们如何影响可用的灾难恢复选择。

对搜索体验的配置和功能更改

SharePoint Server 中的“网站管理”页面提供了支持搜索体验的灵活配置的选项。网站和网站集的新配置选项意味着网站管理员可以进行以前只能由服务器场或搜索管理员进行的搜索配置更改。下一个屏幕截图显示您可以配置搜索选项的两个位置 —“网站集管理”或“搜索”的下方。

在“网站设置”页上配置搜索

您可以从“网站集管理”或“搜索”下的列表，对搜索项（如查询规则或结果源）做出配置更改，该结果是相同的。然而，更改存储的位置直接影响灾难恢复。在网站集或 Web 应用程序中做出的所有更改，更改将只存储于 Search Service 应用程序 (SSA) 管理数据库中。除非此数据库从备份还原到灾难恢复场，否则配置更改在恢复的环境中不可用。

SharePoint Server 搜索中的另一项新功能是 ReIndex Now 功能，它允许网站集、Web 和列表级别的管理员在下一次爬网期间请求对容器重新编制索引。此功能完全在内容数据库内进行托管，因此，当在 DR 服务器场上运行下一个爬网时，在 DR 服务器场内管理员的此要求将触发生产服务器场中的相同事件。

搜索分析驱动的用户建议

在 SharePoint Server 搜索中，搜索和使用情况分析的处理由名为 Analytics 处理器的组件处理。此组件具有以下职责：

处理搜索分析信息的处理
处理使用情况分析
提供内容处理器用于支持搜索建议功能的相关信息
提供有关内容处理器用于提高相关性和排名计算的文档受欢迎程度（例如，页面访问率和点击率）的统计信息

若要详细了解各个分析过程，请参阅 SharePoint Server 中的分析处理概述，了解详细信息。

经处理的信息存储于搜索索引，并通过“报告和链接”数据库存储。因此，能够确保该经处理的信息在同步状态复制到 DR 服务器场的唯一方法是 Search Service 应用程序的完整备份和还原。

服务应用程序备份和恢复的改进

满足所有 DR 捕获配置和索引数据要求的方法是服务应用程序备份和还原。与 SharePoint 的早期版本相比，投入的这些操作显著减少了 RTO 和 RPO。支持对备份和还原过程中所用的线程数量的更改以及支持完整和差异备份和还原操作中的改进，是这一领域的所有关键收获。

当采用完整 Search Service 应用程序备份和还原方法作为 DR 策略时，整个 RPO 由两件事进行管理。自上一个完整服务应用程序备份以来的时间是 RPO，实际执行服务应用程序还原的时间为 RTO。随着 Search Service 应用程序中的已编制索引的内容增加，这两个时间也很可能增加，因此如果声明灾难，需要小心管理服务还原预期。建议您进行频繁的测试还原作为服务连续性管理演练的一部分，以确保仍能满足针对所需 RTO 和 RPO 的任何 SLA。下表总结了 Search Service 应用程序的备份和还原选项。

选项	限制
在 DR 服务器场中对只读数据库进行爬网。	没有将网站集或 Web 级别搜索配置更改复制到 DR 服务器场。
执行双爬网生产场。	没有将网站集或 Web 级别搜索配置更改复制到 DR 服务器场。不会将分析驱动的搜索索引更新复制到 DR 服务器场。
在 DR 服务器场还原搜索管理数据库并重新创建服务。	分析驱动的搜索索引更新不会还原到 DR 场。因为当创建服务应用程序时此索引将为空，且需要完全爬网。
执行完整的 SSA 备份和还原。	对于搜索索引保真没有限制，但还原大型服务应用程序可能需要数小时，并且在故障转移期间会影响 RTO。

恢复的支持技术

只有一个受支持的灾难恢复技术将提供全保真恢复，包括对生产服务器场内服务应用程序、网站集和 Web 级别的搜索索引和所有搜索配置项进行的所有分析处理改进。此方法要求 Search Service 应用程序的完全备份，紧随其后的是服务应用程序到 DR 服务器场的完全还原。将此索引和配置还原到进行备份的相同时间点，那么，如果是好几天前进行的备份，则需要新爬网对索引进行更新。本文将在稍后介绍这种方法的具体步骤。

它还支持对 Search Service 应用程序管理数据库进行备份，并在 DR 网站对其进行还原。通过使用 Microsoft PowerShell，管理员可以使用备份创建新的搜索服务应用程序。但是，这只会恢复搜索服务应用程序的实际配置以及 SharePoint 网站和 Web 中的任何自定义搜索设置，它不会恢复搜索索引。需要完全爬网来填充搜索集。此外，它无法恢复搜索索引的分析扩充，因为用于生成的信号仅驻留在生产场上。

如果在 DR 策略中必须包括搜索的主要目的在于帮助确保故障转移时搜索索引的新鲜度，则可能采用另一种方法。通过使用这两种方法中的一种，可以将索引维持在一个非常新鲜的状态，但也引入了复杂配置和若干限制。因为 DR 服务器场中的爬网程序必须配置为对生产服务器场爬网，或内容数据库必须以可读状态复制到 DR 服务器场以支持本地爬网，这就是复杂性的原因。这种方法的限制在于无法以任何形式将生产中 Search Service 应用程序的配置复制到 DR，来自于分析数据处理的搜索索引更新也缺失了。如果可以接收这些限制，那么在 DR 服务器场中有一个非常灵活的方法来帮助确保高索引新鲜度和搜索可用性。

最后的方法是实际将前面所述的两种技术并成单个策略，在故障转移提供高搜索索引新鲜度，但也增加了执行完整还原来将分析信息和搜索配置转换到 DR 服务器场的可能性。

在这种情况下，可能会使用完全备份和远程或本地爬网，如果需要的话，还可以使用还原过程。开始完全还原过程的典型原因在于 DR 网站的故障转移是否远超过正常服务的临时中断，在约定的时间段内不可能将故障恢复到生产。在这种情况下，可能调用还原过程帮助确保 DR 网站中的全保真搜索体验可用。然后启动新爬网以将搜索索引提高到完全新鲜度。

当还原使用覆盖选项的 Search Service 应用程序时，需要考虑一些影响。在还原过程中，服务应用程序将处于脱机状态，这意味着将不处理更新或查询。对于搜索不是关键功能的业务，这可能不是个问题。但如果在还原过程中，搜索查询功能必须可用，那么就应该考虑另一个选项。在还原过程中，此替代选项始终新建 Search Service 应用程序，完成还原后，运行新爬网以将索引新鲜度更新到最新。在完成爬网后，将服务应用程序关联切换到新服务应用程序，并进行不间断地工作。然后删除较旧的服务应用程序。最大的挑战是，其中的一个容量基本上需要双倍的索引和数据库空间平行地承载两个服务应用程序。搜索服务的重要程度将决定这是否是业务必须适应的内容。

考虑到所有这些事情，值得研究 Search Service 应用程序的预期 RPO 和 RTO 要求。目前，SharePoint 支持搜索服务应用程序的 RPO 和 RTO 为期一周。如果您进行深究，这意味着在执行还原时，配置项、分析处理信息和搜索新鲜度最多还有将一星期过期。再重复一遍，根据环境中的预期变化率和搜索安装程序的重要程度，每天运行或甚至是几小时就进行备份，以帮助确保为业务实现最佳 RPO 和 RTO，这是比较稳妥的做法。对于维护如您进行内容备份一样多的多个备份副本是没有要求的，因为搜索内容是非常流畅的并具有暂时性，所以最多只保留一个或两个完整备份。

服务应用程序备份和恢复

以下信息简要总结了搜索备份和还原文章中包含的要点：

必须采取搜索服务备份的频率受很多因素的影响，但关键驱动因素主要是业务所需的 RPO 。随着搜索索引越来越大，备份和还原服务应用程序所需的时间也会越来越长。一次只能执行一个搜索备份，并且完成备份的时间是可以实现的最小 RPO。因此，在 DR 服务器场上完成还原的持续时间是可以实现的最小 RTO，如备份时间一样，还原时间也会随着时间推移而延长。如果备份或还原时间开始侵占搜索 RPO 和 RTO 要求的服务级别协议 (SLA)，那么正如稍后所述的那样，业务必须以保真度较小的方法对接下来做出更灵活的决定，或调整 SLA 满足可实现的目标。

备份 Search Service 应用程序

若要备份搜索服务应用程序，可以使用 Microsoft PowerShell 或管理中心用户界面。需要的 PowerShell cmdlet 如下所示：

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 Application 的搜索服务应用程序，并将备份文件存储在位置 \server\searchbackup 中。

注意

BackupMethod 开关仅适用于搜索数据库。在所有情况下，完全备份搜索索引，无需考虑选择的选项。

可以在“准备情况”部分的“备份和还原作业状态”页顶部查看所有备份作业的常规状态。可以在该页下部的“备份”部分查看当前备份作业的状态。 The status page updates every 30 seconds automatically. You can manually update the status details by clicking Refresh. 备份和恢复是定时服务作业。 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. 还可以在为存储备份文件指定的 UNC 路径的 Spbackup.log 文件中找到更多详细信息。

还原 Search Service 应用程序

若要还原 SharePoint Server 搜索服务应用程序，备份必须已成功完成，如果频繁执行备份，则需要要还原的特定备份的 ID。有多种方法可以轻松地获取此 ID。最简单的方法是打开执行了备份的生产服务器场上的“备份和还原历史记录”页，输入“备份目录位置”。这将提供备份和还原清单文件 (psbrtoc.xml) 中所有项的列表。在以下屏幕截图中，可以轻松查看 {149fc816-8927-4a32-9437-6e05c2869ab7} 的备份 ID。

SharePoint 备份和还原历史记录页

使用备份和还原历史记录页的另一种方法是直接打开备份和还原清单文件，并为所需项对其进行检查。由于文件的大小将随着进行每个备份和还原而增大，检查该文件可能不是最佳方法，尤其是如果进行了高频率的备份和还原操作。

以下示例说明了 spbrtoc.xml 中的典型项，并且您可以轻松地识别备份 ID。

<?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 cmdlet，该 cmdlet 还可以提供 与spbrtoc.xml 文件相同的信息。

接下来的两个示例演示如何使用 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"

注意

如果没有提供备份 ID，则使用目录中最新的可用备份。

RestoreMethod你使用的确定进程在运行 Restore-SPFarm cmdlet 后将如何流动。

如果选择了“新建”选项，则提示运行此 cmdlet 的管理员在备份中为每个组件和数据库的新服务器场提供地址。如果 DR 服务器场中的服务器场拓扑和命名约定与生产服务器场中的不完全匹配，对于这种经常遇到的情况，此方法特别有用。如果将 Search Service 应用程序存储在使用匹配名称和服务器拓扑构建的服务器场中，则可以使用“覆盖”选项。通常，当还原到作为备份源的相同服务器场时，才使用此选项。

注意

要使用“覆盖”选项，则必须至少有一个已经使用过“新建”选项的还原。如果不适用，则在 DR 服务器场中使用相同配置和命名的现有 Search Service 应用程序必须处于可用状态。

当还原 Search Service 应用程序时，在还原期间和之后，它将自动暂停。若要在还原完成后恢复服务应用程序，请使用以下 PowerShell 命令。

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

还需要管理员特别注意的是，用于还原每个分区包含多个副本的 Search Service 应用程序的过程。还原过程将只还原到每个分区内的一个副本，背景任务会为每个分区将分区信息复制到所有其他副本。在此过程中，搜索索引和查询处于联机状态，但 Search Service 应用程序的管理页面可能按降级显示副本，直到完成此操作。

组合灾难恢复方法

正如前面所提到的，随着服务应用程序备份和还原成为维护全保真 DR 解决方案的唯一受支持方法，要为搜索实现较低的 RPO/RTO，变得特别具有挑战性。随着时间的推移，索引数据集越大，备份和还原的时间也会越长。这可能导致比需要的 RPO 和 RTO 花费更长时间。

可以用来克服实现较低 RPO/RTO 这一挑战的方法是采用双管齐下的解决方法。下面的列表显示了此解决方案：

使用只读内容数据库的爬网，或生产网站的双爬网来在 DR 服务器场中维护可接受级别的搜索索引新鲜度。
采用 Search Service 应用程序备份，定期将它们还原到 DR 服务器场，或使它们处于可用状态以防主网站不可恢复。

如果对 DR 场中的只读数据库进行爬网是首选选择，则必须考虑生产场中的更改不会复制到恢复场这一事实。正如我们所提及的，这包括对索引的搜索服务分析更新和对配置项的更新，如结果源、查询规则和架构修改。如果采用组合方法，则了解所有影响并制定适当的策略非常重要。目前，没有受支持的方法能避免分析更新的丢失，但可以采取措施来解决对配置更改的更新。您可以尝试与以下示例类似的操作。

确保所有自定义结果源、查询规则和搜索架构更改（被视为业务关键）都是在管理中心的搜索服务应用程序级别进行的，而不是在网站集或子网站中进行。例如，考虑到企业的 Intranet 门户依赖于特定查询规则管理主页上的内容。将在生产服务器场上创建这些规则，并手动复制到 DR 服务器场以帮助确保此配置处于可用状态。同样地，必须在两个服务器场的服务应用程序级别实施已爬网属性到托管属性的自定义映射。

可以捕获网站级和 Web 级的搜索配置项，并通过使用 PowerShell 将其导出到 XML 文件。例如，下一个 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 配置数据库中的网站地图表将不会更新为在生产服务器场中注册新建网站。这意味着在完全或增量爬网过程中，将不会对这些网站及其中的内容进行索引。若要克服此问题，请务必定期运行以下 PowerShell 命令，该命令将刷新给定 Web 应用程序上所有内容数据库的 DR 场上的站点映射。

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

通过定期爬网只读数据库和更新网站地图，在 DR 服务器场中可以保持较高级别的索引新鲜度。组合方法的第二个阶段是如何处理搜索服务应用程序备份。这里有两个实际选择，在下面的列表中显示，但请注意，选定的选择将取决于业务需求。

如果能成功执行此业务，满足其基本功能，而无需进行全保真搜索（即，搜索管理服务应用程序中的核心配置元素和维持较高搜索索引新鲜度的能力，使业务在 DR 网站中正常运行），那么从不将服务应用程序还原到 DR。如果越来越明确主网站在很长时间将不可用，那么可能只需要还原 Search Service 应用程序。这意味着不可能将故障恢复到主网站，因此，需要完全还原 Search Service 应用程序来实现所有依赖于搜索重新联机的业务功能。可以选择特定时间段来触发此还原。
如果在有故障转移的情况下，需要尽可能地在 DR 网站维持全保真搜索，那么可以执行定期备份和还原过程。可能出现的情况是，将每天或每周备份和还原与只读数据库爬网一起使用的过程，以尽可能维护接近于 100% 的新鲜度。问题是，当搜索索引太大时，则需要多个小时才能完成还原，因此将一些风险引入到了 RTO/RPO 目标中。

这种组合方法显然比简单的备份和还原复杂得多，但如果业务需求满足实现此类解决方案的要求，其好处将大于挑战。

其他资源

有关其他信息，建议使用以下资源。

除了这些文章和本文中提供的选项外，还可以使用其他方法来备份和还原 SharePoint Server 中的搜索服务应用程序。这些方法更加细化，涉及独立地将搜索索引和搜索数据库还原到新服务器场中的过程。我们尚未介绍这些步骤，但如果你正在考虑使用脚本化方法，我们建议你首先查看以下资源。