随着 ArcGIS Enterprise 部署复杂性的增加，在灾难恢复方面应考虑其他因素。 这些考虑因素需要深入了解构成部署架构的不同系统。 与许多技术方案相似，不存在万能的方法来备份部署中的核心和依赖系统。
以下提供了在灾难恢复事件期间提高恢复成功率的框架。 采用这些做法，组织可以在其 ArcGIS Enterprise 部署环境中将标准操作程序定义为业务连续性/灾难恢复 (BC/DR) 计划的一部分，以应对灾难。
创建备份的最佳做法
查看以下最佳实践，以创建您的 ArcGIS Enterprise 组织和所有引用的数据源的备份。
备份 ArcGIS Enterprise
ArcGIS Enterprise 组织由 Portal for ArcGIS 站点、所有联合 ArcGIS Server 站点及其关联数据，以及 ArcGIS Data Store 中包含的数据组成。 可以使用包含的 Web GIS 灾难恢复 (WebGISDR) 工具或使用第三方工具进行基于计算机和基于图像的备份来备份这些组件。
WebGISDR 工具是 Portal for ArcGIS 随附的命令行实用程序，用于备份组织的内容和数据、联合 ArcGIS Server 站点信息以及包含在关系和切片缓存数据存储中的数据。 此工具对于维护基本部署组件以及任何其他联合站点的一致性特别有用，但是它需要功能部署来执行恢复。
在 WebGISDR 备份过程之外应考虑以下事项：
- 联合 ArcGIS Mission Server 或 ArcGIS Notebook Server 站点 - 如果您有其中任何一种，请按照 ArcGIS Mission Server 文档和 ArcGIS Notebook Server 文档中的说明创建备份。
- 时空大数据存储和图形存储备份 - 如果您的托管服务器上注册了一个时空大数据存储或图形存储（或两者），可使用 ArcGIS Data Store backupdatastore 实用程序创建备份。
- ArcGIS GeoEvent Server 站点配置 - 使用备份配置文件管理 ArcGIS GeoEvent Server 配置的备份。
对象存储用于 11.0 的临时要素图层响应缓存，因此在恢复方案的情况下不需要保留数据。
大多数虚拟化平台允许对正在运行的虚拟机进行快照，从而实现低恢复时间目标。 虽然这些非常有用，但它们并不作为更大型 BC/DR 计划一部分的持久备份。
在维护窗口之前或期间进行备份时，快照提供的低恢复时间目标可作为使用这些工具（如果可用）的动机。 在进行第三方备份时，由于 Portal for ArcGIS 和 ArcGIS Data Store 的基础数据层组件均未与这些方法集成，因此存在与对正在运行的数据库进行实时备份相关的一定程度的风险。 为了最大限度地降低这种风险，应在停止运行 ArcGIS Enterprise 组件的服务后进行快照和基于图像的备份。
对于使用文件共享来托管共享门户内容目录或 ArcGIS Server 站点的配置存储和根目录的架构，在使用第三方备份工具（如虚拟机快照或基于图像的备份）时，考虑这些位置的备份的一致性非常重要。 例如，如果管理员通过恢复快照在 Portal for ArcGIS 升级失败后回滚，则内容目录可能已被升级过程更改，并且将与已恢复实例的数据库中包含的信息不一致。 要在使用第三方工具时将这些影响降至最低，应在组织内未发布或编辑任何内容的中断窗口期间进行备份。 这包括 ArcGIS Enterprise 组件以及任何关联的文件共享。
ArcGIS Data Store 可以与其他组件分开备份，以最大限度地降低该组件发生故障时的数据丢失风险。 可能会在 WebGISDR 实用程序和其他备份工具的计划之外运行关系和切片缓存数据存储的计划备份。
备份引用的数据源
ArcGIS Server 可以提供来自许多来源的内容，包括企业级地理数据库、注册文件共享和云存储。 这些外部数据源应包含在部署的灾难恢复计划中。 建议您按照供应商的说明进行备份或将数据复制到另一个位置。
应使用供应商提供的工具，根据每个组织的恢复点目标，对包含由引用服务提供的数据的企业级地理数据库进行备份。 由于此数据由 ArcGIS Server 服务引用，因此如果数据库恢复独立于包含已发布服务的站点执行，则已发布服务的一致性可能会与后端数据库表不同步。 因此，调整 ArcGIS Enterprise 部署中所有组件的备份计划非常重要。
网络文件共享可以使用基于图像或基于文件系统的备份工具来打包数据，然后传输到位于部署故障域之外的持久存储解决方案中。
云存储应备份或复制到另一个区域，以获得额外的可恢复性和持久性。 复制的存储也可以使用存档或冷存储来部署，以降低总成本。
备份时间
备份频率取决于几个因素，其中最重要的是完成备份需要的时间。 由于备份过程会影响系统资源利用率，因此通常会在主要工作时间之外计划执行备份。 对于不同的备份类型，系统备份的频率可能因 ArcGIS Enterprise 部署有所不同。
例如，生产企业级地理数据库可能每 15 分钟增量备份一次，以实现低恢复点目标。 最重要的数据应存储在此数据库实例中，以减少潜在的数据丢失量。 对于具有许多引用服务和静态内容的 ArcGIS Enterprise 部署，备份频率可以是每天或每周，而对于使用大量托管要素服务和频繁创建 web 地图和应用程序的部署，应选择更短的备份间隔时间。
验证备份
应监控备份是否成功完成，并在发生故障时提醒管理员。 对于 WebGISDR 工具，运行脚本的退出代码可以用来衡量备份是否成功完成。 零表示备份成功，而任何非零代码均表示失败。 可以集成多种警报工具，以便向负责备份完整性的团队发送电子邮件或 SMS 通知。 许多第三方备份工具可以提供类似功能，或者可以与其他服务集成以提供警报。
验证组织的 BC/DR 计划的另一个重要方面是以半定期的节奏运行恢复练习。 这有助于管理员确保在发生灾难的情况下，可以准备好从功能备份进行恢复并验证以下描述的恢复计划。
备份文件应保留多久
确定保留备份文件的时间取决于您拥有的可用磁盘空间量以及恢复选项所需的灵活性。 如果您不需要恢复到上一次完整备份前的某个时间，则可以保留上一次完整备份以及自那时起创建的增量备份。
使用 WebGISDR 工具创建的增量备份可累积；可将最近的增量备份应用到上一次完整备份。 因此，您至少需要保留上一次完整备份和自该完整备份起创建的最近增量备份。
您还可以将几组原有备份移动至其他位置，例如存储介质。 这样，如果您发现在上一次完整备份前删除了关键数据和服务，您仍可以使用这些文件。
注：
创建备份时，WebGISDR 实用程序会记录 ArcGIS Enterprise 组件的软件版本。 您要恢复到的部署的版本必须与您创建备份时的版本相同。 或者，您必须恢复至相同类型的操作系统。 例如，您无法在 Linux 上创建 ArcGIS Enterprise 部署的备份并将其恢复至 Windows 计算机。恢复组织的最佳做法
查看以下最佳做法，以使用您创建的备份还原 ArcGIS Enterprise 组织。
恢复内容
当管理员可以使用多种备份类型时，相对于恢复整个部署，可以通过更精细的方式恢复组件。 如果地图或影像服务的缓存被删除，则仅需从备份中恢复这些文件。 同样，如果从企业级地理数据库中意外删除了某个表，则可以恢复该数据库而不会影响其他组件。
如果对托管要素图层进行了错误编辑并且需要回滚数据，管理员可以选择仅恢复关系数据存储而不恢复整个 ArcGIS Enterprise 部署。 这减少了恢复对数据库中存储的其他数据的影响，但如果在此期间创建了托管服务，则可能导致 ArcGIS Server 站点与恢复的数据库表不一致，并需要手动清理和重新发布受影响的服务。
在其他情况下，可能会出现重大中断，例如需要恢复整个 ArcGIS Enterprise 部署以及任何外部数据源的数据中心或云区域。 这将是最极端的例子，需要进行充分的规划以确保恢复环境的完整功能。
恢复方法
当 ArcGIS Enterprise 部署遇到大范围中断时，根据可用的备份类型，可以从多个恢复选项中进行选择。 使用 WebGISDR 实用程序复制到附近站点是减少恢复部署时间的最重要方法，同时拥有一个可用于启动和恢复的冷备用站点可以促进恢复练习并减少总恢复时间。
在决定恢复路径时，应首先尝试具有最短恢复点和时间目标的选项。 这将允许以最快的速度反馈恢复的成功程度。 对于熟悉备份策略且过去定期测试恢复的管理员，也可以缩短在灾难情况下恢复所需的时间。
由于 ArcGIS Enterprise 在内部和外部组件中有多个层，因此这些组件的恢复顺序会影响恢复后部署的稳定性。 首先，应确保所有引用的数据源均可用，并且应在恢复 ArcGIS Enterprise 计算机和组件之前验证它们是否可以从 ArcGIS Enterprise 环境访问，包括数据库实例和外部文件共享。
周围的依赖关系已就绪，ArcGIS Enterprise 部署应恢复到一致状态。 这样可以避免托管服务器站点可能已发布托管要素服务但关系数据存储缺少依赖数据表的情况，或者组织可能具有不再存在于联合站点中的服务项目的情况。
恢复后验证
恢复操作完成后，应对业务关键数据和 ArcGIS Enterprise 部署的广泛功能执行验证。 要执行此操作，可以为业务中心和部门创建清单以验证其最重要的内容，或通过自动编写脚本来实现。 与手动验证项目和服务相比，使用自动化脚本进行此验证可以提高在更短的时间内完成恢复的成功率。
自动化备份和恢复操作
建议您定期创建备份以防止重大数据丢失并减少停机时间。 创建备份的频率将取决于您组织的恢复点目标 (RPO)，该目标定义了可接受的数据丢失量。 例如，如果组织不能容忍超过 12 小时的数据丢失，则需定义一个以短于 12 小时的节奏创建备份的计划。
可以使用 CronJob 或任何其他计划软件在 Linux 中自动创建和恢复备份。 请注意，组织中的数据量也会影响创建备份的频率以及恢复备份的速度。 您可以在设置计划任务之前测试所需时间，以确保在进行下一次尝试之前完成备份或恢复操作。
此外，应确定备份或恢复操作是否成功。 WebGISDR 工具支持将操作结果记录为 JSON 的输出文件，可以解析该文件以确定备份是否位于、是否存在任何组件失败以及每个组件所花费的时间。 该文件可以集成到您的备份和恢复逻辑中，以通知管理员任何故障或操作项。