对于具有可用性预期、要求或承诺的企业系统，明确定义、可操作且经过充分测试的备份和灾难恢复 (DR) 方法至关重要。 要设计备份策略或灾难恢复方法，组织需要首先了解其系统的范围和依赖关系，然后再仔细建立恢复目标，了解可用的 IT 资源，并考虑恢复流程，从触发备份或还原到员工支持的可行性和用户影响。
备份的重要性或作用主要与系统的业务关键性、它支持的工作流及其中存储的数据类别有关。 某些系统（如开发服务器或小型团队使用的系统）可能不需要备份策略，而其他系统可能主要使用备份和 DR 方法来测试流程，并通知它们成功应用于生产系统。
本主题概述了备份和灾难恢复过程，包括对 ArcGIS 软件组件的影响以及支持各种 ArcGIS 应用程序的备份或灾难恢复方法的可用选项。
系统、数据或硬件组件的备份过程对 IT 系统一直很重要。 虽然从历史上看，备份通常是在存储级别实施的，但云服务的激增引入了几个与备份相关的新选项，主要是需要备份云托管数据和 SaaS 系统，以及可用于在数据级别存储备份的新位置和提供商。
备份的注意事项包括仔细定义以下内容：
此外，用于从备份恢复系统的方法以及它对用户的影响也很重要。
根据历史记录，只有最关键的业务系统或数据得到可靠备份，因此备份范围集中在最重要的系统、服务器或数据库上。 随着现代存储成本明显低于过去，备份范围已显著扩大，趋向于整个系统备份，而不是选择性地备份一个应用程序组件或数据类型。
用于创建备份的方法可能千差万别，从特定于应用程序的备份格式（如二进制数据库转储到虚拟机映像），到配置备份或复合备份（可能将应用程序的状态与数据和应用程序代码本身相结合）。 用于创建备份的方法可能会对创建备份所需的时间、运行频率以及备份的还原方式产生重大影响。 备份的创建方式以及捕获运行系统状态的程度也可能有所不同。 在 ArcGIS 系统中，需要考虑三种主要类型的备份：
备份系统的频率和进行这些备份的启动时间也是需要考虑重要的因素。 备份过于频繁可能会导致成本过高或增加系统中断次数，而备份不太频繁可能意味着在中断事件和最近备份之间丢失不可接受的数据。 大多数备份旨在避免在某种程度上造成用户中断，但备份的时间可能会影响备份中捕获的数据和工作流。 通常，备份是在系统的“非工作时间”（如果存在）进行的，以捕获前一天的大部分数据和信息，而不是在工作日的中间进行备份，此时备份可能只捕获正在积极处理的较长进程或较大数据集的一部分。
备份进程存在的原因似乎不言而喻，例如，为了还原系统的状态，但备份还用于各种存在细微差别的用例。 某些备份与系统升级相关联，因此，如果发现升级问题，可以将系统恢复到已知状态。 同样的考虑因素推动了与中断性系统更改（如移除服务器或添加新组件）相关的备份进程。 有些备份仅针对最坏情况创建，以在灾难发生时用于从灾难中恢复。 其他备份用于对环境状态进行快照复制，并创建一个新的较低环境作为副本，或者将另一个方向的内容从较低环境提升到较高的生产级别系统。
灾难恢复或 DR 是一个通常与备份和还原过程密切相关的主题，但它们不是同义词。 DR 特指“灾难发生后我们该怎么做才能恢复”、恢复所需的过程，以及“灾难”和“恢复”在组织特定上下文中的含义定义。 灾难通常是指重大的 IT 系统中断，无论是由硬件、环境还是用户配置问题引起的，这些中断导致系统的正常运行时间、可用性或功能出现重大中断。
要建立 DR 流程，前期步骤之一是构建需要灾难恢复流程的“灾难”。 必须仔细定义这一点，因为如果定义过于敏感（例如对主系统的一个请求失败），可能会导致频繁的 DR 故障转移操作，但等到中断持续时间超过 4 小时可能过于宽松，并导致大量用户中断。 最后，在定义“灾难的构成因素”以让系统采取措施来启动恢复或故障转移过程中，涉及自动执行和人工管理的决策，并且将依赖于组织对可用性、关键性和正常运行时间等概念的定义。 DR“启动程序”的常见示例包括无法访问数据中心、存储故障、虚拟机监听器故障、DNS 中断或网络连接问题，甚至数据损坏或系统勒索软件攻击。
DR 流程中的另一个关键定义是组织的恢复点目标 (RPO) 和恢复时间目标 (RTO)。 RPO 相当于_我们在灾难场景中丢失的数据量_，指的是创建的备份类型以及数据或配置的备份频率。 如果 RPO 等于 4 小时，意味着在最坏的情况下，当发生 DR 级别中断时，会丢失 4 个小时的数据或工作，并且组织可以接受在 DR 过程中丢失这 4 小时的数据或输入。 虽然低 RPO 似乎是一种显而易见的方法，但在大多数系统中，备份的复杂性和中断用户的可能性意味着低 RPO 会造成资源、存储或用户影响方面的成本过高。
RTO 表示_我们再次备份所需的时间_，指的是将备份还原到 DR 系统、从头开始创建新系统或自动部署资源以从灾难中恢复所花费的时间。 RTO 通常低于 RPO，因为故障转移系统或故障转移系统的组件可能已经存在，并且要切换到该系统，只需要更改 DNS 或网络。 必须定义和实现切合实际的 RPO 和 RTO，这对于构建 DR 策略以及获得利益相关方同意实施此策略的成本和工作流影响非常重要。
灾难场景的一种常见响应方法是将流量切换到故障转移系统，该系统存在的目的是在主系统识别或遇到问题时接收流量。 要实施此方法，需要满足几个重要要求，这些要求对成本和工作流程会造成影响：
另一种 DR 方法是使用备份来重建系统，这可能会导致 RTO 更长，但会降低持续成本，因为不需要始终维护故障转移系统。 这可能涉及进行 VM 备份或应用程序级备份，然后重建系统，通过基础设施即代码和软件部署自动化自动重建，或者由经验丰富的团队手动重建，在恢复备份之前，流量将切换回系统，用户可以恢复系统中的工作负载。
DR 进程也可能具有更广泛的影响或方法，而不是特定于使用 ArcGIS 构建的企业系统。 例如，整个数据中心可能具有一个 DR 策略，该策略使用 VM 复制在单独的数据中心中维护一组 VM，当发现存储或虚拟机监听器组件发生中断时，所有用户都可能切换到访问辅助数据中心。
DR 进程还需要考虑恢复后的情况。 如果存在主系统或数据中心，并且 DR 事件导致故障转移到辅助系统，则在解决中断后将流量切换回主系统是否是标准方法？ 或者，备用系统现在是否成为主系统，而原始系统被设置为备用系统以支持下一个 DR 情况？ 这两种情况都有价值，定义事件解决后的情况是完成 DR 策略和方法的重要组成部分。
在 ArcGIS 系统中，有几种方法可以启动备份过程，这些方法内置于 ArcGIS 软件中。 单组件备份，仅备份单个应用程序的内容和状态，可用于包括 Portal for ArcGIS、ArcGIS Server 和 ArcGIS Data Store 在内的 ArcGIS Enterprise 组件。 这些组件特定备份并非主要用于 DR 目的，而是用于就地备份和还原 - 对于 DR 目的，建议使用 WebGISDR 工具。 每个组件都有不同的备份方法，包括：
多个 ArcGIS Server 角色通常无状态，其中所有相关配置均存储为门户项目，通常不需要进行备份。 这包括 Notebook Server、Business Analyst Enterprise Server (GeoEnrichment Server) 和 Raster Analytics Server。 通常，所有这些组件都可以从空白计算机或已安装的映像重新创建，而不是还原特定部署，因为内容存储在 ArcGIS Enterprise 中。 除此之外，唯一需要考虑的是已将自定义代码或第三方库部署到系统以启用基于 Python 的工作流或其他流程的情况。
除了特定于组件的备份功能外，ArcGIS Enterprise 还具有一个名为 Web GIS 灾难恢复工具（简称 WebGISDR）的多组件备份工具，该工具可以同时备份多个不同 ArcGIS Enterprise 组件的状态。
ArcGIS Enterprise 文档中对 WebGISDR 工具进行了全面介绍，但需要注意的是，此工具优先考虑集体应用程序的一致性和状态，而不是备份速度或进程的灵活性。 这意味着在实践中，该工具会尝试准确捕获运行请求时的系统状态。 如果在备份时发布了更多内容或数据，则这些内容或数据将不会出现在任何备份文件中，并且无法还原到故障转移系统。 这种关注与关注 RPO 而不是 RTO 同义，优先考虑系统的功能完整性，而不是系统的恢复速度（可能导致配置错误或数据错误）。
除了特定于 ArcGIS 应用程序的备份之外，组织可能会建议或首选各种其他方法，这些方法可能是特定组件或基础架构提供商的原生方法。 这些方法可能适用于 ArcGIS 备份或灾难恢复进程，但应仔细评估和考虑，因为使用这些方法也可能中断系统。
例如，VM 快照是备份系统的一种常见方法，但如果快照的方法包括突然重启计算机或仅捕获数据状态，则可能会带来复杂的挑战，因为可能无法捕获或部分捕获进程内的操作或配置，这可能会导致在还原或恢复时出现意外和损坏状态。
基于 VM 的备份策略有时会在两个数据源之间移动 VM 资源，以防中断。 在这些情况下，请确保 ArcGIS Server 和 ArcGIS Pro 主机正在访问其自己的数据中心中的数据库，而不是向原始数据中心发出请求，因为这将引起延迟，从而对用户体验产生负面影响。
基于云的备份和 DR 工具（例如 Microsoft Azure Site Recovery）在经过仔细规划后可以与 ArcGIS Enterprise 系统兼容，以便在执行站点恢复操作时保持 DNS 解析、数据库连接和客户端与系统的连接。 这些备份方法在相对较低的虚拟机访问级别上运行，因此它们无法保证应用程序一致性。 这意味着，虽然恢复系统通常会成功恢复和运行，但在某些情况下可能会出现应用程序级别不一致，即正在进行的发布进程或在备份过程中对要素服务进行编辑。 可通过一些方法对此进行规划，例如在非高峰时段拍摄 VM 快照，但通常“规划、测试和仔细考虑影响”的指导适用于这些外部工具方法。
构建 ArcGIS 使用的关系数据库（作为企业级地理数据库或查询图层的源）的数据库提供商会提供专用数据库特定备份选项，这些选项通常可以创建数据库内容和配置的基于文件的备份，以在需要时还原到新系统或部署。
ArcGIS Online 作为 SaaS 产品和系统，需要从备份和恢复的角度以不同的方式处理。 作为系统稳定性的一部分，Esri 无需用户输入即可处理硬件和系统级别中断的备份和恢复要求，ArcGIS Online 的服务级别协议反映了这一承诺。 ArcGIS Online 目前没有为用户提供创建组织范围的备份或内容备份的方法，组织需要通过各种模式为 ArcGIS Online 中的内容或配置定义专用的附加备份策略，包括：
请注意，Esri 合作伙伴还创建了备份解决方案，可通过 ArcGIS Marketplace 查看或购买这些解决方案。
ArcGIS Online 最近引入了回收站功能，该功能将在永久删除之前将已删除内容存储 14 天（默认设置）。 通过简单的工作流即可将回收站中的内容恢复到其以前的状态和位置。 这将有助于防止删除相关的内容，该内容与其他内容相互链接但未明确标识为依赖或依赖该其他内容。