你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

将云和本地工作负载备份到云

  • 项目

Azure 备份通过一种简单、安全、经济高效且不需要任何基础结构的解决方案来全面保护 Azure 中的数据资产。 它是 Azure 的内置数据保护解决方案，适用于各种工作负载。 它可帮助保护在云中运行的任务关键型工作负载，确保你的备份始终可用并在整个备份资产中以大规模的方式进行管理。

目标受众

本文的主要目标受众是 IT 和应用程序管理员，以及大中型组织的实施者，他们想要了解 Azure 内置数据保护技术与 Azure 备份的功能，以及如何有效实施用于保护部署的解决方案。 本文假设你熟悉核心 Azure 技术、数据保护概念，并具有使用备份解决方案的经验。 本文中介绍的指南可让你更轻松地在 Azure 上使用已建立的模式设计备份解决方案，并避免出现已知问题。

本文的组织方式

尽管在 Azure 上开始保护基础结构和应用程序十分容易，但当你确保基础 Azure 资源已经过正确设置并以最佳方式使用时，你可以加快实现价值的速度。 本文简要概述了用于以最佳方式配置 Azure 备份部署的设计注意事项和指南。 它剖析了核心组件（例如，恢复服务保管库、备份策略）和概念（例如治理），说明了如何理解它们以及其功能，并提供了详细产品文档的链接来帮助读者理解。

入门

订阅设计策略

除了有一个便于在云采用之旅中导航的清晰路线图之外，还必须规划云部署的订阅设计和帐户结构，以便于组织的所有权、计费和管理能力相匹配。 由于保管库的范围限定为订阅，因此订阅设计将极大地影响保管库设计。 详细了解不同的订阅设计策略和关于何时使用它们的指南。

阐述备份要求

若要开始使用 Azure 备份，请规划备份需求。 下面是在制定完美的备份策略时应该自问的一些问题。

要保护哪种工作负载类型？

若要设计保管库，请确定是否需要集中/分散式的操作模式。

所需的备份粒度是什么？

确定备份应该是应用程序一致性、崩溃一致性备份还是日志备份。

是否要满足任何合规要求？

确定是否需要强制执行安全标准和隔离访问边界。

所需的 RPO、RTO 是多少？

确定备份频率和还原速度。

是否存在任何数据驻留限制？

确定所需数据持久性的存储冗余。

要将备份数据保留多久？

确定备份的数据在存储中保留的持续时间。

体系结构

显示 Azure 备份体系结构的示意图。

工作负载

Azure 备份为各种工作负载（本地和云）启用数据保护。 它是 Azure 中安全可靠的内置数据保护机制。 它可以跨多个工作负载无缝缩放其保护，而无需你支付任何管理开销。 还有多个自动化通道可用于启用此功能（通过 PowerShell、CLI、Azure 资源管理器模板和 REST API）。

  • 可缩放、持久且安全的存储：Azure 备份使用带有内置安全性和高可用性功能的可靠 Blob 存储。 你可以选择将 LRS、GRS 或 RA-GRS 存储用于备份数据。

  • 原生工作负载集成：Azure 备份提供与 Azure 工作负载（VM、SAP HANA、Azure VM 中的 SQL，甚至 Azure 文件存储）的原生集成，无需你管理自动化或基础结构来部署代理、编写新脚本或预配存储。

详细了解支持的工作负载。

数据平面

  • 自动化存储管理：Azure 备份会自动预配和管理备份数据的存储帐户，以确保存储帐户随着备份数据的增长而扩展。

  • 恶意删除保护：通过备份的软删除来防止有人意外或恶意尝试删除备份。 已删除的备份数据将免费存储 14 天，并允许其从该状态恢复。

  • 安全的加密备份：Azure 备份利用 Azure 平台的内置安全功能（例如 Azure 基于角色的访问控制 (Azure RBAC) 和加密），确保备份数据以安全的方式存储。

  • 备份数据生命周期管理：Azure 备份会自动清理较旧的备份数据，以遵守保留策略。 你还可以将操作存储中的数据分层存储到保管库存储中。

  • 受保护的关键操作：使用 Azure 备份的多用户授权 (MUA)，可为针对恢复服务保管库的关键操作额外增加一层保护。

管理平面

  • 访问控制：保管库（恢复服务和备份保管库）提供管理功能，可通过 Azure 门户、备份中心、保管库仪表板、SDK、CLI 进行访问，甚至还可以通过 REST API 进行访问。 它也是 Azure 基于角色的访问控制 (Azure RBAC) 边界，让你可以选择仅限经过授权的管理员访问备份。

  • 策略管理：每个保管库中的 Azure 备份策略定义了应该何时触发备份，以及需要将备份保留多长时间。 你还可以管理这些策略，并将它们应用于多个项。

  • 监视和报告：Azure 备份与 Log Analytics 集成，提供通过工作簿查看报告的功能。

  • 快照管理：Azure 备份为某些 Azure 原生工作负载（VM 和 Azure 文件存储）创建快照、管理这些快照，并允许从这些快照快速还原。 此选项可大大减少将数据恢复到原始存储的时间。

保管库注意事项

Azure 备份使用保管库（恢复服务保管库和备份保管库）来编排、管理备份并存储备份数据。 有效的保管库设计有助于组织建立一个结构来组织和管理 Azure 中的备份资产，以便支持你的业务优先级。 创建保管库时，请注意以下准则。

单个或多个保管库

若要使用单个或多个保管库来组织和管理备份，请参阅以下准则：

  • 保护跨全球多个区域的资源：如果组织在北美、欧洲和亚洲拥有全球运营，且资源部署在美国东部、英国西部和东亚。 Azure 备份的要求之一是，保管库必须与要备份的资源位于同一区域。 因此，应该为每个区域创建三个单独的保管库以保护资源。

  • 保护各个业务单位和部门的资源：考虑将业务运营划分为三个独立的业务单位 (BU)，每个业务单位有其自己的部门集（五个部门 - 财务、销售、人力资源、研发和营销）。 你的业务需求可能要求每个部门管理和访问其自己的备份和还原；此外，允许他们跟踪其个人使用情况和成本支出。 对于这种情况，我们建议为 BU 中的每个部门创建一个保管库。 这样，整个组织就有 15 个保管库。

  • 保护不同的工作负载：如果你计划保护不同类型的工作负载（例如 150 个 VM、40 个 SQL 数据库和 70 个 PostgreSQL 数据库），我们建议为每种类型的工作负载创建单独的保管库（对于此示例，需要为每个工作负载 - VM、SQL 数据库和 PostgreSQL 数据库 - 创建三个保管库）。 这有助于你为用户分隔访问边界，方法是支持向相关利益干系人授予访问权限（使用 Azure 基于角色的访问控制 - Azure RBAC）。

  • 保护在多个环境中运行的资源：如果你的运营要求你在多个环境（例如生产、非生产和开发人员环境）中工作，我们建议为每个环境创建单独的保管库。

  • 保护大量的（1000 个以上）Azure VM：假设你有 1500 个 VM 需要备份。 Azure 备份只允许在一个保管库中备份 1000 个 Azure VM。 对于这种情况，可以创建两个不同的保管库，并将资源以 1000 和 500 个 VM 的形式分配到相应的保管库，或者在考虑上限的情况下以任意组合方式进行分配。

  • 保护大量（2000 个以上）不同的工作负载：在大规模管理备份时，你将保护 Azure VM 以及其他工作负载，例如这些 Azure VM 上运行的 SQL 和 SAP HANA 数据库。 例如，你有 1300 个 Azure VM 和 2500 个 SQL 数据库需要保护。 保管库限制允许在每个保管库中备份 2000 个工作负载（限制为 1000 个 VM）。 因此，从数学上讲，可以在一个保管库中备份 2000 个工作负载（1000 个 VM + 1000 个 SQL 数据库），在单独的保管库中备份剩下的 1800 个工作负载（300 个 VM + 1500 个 SQL 数据库）。

    但是，不建议使用这种类型的分隔，因为无法定义访问边界，并且工作负载不会相互隔离。 因此，若要正确分配工作负载，请创建四个保管库。 两个保管库用于备份 VM（1000 个 VM + 300 个 VM），另外两个保管库用于备份 SQL 数据库（2000 个数据库 + 500 个数据库）。

  • 可通过以下方式管理备份：

    • 可以使用备份中心的单个窗格来管理所有备份任务。 在此处了解更多信息。
    • 如果需要对不同的保管库应用一致的策略，可以使用 Azure Policy 来跨多个保管库传播备份策略。 可以编写自定义 Azure Policy 定义，以使用 ‘deployifnotexists’ 效果跨多个保管库传播一个备份策略。 还可以将此 Azure Policy 定义分配到特定的范围（订阅或 RG），以便它将一个“备份策略”资源部署到该 Azure Policy 分配的范围内的所有恢复服务保管库。 备份策略的设置（例如备份频率、保留期等）应作为 Azure Policy 分配中的参数由用户指定。
  • 随着组织的占用量的增长，你可能想要跨订阅移动工作负载，原因包括：根据备份策略进行调整，合并保管库，权衡降低冗余度以节省成本（从 GRS 迁移到 LRS）。 Azure 备份支持跨 Azure 订阅移动恢复服务保管库，或将其移动到同一订阅中的其他资源组。 在此处了解更多信息。

查看默认设置

在保管库中配置备份之前，请检查“存储复制类型”和“安全设置”的默认设置是否满足你的需求。

  • “存储复制类型”默认设置为“异地冗余”(GRS)。 配置备份后，将禁用修改选项。 请遵循这些步骤检查和修改设置。

    • 非关键工作负载（例如非生产和开发工作负载）适用于 LRS 存储复制。

    • 区域冗余存储 (ZRS) 是一种不错的存储方式，具有高数据持续性以及数据驻留。

    • 建议将异地冗余存储 (GRS) 用于任务关键型工作负载（例如在生产环境中运行的工作负载），以防止永久性数据丢失，以及防范区域性完全中断或主要区域无法恢复的灾难。

  • “软删除”对新建的保管库默认为“已启用”，旨在防止意外或恶意删除备份数据。 请遵循这些步骤检查和修改设置。

  • 跨区域还原可用于将 Azure VM 还原到次要区域（Azure 配对区域）中。 使用此选项可以执行钻取来满足审核或符合性要求，以及在主要区域发生灾难时还原 VM 或其磁盘。 CRR 是适用于任何 GRS 保管库的可选功能。 在此处了解更多信息。

  • 在完成保管库设计之前，请查看保管库支持矩阵，以了解可能会影响或限制你的设计选择的因素。

备份策略注意事项

Azure 备份策略有两个组件：计划（何时进行备份）和保留期（要将备份保留多长时间）。 可以基于要备份的数据的类型、RTO/RPO 要求、运营或法规符合性需求和工作负载类型（例如，VM、数据库、文件）定义策略。 了解详细信息

创建备份策略时，请注意以下准则：

“计划”注意事项

在计划备份策略时，请考虑以下几点：

  • 对于任务关键型资源，请尝试计划每天最常用的自动备份，使 RPO 保持在较低水平。 了解详细信息

    如果需要每天通过扩展为 Azure VM 进行多次备份，请参阅下一部分中的解决方法。

  • 对于需要相同计划开始时间、频率和保留设置的资源，需要将它们分组到单个备份策略下。

  • 建议将备份计划开始时间安排在非高峰生产应用程序时间段内。 例如，最好将每日自动备份安排在凌晨 2-3 点而不是资源使用量较高的白天进行。

  • 若要分配备份流量，建议在一天的不同时间备份不同的 VM。 例如，若要备份 500 个具有相同保留设置的 VM，建议创建 5 个不同的策略，每个策略与 100 个 VM 关联，并将备份间隔计划为若干小时。

“保留期”注意事项

  • 短期保留可以是“按天”。 “按月”、“按周”或“按年”的备份点保留称为“长期保留”。

  • 长期保留：

    • 已计划（符合性要求）- 如果事先知道数据是从当前时间起的数年内所必需的，请使用长期保留。 Azure 备份支持备份存档层中的长期保留点，以及快照和标准层。 详细了解存档层和保留配置的受支持的工作负载。
    • 未计划（按需要求）- 如果事先不知道，则可以使用特定自定义保留设置进行按需备份（这些自定义保留设置不受策略设置的影响）。

  • 使用自定义保留期按需备份 - 如果需要执行一个未通过备份策略计划的备份，则可以使用按需备份。 如果要执行的备份不适合计划备份，或者要执行细化的备份（例如，每天多个 IaaS VM 备份，因为计划备份只允许每天一个备份），则按需备份可能十分有用。 请务必注意，在计划的策略中定义的保留策略不适用于按需备份。

优化备份策略

  • 随着业务需求的变化，你可能需要延长或缩短保留期。 执行此操作时，可能会出现以下情况：

    • 如果延长保留期，则会根据新策略对现有的恢复点进行标记和保留。
    • 如果缩短保留期，恢复点会标记为要在下一清理作业中删除，并且随后会被删除。
    • 最新的保留规则适用于所有保留点（不包括按需保留点）。 因此，如果保留期已延长（例如，延长到 100天），则在进行备份时，如果又缩短了保留期（例如，从 100 天缩短到 7 天），将根据最后指定的保留期（即 7 天）保留所有备份数据。

  • 使用 Azure 备份可以灵活地停止保护和管理备份：

    • 停止保护并保留备份数据。 如果要停用数据源（VM、应用程序）或对其解除授权，但需要保留数据以用于审核或合规目的，则可以使用此选项停止所有将来的备份作业保护数据源，并保留已备份的恢复点。 然后，可以还原或恢复 VM 保护。

    • 停止保护并删除备份数据。 此选项将使所有将来的备份作业停止保护你的 VM 并删除所有恢复点。 你将无法还原 VM，也无法使用“恢复备份”选项。

    • 如果恢复保护（对于已停止且其数据已保留的数据源），则将应用保留规则。 任何过期的恢复点将被删除（在计划时间）。

  • 在完成策略设计之前，请务必注意可能会影响你的设计选择的下列因素。

    • 一个备份策略的作用域限定为一个保管库。
    • 每个策略的项数有限制（例如，100 个 VM）。 若要缩放，可以创建具有相同或不同计划的重复策略。
    • 不能选择性地删除特定的恢复点。
    • 不能完全禁用计划的备份并使数据源处于受保护状态。 可以使用策略配置的最低频率的备份是每周执行计划的备份一次。 一种替代方法是停止保护且保留数据，并在每次要执行备份时启用保护，然后执行按需备份，之后关闭保护，但保留备份数据。 在此处了解更多信息。

安全注意事项

为了帮助你保护你的备份数据并满足你的业务安全需求，Azure 备份提供了机密性、完整性和可用性保障，防范有人蓄意攻击和滥用你的宝贵数据与系统。 请注意以下适用于 Azure 备份解决方案的安全准则：

使用 Azure 基于角色的访问控制 (Azure RBAC) 进行身份验证和授权

  • Azure 基于角色的访问控制 (Azure RBAC) 用于进行精细的访问管理、在团队中进行职责分离，以及仅将执行作业所需的最低访问权限授予用户。 在此处了解更多信息。

  • 如果你有多个工作负载（例如 Azure VM、SQL 数据库和 PostgreSQL 数据库）需要备份，并且有多个利益干系人管理这些备份，请务必分离其职责，使用户只能访问这些人员负责的资源。 Azure 基于角色的访问控制 (Azure RBAC) 用于进行精细的访问管理、在团队中进行职责分离，以及仅将执行作业所需的访问权限类型授予用户。 了解详细信息

  • 还可通过提供执行特定任务所需的最低访问权限来分离职责。 例如，负责监视工作负载的人员不应拥有修改备份策略或删除备份项的访问权限。 Azure 备份提供三个用于控制备份管理操作的内置角色：备份参与者、操作员和读取者。 在此处了解详细信息。 如需了解 Azure VM、SQL/SAP HANA 数据库和 Azure 文件共享的每个备份操作所需的最低 Azure 角色，请参阅此指南。

  • Azure 基于角色的访问控制 (Azure RBAC) 还支持根据你的个人要求灵活构建自定义角色。 如果你不确定针对特定操作建议的角色类型是否适合自己的情况，可以先从 Azure 基于角色的访问控制 (Azure RBAC) 提供的内置角色着手。

    下图解释了不同 Azure 内置角色的工作原理：

    该图解释了不同 Azure 内置角色的工作原理。

    • 在上图中，User2 和 User3 是备份读取者 。 因此，他们只有权监视备份和查看备份服务。

    • 在访问权限范围方面：

      • User2 只有权访问 Subscription1 的资源，User3 只有权访问 Subscription2 的资源。
      • User4 是备份操作员。 其有权启用备份、触发按需备份、触发还原，并且具有“备份读取者”功能。 但是，在此场景中，其权限范围仅限于 Subscription2。
      • User1 是备份参与者。 该用户有权创建保管库、创建/修改/删除备份策略和停止备份，并具有备份操作员的功能。 但是，在此场景中，其权限范围仅限于 Subscription1。

  • 恢复服务保管库使用的存储帐户是隔离的，恶意用户无法对其进行访问。 仅允许通过 Azure 备份管理操作（例如还原）进行访问。

传输中数据和静态数据的加密

加密可以保护数据，并帮助组织履行在安全性与合规性方面做出的承诺。

  • 在 Azure 中，Azure 存储与保管库之间传输的数据受 HTTPS 保护。 此数据保留在 Azure 网络中。

  • 使用 Microsoft 托管的密钥自动加密备份数据。 或者，你可以使用自己的密钥，也称为客户托管密钥。 此外，使用 CMK 加密进行备份不会产生额外的成本。 不过，使用 Azure 密钥保管库（存储密钥的位置）会产生成本，但这是一项合理的开支，因为可以获得更高数据安全性的回报。

  • Azure 备份支持备份和还原已使用 Azure 磁盘加密 (ADE) 功能加密了其 OS/数据磁盘的 Azure VM。 了解详细信息

使用软删除防止意外删除备份数据

你可能会遇到这种情况：意外或错误地删除了保管库中的任务关键型备份数据。 此外，恶意行动者可能会删除生产备份项。 重新生成这些资源通常代价不菲且很费时，甚至可能导致至关重要的数据丢失。 Azure 备份通过软删除功能防范意外和恶意删除，让你可以在删除资源后予以恢复。

在使用软删除的情况下，如果用户删除了（属于 VM、SQL Server 数据库、Azure 文件共享、SAP HANA 数据库）备份，备份数据将额外保留 14 天，使该备份项可以恢复，而不会丢失数据。 以软删除状态将备份数据额外保留 14 天不会产生任何成本。 了解详细信息

多用户授权 (MUA)

如果管理员恶意入侵系统，你如何保护数据？

对备份数据拥有访问特权的任何管理员都可能会导致系统受到不可修复的损坏。 恶意管理员可以删除所有业务关键型数据，甚至关闭可能导致系统易受网络攻击的所有安全措施。

Azure 备份提供多用户授权 (MUA) 功能，以防范此类恶意管理员攻击。 多用户授权通过确保每个特权/破坏性操作仅在获得安全管理员批准后执行，帮助防范恶意管理员执行破坏性操作（例如禁用软删除）。

勒索软件防护

  • 恶意行动者无法直接访问 Azure 备份数据以进行加密，因为对备份数据的所有操作只能通过恢复服务保管库或备份保管库执行，而这两种机制可通过 Azure 基于角色的访问控制 (Azure RBAC) 和 MUA 受到保护。

  • 对备份数据启用软删除（默认已启用）后，删除的数据将保留 14 天（免费）。 可以使用 MUA 来防止禁用软删除。

  • 使用较长的保留期（周、月、年）以确保干净备份（未由勒索软件加密）不会提前过期；现有的某些策略可以提前检测和缓解针对源数据的此类攻击。

可疑活动的监视和警报

你可能会遇到有人试图入侵你的系统并恶意关闭安全机制的情况，例如禁用软删除或尝试执行破坏性操作（如删除备份资源）。

Azure 备份通过使用你首选的通知渠道（电子邮件、ITSM、Webhook、runbook 和 sp pn）发送关键警报并在警报之上创建操作规则，提供防范此类事件的安全性。 了解详细信息

用于帮助保护混合备份的安全功能

Azure 备份服务使用 Microsoft Azure 恢复服务 (MARS) 代理将本地计算机中的文件、文件夹和卷/系统状态备份和还原到 Azure。 MARS 现在提供了安全功能：通行短语用于在上传到 Azure 备份之前进行加密以及在从 Azure 备份下载之后进行解密，已删除的备份数据将从删除之日起额外保留 14 天，并且关键操作（例如，更改通行短语）只能由具有有效 Azure 凭据的用户执行。 在此处了解更多信息。

网络注意事项

Azure 备份需要将工作负载中的数据移到恢复服务保管库。 Azure 备份提供多种功能，以防止无意中泄露备份数据（例如，通过网络上的中间人攻击）。 遵循以下指南：

Internet 连接

  • Azure VM 备份：存储和 Azure 备份服务之间的所有必需通信和数据传输均在 Azure 网络中发生，无需访问你的虚拟网络。 因此，放置在受保护网络中的 Azure VM 的备份不需要你授予对任何 IP 或 FQDN 的访问权限。

  • Azure VM 上的 SAP HANA 数据库、Azure VM 上的 SQL Server 数据库：要求连接到 Azure 备份服务、Azure 存储和 Microsoft Entra ID。 这可以通过使用专用终结点，或允许访问所需的公共 IP 地址或 FQDN 来实现。 如果不允许正确连接到所需的 Azure 服务，则可能会导致诸如数据库发现、配置备份、执行备份和还原数据等操作失败。 有关在使用 NSG 标记、Azure 防火墙和 HTTP 代理时可参考的完整网络指南，请参阅这些 SQL 和 SAP HANA 文章。

  • 混合：对于所有关键操作（安装、配置、备份和还原），MARS（Microsoft Azure 恢复服务）代理都需要进行网络访问。 MARS 代理可以通过以下这些方式连接到 Azure 备份服务：使用公共对等互连（可用于旧线路）和 Microsoft 对等互连通过 Azure ExpressRoute 进行连接；使用专用终结点进行连接；通过具有适当访问控制的代理/防火墙进行连接。

用于安全访问的专用终结点

使用 Azure 备份保护关键数据时，你不希望资源可以通过公共 Internet 被访问。 尤其是，如果作为银行或金融机构，你会有严格的合规性和安全性要求，以保护高业务影响 (HBI) 数据。 即使是医疗保健行业，也有严格的合规性规则。

如需满足所有这些需求，可使用 Azure 专用终结点，Azure 专用终结点是一个网络接口，可以通过私密且安全的方式将你连接到 Azure 专用链接支持的服务。 建议使用专用终结点来保护备份和还原，无需将虚拟网络中 Azure 备份或 Azure 存储的任何 IP/FQDN 添加到允许列表。

详细了解如何在虚拟网络内为 Azure 备份创建和使用专用终结点。

  • 为保管库启用了专用终结点后，这些专用终结点仅用于 Azure VM 中的 SQL 和 SAP HANA 工作负载的备份和还原以及 MARS 代理和 DPM/MABS 的备份。 还可以使用保管库来备份其他工作负载（尽管它们不需要专用终结点）。 除了 SQL 和 SAP HANA 工作负载的备份以及使用 MARS 代理和 DPM/MABS Server 进行的备份，专用终结点还可用于针对 Azure VM 备份执行文件恢复。 在此处了解更多信息。

  • Microsoft Entra ID 当前不支持专用终结点。 因此，在 Azure VM 中执行数据库备份和使用 MARS 代理进行备份时，需要允许 Microsoft Entra ID 所需的 IP 和 FQDN 从受保护的网络进行出站访问。 如果适用，还可以使用 NSG 标记和 Azure 防火墙标记来允许访问 Microsoft Entra ID。 详细了解此处的先决条件。

治理注意事项

Azure 中的治理主要通过 Azure Policy 和 Azure 成本管理来实现。 Azure Policy 允许你创建、分配和管理策略定义，以强制执行资源规则。 此功能可使这些资源符合企业标准。 Azure 成本管理可用于跟踪 Azure 资源和其他云提供商的云使用情况和开支。 此外，下列工具（例如 Azure 价格计算器和 Azure 顾问）在成本管理过程中扮演着重要的角色。

使用 Azure Policy 大规模自动配置新预配的备份基础结构

  • 每当预配新基础结构和创建新 VM 时，备份管理员都需要确保保护它们。 可以轻松为一个或两个 VM 配置备份。 但是，如果需要大规模配置数百甚至数千个 VM，则工作会变得复杂。 为了简化配置备份的过程，Azure 备份提供了一组用于管理备份资产的内置 Azure 策略。

  • 使用 Policy 在 VM 上自动启用备份（中心备份团队模型）：如果你的组织有一个中心备份团队，负责管理跨应用程序团队的备份，则可以使用该策略将备份配置为与 VM 相同的订阅和位置中的现有中央恢复服务保管库。 可以选择包括/排除包含策略范围中特定标记的 VM。 了解详细信息。

  • 使用 Policy 在 VM 上自动启用备份（备份由应用程序团队拥有的情况）：如果你通过专用资源组来组织应用程序，并且想要通过同一保管库来备份这些应用程序，可以使用此策略来自动管理此操作。 可以选择包括/排除包含策略范围中特定标记的 VM。 了解详细信息。

  • 监视策略：如果要为资源生成备份报告，请在创建新的保管库时启用诊断设置。 通常，为每个保管库手动添加诊断设置是一项繁琐的任务。 因此，可以利用 Azure 内置策略，将诊断设置大规模配置为每个订阅或资源组中的所有保管库（Log Analytics 作为目标）。

  • 仅审核策略：Azure 备份还提供仅审核策略，用于标识没有备份配置的 VM。

Azure 备份成本注意事项

通过 Azure 备份服务，可以灵活地有效管理成本，并且仍然满足 BCDR（业务连续性和灾难恢复）业务要求。 遵循以下指南：

  • 使用定价计算器可以通过调整各种杠杆来评估和优化成本。 了解详细信息

  • 优化备份策略。

    • 基于工作负载原型（例如，任务关键型、非关键型）优化计划和保留设置。
    • 针对即时还原优化保留设置。
    • 选择适当的备份类型来满足要求，同时考虑到 Azure 备份中的工作负载所支持的备份类型（完整备份、增量备份、日志备份、差异备份）。

  • 使用选择性备份磁盘减少备份存储成本：排除磁盘功能提供高效、高性价比的选择，可选择性地备份关键数据。 例如，如果你不想备份附加到 VM 的所有磁盘，可以只备份一个磁盘。 这在你有多个备份解决方案时也很有用。 例如，若要使用工作负载备份解决方案（Azure VM 中的 SQL Server 数据库备份）来备份数据库或数据，可以将 Azure VM 级备份用于所选磁盘。

  • 使用即时还原功能加速还原并最大程度降低 RTO：Azure 备份会创建 Azure VM 的快照，并将这些快照与磁盘一起存储，以加快恢复点创建并加快还原操作。 这称为即时还原。 此功能允许从这些快照执行还原操作，并可缩短还原时间。 它减少了从保管库转换数据和复制回数据所需的时间。 因此，在此期间创建的快照会产生存储成本。 详细了解 Azure 备份即时恢复功能。

  • 选择正确的复制类型：Azure 备份保管库的存储复制类型默认设置为异地冗余 (GRS)。 在开始保护备份项之后无法更改此选项。 异地冗余存储 (GRS) 提供更高级别的数据持久性（与本地冗余存储 (LRS) 相比），允许选择使用跨区域还原，但成本更高。 请在较低的成本与较高的数据持久性之间权衡取舍，选择最适合你的情况的选项。 了解详细信息

  • 将存档层用于长期保留 (LTR) 并节省成本：请考虑以下场景：你有极少访问的较旧备份数据，但由于合规性因素，需要将其长期存储（例如 99 年）。 在标准层中存储这样的海量数据成本高且不经济。 为了帮助优化存储成本，Azure 备份提供了存档层，这是一个访问层，专为备份数据的长期保留 (LTR) 设计。

  • 如果要保护 VM 中运行的工作负载和该 VM 自身，请确定是否需要这种双重保护。

监视和警报注意事项

作为备份用户或管理员，你应该能够监视所有备份解决方案并获得有关重要情况的通知。 本部分详细介绍了 Azure 备份服务提供的监视和通知功能。

监视

  • Azure 备份针对配置备份、备份、还原、删除备份等操作提供内置的作业监视。 这仅限用于保管库，并且最适用于监视单个保管库。 在此处了解更多信息。

  • 如果需要大规模监视操作活动，则可使用备份资源管理器来提供整个备份资产的聚合视图，从而实现详细的深化分析和故障排除。 内置的 Azure Monitor 工作簿提供了一个中心位置，可帮助你跨租户、位置、订阅、资源组和保管库监视 Azure 中的整个备份资产的操作活动。 在此处了解更多信息。

    • 使用它可识别未配置为要进行备份的资源，并确保你永不会错过保护不断增长的资产中的关键数据。
    • 该仪表板提供过去 7 天（最大值）的操作活动。 如果需要保留此数据，则可以导出为 Excel 文件并保留这些数据。
    • 如果你是 Azure Lighthouse 用户，则可以跨多个租户查看信息，从而实现无边界监视。

  • 如果需要长期保留并查看操作活动，请使用报告。 备份管理员的一个常见需求是根据时间跨度较长的数据获取有关备份的见解。 此类解决方案的用例包括：

    • 分配和预测需使用的云存储空间。
    • 审核备份和还原。
    • 确定不同粒度级别的关键趋势。

  • 此外，

    • 你可以将数据（例如作业、策略等）发送到 Log Analytics 工作区。 这将启用 Azure Monitor 日志的功能以使数据可与 Azure Monitor 收集的其他监视数据进行关联、将多个 Azure 订阅和租户中的日志条目合并到一个位置以便一起分析、使用日志查询执行复杂的分析，并且获得有关日志条目的深入见解。 在此处了解更多信息。
    • 可以向 Azure 事件中心发送数据，以向 Azure 外部发送条目，例如，发送到第三方 SIEM（安全信息和事件管理）或其他日志分析解决方案。 在此处了解更多信息。
    • 如果要将日志数据保留 90 天以上以进行审核、静态分析或备份，可以将数据发送到 Azure 存储帐户。 如果只需将事件保留 90 天或更短的时间，则无需设置存档到存储帐户，因为活动日志事件保留在 Azure 平台中的时间是 90 天。 了解详细信息。

警报

在某些情况下，备份/还原作业会因某种未知问题而失败。 若要指派工程师对此问题进行调试，需要尽快收到有关失败情况的通知。 另外，在某些情况下，可能有人恶意执行破坏性操作（例如删除备份项或关闭软删除），你需要收到针对此类事件的警报消息。

可以配置此类关键警报，并将其路由到任何首选通知渠道（电子邮件、ITSM、webhook、runbook 等）。 Azure 备份与多个 Azure 服务集成，以满足不同的警报和通知要求：

  • Azure Monitor 日志 (Log Analytics)：可以将保管库配置为向 Log Analytics 工作区发送数据，针对工作区编写自定义查询，并将警报配置为基于查询输出生成。 可以在表和图表中查看查询结果；此外，将其导出到 Power BI 或 Grafana。 （Log Analytics 也是后续部分中所述的报告/审核功能的关键组件）。

  • Azure Monitor 警报：对于某些默认场景（例如备份失败、还原失败、备份数据删除等），Azure 备份默认会发送可在 Azure Monitor 中查看的警报，而无需用户设置 Log Analytics 工作区。

  • Azure 备份提供了内置的警报通知机制，可通过电子邮件针对故障、警告和关键操作发出通知。 可以指定在生成警报时接收通知的个人电子邮件地址或通讯组列表。 还可以选择是要接收每个警报的通知，还是将这些警报分组成按小时摘要，然后接收通知。

    • 这些警报由服务定义，并针对有限的场景（备份/还原失败、停止保护并保留数据/停止保护并删除数据，等等）提供支持。 在此处了解更多信息。
    • 如果执行了破坏性操作（例如“停止保护并删除数据”），那么，即使未针对恢复服务保管库配置通知，也会引发警报，并且会向订阅所有者、管理员和共同管理员发送电子邮件。
    • 某些工作负载可能会导致失败频发（例如，SQL Server 每 15 分钟发生一次失败）。 为了防止每次发生失败时都会引发大量的警报，警报会进行合并。 在此处了解更多信息。
    • 内置的警报不能自定义，并且仅限于 Azure 门户中定义的电子邮件。

  • 如果需要创建自定义警报（例如，成功作业的警报），请使用 Log Analytics。 在 Azure Monitor 中，可以在 Log Analytics 工作区内创建你自己的警报。 混合工作负载 (DPM/MABS) 也可以将数据发送到 LA，并使用 LA 为 Azure 备份支持的工作负载提供常见警报。

  • 还可以通过内置的恢复服务保管库活动日志获取通知。 但是，它只支持有限的场景，并且不适用于计划备份（与活动日志相比，资源日志更适用于该操作）之类的操作。 若要详细了解这些限制，以及如何使用 Log Analytics 工作区对 Azure 备份保护的所有工作负载进行大规模的监视和警报发送，请参阅此文章。

自动重试失败的备份作业

许多失败错误或中断情况在是暂时性的，可以通过设置正确的 Azure 基于角色的访问控制 (Azure RBAC) 权限或重新触发备份/还原作业来修正。 由于此类故障的解决方案很简单，因此无需花费时间等待工程师手动触发作业或分配相关权限。 因此，处理这种情况的更明智方法是自动重试失败的作业。 这非常有助于最大程度地减少在失败后予以恢复所花费的时间。 为此，可通过 Azure Resource Graph (ARG) 检索相关备份数据，并将其与纠正的 PowerShell/CLI 程序结合使用。

请观看以下视频，了解如何使用 ARG 和 PowerShell 为所有失败作业（跨保管库、订阅和租户）重新触发备份。

将警报路由到首选通知渠道

虽然可以更正暂时性错误，但某些持续出现的错误可能需要深入分析，重新触发作业的解决方法不一定可行。 你可以使用自己的监视/票证机制来确保正确跟踪和修复此类失败。 若要处理此类情况，可以通过在警报上创建操作规则，选择将警报路由到首选通知渠道（电子邮件、ITSM、Webhook、runbook 等）。

请观看以下视频，了解如何利用 Azure Monitor 为关键警报配置各种通知机制。

后续步骤

请阅读以下文章，作为学习 Azure 备份用法的起点：