本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 备份保管库
在中 AWS Backup，*备份保管库*是一个用于存储和组织备份的容器。
创建备份存储库时，必须指定 AWS Key Management Service (AWS KMS) 加密密钥，该密钥用于加密放置在该存储库中的某些备份。其他备份的加密由其源 AWS 服务管理。有关加密的更多信息，请参阅 [AWS中的备份加密](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)。
以下几节概述了如何在 AWS Backup中管理您的备份保管库。
**Topics**
+ [备份保管库创建和删除](create-a-vault.md)
+ [逻辑上受物理隔离的保管库](logicallyairgappedvault.md)
+ [文件库访问策略](create-a-vault-access-policy.md)
+ [AWS Backup 文件库锁](vault-lock.md)
# 备份保管库创建和删除
在创建备份计划或开始备份作业之前，您必须至少创建一个保管库。
当您首次在中使用 AWS Backup 控制台的 **Backup Vaul** ts 页面时 AWS 区域，控制台会自动为该区域创建默认存储库。
但是，如果您 AWS Backup 通过 AWS CLI、 AWS SDK 或使用 CloudFormation，则不会创建默认保管库。您必须创建自己的保管库。
## 所需的权限
您必须具有以下权限，才能使用 AWS Backup创建备份保管库。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AllowKMSOperations",
"Effect": "Allow",
"Action": [
"kms:CreateGrant",
"kms:DescribeKey",
"kms:RetireGrant",
"kms:Decrypt",
"kms:GenerateDataKey"
],
"Resource": "arn:aws:kms:us-east-1:444455556666:key/1234abcd-12ab-34cd-56ef-1234567890ab"
},
{
"Sid": "AllowCreateBackupVault",
"Effect": "Allow",
"Action": [
"backup:CreateBackupVault"
],
"Resource": "arn:aws:backup:us-east-1:444455556666:backup-vault:*"
},
{
"Sid": "AllowMountCapsule",
"Effect": "Allow",
"Action": [
"backup-storage:MountCapsule"
],
"Resource": "*"
}
]
}
```
------
## 创建备份保管库（控制台）
您可以不使用 AWS Backup 控制台上自动为您创建的默认备份保管库，而是创建特定备份保管库，在同一个保管库中保存和组织备份组。
**创建备份保管库**
1. 在 AWS Backup 控制台的导航窗格中，选择 **Backup Vaul** ts。
**注意**
如果左侧看不到导航窗格，则可以通过选择控制台左上角的菜单图标将其打开。 AWS Backup
1. 选择**创建备份保管库**。
1. 输入备份保管库的名称。您对保管库的命名可以体现出将要存储在其中的内容，或者便于搜索您所需的备份。例如，您可以将其命名为 **FinancialBackups**。
1. 选择一个 AWS Key Management Service (AWS KMS) 密钥。您可以使用已创建的密钥，也可以选择默认 AWS Backup KMS 密钥。
**注意**
此处指定的 AWS KMS 密钥仅适用于支持 AWS Backup 独立加密的服务的备份。要查看支持 AWS Backup 独立加密的资源类型列表，请参阅[按资源划分的功能可用性](backup-feature-availability.md#features-by-resource)表格的 “完全管理” 部分。
1. （可选）添加标签可帮助您搜索和标识备份保管库。例如，您可以添加 **BackupType:Financial** 标签。
1. 选择**创建备份保管库**。
1. 在导航窗格中，选择**备份保管库**，并确保您的备份保管库已添加。
**注意**
现在，您可以在某个备份计划中编辑备份规则，以便将由该规则创建的备份存储在您刚刚创建的备份保管库中。
## 创建备份保管库（以编程方式）
以下 AWS Command Line Interface 命令创建备份保管库：
```
aws backup create-backup-vault --backup-vault-name test-vault
```
您还可以为备份保管库指定以下配置。
## 备份保管库名称
备份保管库名称区分大小写。名称必须包含 2 到 50 个字母数字字符、连字符或下划线。
## AWS KMS 加密密钥
AWS KMS 加密密钥可保护您在此备份保管库中的备份。默认情况下， AWS Backup 使用别名 `aws/backup` 为您创建 KMS 密钥。您可以选择该密钥或选择账户中的任何其他密钥（跨账户 KMS 密钥可通过 CLI 使用）。
您可以按照《AWS Key Management Service 开发人员指南》**中的[创建密钥](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html)过程，创建新的加密密钥。
创建备份保管库并设置 AWS KMS 加密密钥后，您将无法再编辑该备份保管库的密钥。
在 AWS Backup 文件库中指定的加密密钥适用于某些资源类型的备份。有关备份加密的更多信息，请参阅“安全”部分中的[对中的备份进行加密 AWS Backup](encryption.md)。所有其他资源类型的备份通过用于加密源资源的密钥进行备份。
## 备份保管库标签
这些标签与备份保管库关联，帮助您组织和跟踪备份保管库。
## 删除文件库
为防止意外或恶意大规模删除，只有在删除备份保管库中的所有恢复点（或备份计划生命周期）之后，才能删除 AWS Backup 中的备份保管库。要手动删除恢复点，请参阅[删除备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/deleting-backups.html)。
删除备份保管库时，请更新您的备份计划以指向新的备份保管库。指向已删除备份保管库的备份计划将导致备份创建失败。
您无法使用 AWS 管理控制台删除默认备份保管库或 Amazon EFS 自动备份保管库。如果默认备份保管库为空， AWS CLI 则可以使用将其删除。但是，如果您打开 AWS Backup 控制台并选择该区域，则控制台会重新创建默认备份保管库。您可以删除 Amazon EFS 自动备份保管库中未使用的快照。
**使用 AWS Backup 控制台删除备份保管库**
1. 登录 AWS 管理控制台，然后在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在导航窗格中，选择**备份保管库**。
1. 选择备份保管库名称以打开其详细信息页面。
1. 选择并删除与备份保管库关联的任何备份。
1. 选择**删除保管库**。提示进行确认时，输入保管库名称，然后选择**删除备份保管库**。
# 逻辑上受物理隔离的保管库
## 逻辑上受物理隔离的保管库概述
AWS Backup 提供了一种辅助类型的保管库，可以将备份存储在具有其他安全功能的容器中。**逻辑上空隙的保管库**是一种专门的保管库，它提供了比标准备份保管库更高的安全性，并且能够与其他账户共享保管库访问权限，这样在发生需要快速恢复资源的事件时，恢复时间目标 (RTOs) 可以更快、更灵活。
从逻辑上讲，气隙保管库配备了额外的保护功能；每个保管库都使用[AWS 自有密钥（默认）或可选的客户管理的 KMS 密钥](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#key-mgmt)进行加密，并且每个保管库都配备了 Vault [Lock 的合AWS Backup 规](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)模式。加密密钥类型信息可通过控制台查看 AWS Backup APIs ，以实现透明度和合规性报告。
您可以将逻辑上空隙的保管库与[多方批准](multipartyapproval.md) (MPA) 集成，即使无法访问保管库拥有者的帐户，也可以恢复保管库中的备份，这有助于保持业务连续性。此外，您可以选择与 [AWS Resource Access Manager](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)(RAM) 集成，与其他 AWS 账户（包括其他组织中的账户）共享逻辑上存在空隙的保管库，以便在需要进行数据丢失恢复或还原测试时，可以从共享该保管库的账户中[恢复](restore-testing.md)存储在保管库中的备份。作为增强安全性的一部分，逻辑上隔绝的保管库将其备份存储在 AWS Backup 服务拥有的账户中（这会导致在 AWS CloudTrail 日志中的修改属性项中显示为组织外部共享的备份）。
[在您的逻辑上存在气隙的保管库拥有账户被关闭（恶意或其他方式）的情况下，您仍然可以通过 MPA 访问存储库中的备份（恢复或复制），直到关闭后的期限结束。](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#post-closure-period)关闭后期限到期后，将无法再访问备份。在关闭后期间，您可以参考[AWS 账户管理文档，在恢复账户](https://docs.aws.amazon.com/accounts/latest/reference/manage-acct-closing.html#what-to-expect-after-closure)的同时重新获得对账户的控制权。
为了提高弹性，我们建议在相同或单独的账户中在逻辑上存在气隙的保管库中创建跨区域副本。但是，如果您想通过仅维护一个副本来降低存储成本，则可以在加入 MPA 后使用[主备份来实现逻辑上空隙的保管库](lag-vault-primary-backup.md)。 AWS
您可以在 [AWS Backup 定价](https://aws.amazon.com/backup/pricing/)页面上查看逻辑上受物理隔离的保管库中受支持服务的备份的存储定价。
有关您可以复制到逻辑上受物理隔离的保管库的资源类型，请参阅[按资源划分的功能可用性](backup-feature-availability.md#features-by-resource)。
**Topics**
+ [逻辑上受物理隔离的保管库概述](#lag-overview)
+ [逻辑上受物理隔离的保管库的用例](#lag-usecase)
+ [与标准备份保管库进行比较和对比](#lag-compare-and-contrast)
+ [创建逻辑上受物理隔离的保管库](#lag-create)
+ [查看逻辑上受物理隔离的保管库的详细信息](#lag-view)
+ [在逻辑隔绝的保管库中创建备份](#lag-creation)
+ [共享逻辑上受物理隔离的保管库](#lag-share)
+ [从逻辑上受物理隔离的保管库中还原备份](#lag-restore)
+ [删除逻辑上受物理隔离的保管库](#lag-delete)
+ [逻辑上受物理隔离的保管库的其他编程选项](#lag-programmatic)
+ [了解逻辑上存在气隙的保管库的加密密钥类型](#lag-encryption-key-types)
+ [服务自有密钥的使用](#lag-service-owned-key)
+ [安全自动修复的注意事项](#lag-security-auto-remediation)
+ [解决逻辑上受物理隔离的保管库问题](#lag-troubleshoot)
+ [目标为逻辑上受物理隔离的保管库的主备份](lag-vault-primary-backup.md)
+ [逻辑上受物理隔离的保管库的多方审批](multipartyapproval.md)
## 逻辑上受物理隔离的保管库的用例
逻辑上受物理隔离的保管库是作为数据保护策略一部分的辅助保管库。当您希望为备份使用符合以下条件的保管库时，此保管库可以帮助增强组织的保留策略和恢复能力
+ 在[合规模式](vault-lock.md)下使用保管库锁定功能自动设置
+ 默认情况下，使用 AWS 自有密钥提供加密。（可选）您可以提供客户托管密钥
+ 包含通过 AWS RAM 或 MPA 与创建备份的帐户不同的帐户共享和恢复的备份
**注意事项和限制**
+ 未加密的 Amazon Aurora、Amazon DocumentDB 和 Amazon Neptune 集群不支持逻辑空隙保管库，因为它们不支持对未加密的数据库集群快照进行加密。
+ 亚马逊 EC2 提供 [EC2 允许 AMIs](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/ec2-allowed-amis.html)。如果您的账户启用了此设置，请将别名 `aws-backup-vault` 添加到您的允许列表中。
如果未添加此别名，则从逻辑上受物理隔离的保管库复制到备份保管库的操作以及从逻辑上受物理隔离的保管库中还原 EC2 实例的操作将失败，并显示错误消息，例如“在区域中找不到源 AMI ami-xxxxxx”。
+ 存储在逻辑上受物理隔离的保管库中的恢复点的 ARN（Amazon 资源名称）将使用 `backup` 代替底层资源类型。例如，如果原始 ARN 以 `arn:aws:ec2:region::image/ami-*` 开头，则逻辑上受物理隔离的保管库中恢复点的 ARN 将为 `arn:aws:backup:region:account-id:recovery-point:*`。
您可以使用 CLI 命令 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html) 确定 ARN。
## 与标准备份保管库进行比较和对比
**备份保管库**是 AWS Backup中使用的主要和标准类型的保管库。创建备份时，每个备份都存储在备份保管库中。您可以分配基于资源的策略来管理存储在保管库中的备份，例如存储在保管库中的备份的生命周期。
**逻辑气隙保管库**是一种专门的保管库，具有更高的安全性和灵活共享功能，可缩短恢复时间 (RTO)。此存储库存储最初创建并存储在标准备份存储库中的主备份或备份副本。
备份保管库使用密钥进行加密，这是一种限制目标用户访问权限的安全机制。这些密钥可以由客户管理或 AWS 管理。有关复制作业期间的加密行为（包括复制到逻辑上受物理隔离的保管库），请参阅[复制加密](encryption.md#copy-encryption)。
此外，借助保管库锁定功能，可以更安全地保护备份保管库；逻辑上受物理隔离的保管库配备了合规模式下的保管库锁定功能。
与备份存储库类似，逻辑上的气隙存储库也支持 [Amazon EC2 备份的受限标签](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Using_Tags.html#tag-restrictions)。
| 功能 | 备份保管库 | 逻辑上受物理隔离的保管库 |
| --- | --- | --- |
| [AWS Backup Audit Manager](aws-backup-audit-manager.md) | 您可以使用 Audi AWS Backup t Manager [控制和修复](controls-and-remediation.md) 来监控您的备份存储库。 | 除了标准存储库可用的控件外，还要确保按照您确定的时间表将特定资源的备份存储在[至少一个逻辑上存在气隙的保管库](controls-and-remediation.md#resources-in-lag-vault-control)中。 |
| [Billing](https://aws.amazon.com/backup/pricing/) | 完全由 AWS Backup 托管的资源的存储和数据传输费用记在“AWS Backup”下。其他资源类型的存储和数据传输费用将记在各自的服务下。 例如，Amazon EBS 备份将显示在“Amazon EBS”下；Amazon S3 备份将显示在“AWS Backup”下。 | 这些保管库的所有账单费用（存储或数据传输）都记在“AWS Backup”下。 |
| [区域](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#features-by-region) | 在所有 AWS Backup 运营地区均可用 | 在支持的大多数地区都可用 AWS Backup。目前在亚太地区（马来西亚）、加拿大西部（卡尔加里）、墨西哥（中部）、亚太地区（泰国）、亚太地区（台北）、亚太地区（新西兰）、中国（北京）、中国（宁夏） AWS GovCloud 、（美国东部） AWS GovCloud 或（美国西部）不可用。 |
| [资源](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#supported-resources) | 可以存储大多数支持跨账户复制的资源类型的备份副本。 | 有关可以复制到此保管库的资源，请参阅[按资源划分的功能可用性](backup-feature-availability.md#features-by-resource)中的逻辑上受物理隔离的保管库列。 |
| [还原](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html) | 备份可以由保管库所属的同一个账户进行还原， | 也可以由与其所属账户不同的另一个账户进行还原，但前提是这两个账户共享该保管库。 |
| [安全性](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-considerations.html) | 可以选择使用密钥进行加密（客户管理或 AWS 管理） 可以选择在合规模式或监管模式下使用保管库锁定功能 | 可以使用[AWS 自有密钥或客户管理的密钥](https://docs.aws.amazon.com//kms/latest/developerguide/concepts.html#key-mgmt)进行加密 在合规模式下始终使用[保管库锁定](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html)功能进行锁定 通过 AWS RAM 或 MPA 共享文件库时，加密密钥类型信息会被保留并可见 |
| [共享](#lag-share) | 可以通过策略和 [AWS Organizations](https://docs.aws.amazon.com/aws-backup/latest/devguide/manage-cross-account.html) 管理访问权限 不兼容 AWS RAM | 可以选择使用 [AWS RAM](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) 跨账户共享 |
## 创建逻辑上受物理隔离的保管库
您可以通过 AWS Backup 控制台或通过 AWS Backup 和 CL AWS RAM I 命令的组合来创建逻辑上隔绝的保管库。
在合规模式下，每个逻辑上受物理隔离的保管库都配有保管库锁定功能。请参阅[AWS Backup 文件库锁](vault-lock.md)，以帮助确定适合运营的保留期值
------
#### [ Console ]
**从控制台创建逻辑气隙保管库**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在导航窗格中，选择**保管库**。
1. 将显示两种类型的保管库。选择**创建新保管库**。
1. 输入备份保管库的名称。您对保管库的命名可以体现出将要存储在其中的内容，或者便于搜索您所需的备份。例如，您可以将其命名为 `FinancialBackups`。
1. 选择**逻辑上受物理隔离的保管库**所对应的单选按钮。
1. *（可选）*选择加密密钥。您可以选择客户管理的 KMS 密钥来进一步控制加密，也可以使用默认 AWS拥有的密钥（推荐）。
1. 设置**最短保留期**。
此值（以天、月或年为单位）是可以在此保管库中保留备份的最短时间。无法将保留期短于此值的备份复制到此保管库。
允许的最小值为 `7` 天。月数和年数的值满足这一最低要求。
1. 设置**最长保留期**。
此值（以天、月或年为单位）是可以在此保管库中保留备份的最长时间。无法将保留期大于此值的备份复制到此保管库。
1. *（可选）*设置**加密密钥**。
指定要用于保管库的密钥。您可以选择**AWS 拥有的密钥（由管理 AWS Backup）**，也可以为**客户管理的密钥输入 ARN，该密钥**最好属于您有权访问的其他账户。 AWS Backup 建议使用 AWS 自有密钥。
1. *（可选）*添加标签，以帮助您搜索和识别逻辑气隙保管库。例如，您可以添加 `BackupType:Financial` 标签。
1. 选择**创建保管库**。
1. 检查设置。如果所有设置都按预期显示，请选择**创建逻辑气隙保管库**。
1. 控制台将带您进入新保管库的详细信息页面。验证保管库详细信息是否符合预期。
1. 选择**保管库**以查看您账户中的保管库。此时将显示逻辑上受物理隔离的保管库。KMS 密钥将在保管库创建后大约 1 到 3 分钟内可用。刷新页面以查看关联的密钥。一旦密钥可见，保管库即处于可用状态，可供使用。
------
#### [ AWS CLI ]
从 CLI 创建逻辑上受物理隔离的保管库
您可以使用以编程方式 AWS CLI 对逻辑上存在气隙的保管库执行操作。每个 CLI 都特定于其来源的 AWS 服务。与共享相关的命令在前面加上 `aws ram`；所有其他命令都应在前面加上 `aws backup`。
使用 CLI 命令 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-logically-air-gapped-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-logically-air-gapped-backup-vault.html)，该命令用以下参数进行了修改：
```
aws backup create-logically-air-gapped-backup-vault
--region us-east-1 // optional
--backup-vault-name sampleName // required
--min-retention-days 7 // required Value must be an integer 7 or greater
--max-retention-days 35 // required
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012 // optional
--creator-request-id 123456789012-34567-8901 // optional
```
可选`--encryption-key-arn`参数允许您为文件库加密指定客户管理的 KMS 密钥。如果未提供，则保管库将使用 AWS拥有的密钥。
用于创建逻辑上受物理隔离的保管库的 CLI 命令示例：
```
aws backup create-logically-air-gapped-backup-vault
--region us-east-1
--backup-vault-name sampleName
--min-retention-days 7
--max-retention-days 35
--creator-request-id 123456789012-34567-8901 // optional
```
使用客户管理的加密创建逻辑空隙保管库的 CLI 命令示例：
```
aws backup create-logically-air-gapped-backup-vault
--region us-east-1
--backup-vault-name sampleName
--min-retention-days 7
--max-retention-days 35
--encryption-key-arn arn:aws:kms:us-east-1:123456789012:key/12345678-1234-1234-1234-123456789012
--creator-request-id 123456789012-34567-8901 // optional
```
有关创建操作之后的信息，请参阅 [CreateLogicallyAirGappedBackupVault API 响应元素](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_CreateLogicallyAirGappedBackupVault.html)。如果操作成功，则新的逻辑上存在气隙的保管库将 VaultState 为。`CREATING`
创建完成并分配 KMS 加密密钥后， VaultState 将转换为`AVAILABLE`。该保管库为可用状态后，即可供使用。可以通过调用 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html) 或 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html) 来检索 `VaultState`。
------
## 查看逻辑上受物理隔离的保管库的详细信息
您可以通过 AWS Backup 控制台或 AWS Backup CLI 查看文件库的详细信息，例如摘要、恢复点、受保护的资源、帐户共享、访问策略和标签。
------
#### [ Console ]
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 从左侧导航窗格中，选择**保管库**。
1. 文件库描述下方将列出三个列表：**该账户创建的保管库**、**通过 RAM 共享的保管库以及可通过**多方批准**访问的保管库**。选择所需的选项卡以查看保管库。
1. 在**保管库名称**下，单击保管库名称以打开详细信息页面。您可以查看摘要、恢复点、受保护的资源、账户共享、访问策略和标签详细信息。
详细信息的显示视账户类型而定：拥有保管库的账户可以查看账户共享；不拥有保管库的账户将无法查看账户共享。对于共享文件库，加密密钥类型（AWS由所有或客户管理的 KMS 密钥）显示在文件库摘要中。
------
#### [ AWS CLI ]
通过 CLI 查看逻辑上受物理隔离的保管库的详细信息
CLI 命令 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/describe-backup-vault.html) 可用于获取有关保管库的详细信息。参数 `backup-vault-name` 是必需项，`region` 是可选项。
```
aws backup describe-backup-vault
--region us-east-1
--backup-vault-name testvaultname
```
响应示例：
```
{
"BackupVaultName": "LOG-AIR-GAP-VAULT-TEST",
"BackupVaultArn": "arn:aws:backup:us-east-1:234567890123:backup-vault:IAD-LAGV-01",
"VaultType": "LOGICALLY_AIR_GAPPED_BACKUP_VAULT",
"EncryptionKeyType": "AWS_OWNED_KMS_KEY",
"CreationDate": "2024-07-25T16:05:23.554000-07:00",
"NumberOfRecoveryPoints": 0,
"Locked": true,
"MinRetentionDays": 8,
"MaxRetentionDays": 30,
"LockDate": "2024-07-25T16:05:23.554000-07:00"
}
```
**注意**
在逻辑上隔开的保管库不可用的区域，API 响应中不包含该`VaultType`字段。
------
## 在逻辑隔绝的保管库中创建备份
从逻辑上讲，空隙存储库可以是备份计划中的复印任务目标或按需复印作业的目标。它也可以用作主备份目标。请参见[对逻辑气隙存储库的主备份](lag-vault-primary-backup.md)。
**兼容的加密**
要确保成功从备份保管库复制到逻辑上受物理隔离的保管库，需要一个由所复制的资源类型确定的加密密钥。
在创建或复制[完全托管资源类型的](backup-feature-availability.md#features-by-resource)备份时，可以通过客户托管密钥或托管密钥对源资源进行加密。 AWS
创建或复制其他资源类型（[未完全托管的资源）的备份时，必须使用客户管理](backup-feature-availability.md#features-by-resource)的密钥对源进行加密。 AWS 不支持非完全托管资源的托管密钥。
**通过备份计划创建备份或将备份复制到逻辑上空隙的保管库**
您可以通过[创建新的备份计划或在 AWS Backup 控制台中[更新现有](updating-a-backup-plan.md)备份计划或通过 AWS CLI 命令[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/create-backup-plan.html)和将备份（恢复点）从标准备份](creating-a-backup-plan.md)保管库复制到逻辑上隔绝的保管库。[https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/update-backup-plan.html)您也可以将其用作主目标，直接在逻辑上存在气隙的保管库中创建备份。有关更多详细信息，请参阅[对逻辑气隙保管库的主备份](lag-vault-primary-backup.md)。
可以按需将备份从一个逻辑上受物理隔离的保管库复制到另一个逻辑上受物理隔离的保管库（无法在备份计划中安排此类备份）。只要使用客户托管密钥对副本进行加密，就可以将备份从逻辑上受物理隔离的保管库复制到标准备份保管库。
**按需将备份复制到逻辑上受物理隔离的保管库**
要在逻辑上受物理隔离的保管库中创建一次性[按需](recov-point-create-on-demand-backup.md)备份副本，可以从标准备份保管库中进行复制。如果资源类型支持副本类型，则可以使用跨区域或跨账户副本。
**副本可用性**
可以从保管库所属的账户创建备份副本。共享保管库的账户可以查看或还原备份，但不能创建副本。
只能包括[支持跨区域或跨账户复制的资源类型](backup-feature-availability.md#features-by-resource)。
------
#### [ Console ]
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 从左侧导航窗格中，选择**保管库**。
1. 在保管库详细信息页面中，将显示该保管库中的所有恢复点。在要复制的恢复点旁边打勾标记。
1. 选择**操作**，然后选择下拉菜单中的**复制**。
1. 在下一个屏幕上，输入目的地详细信息。
1. 指定目标区域。
1. 目的地备份保管库下拉菜单显示符合条件的目的地保管库。按类型 `logically air-gapped vault` 选择一个
1. 将所有详细信息设置为首选项后，选择**复制**。
在控制台的**作业**页面上，您可以选择**复制**作业以查看当前的复制作业。
------
#### [ AWS CLI ]
使用 [start-copy-job](https://amazonaws.com/aws-backup/latest/devguide/API_StartCopyJob.html) 将备份保管库中的现有备份复制到逻辑气隙保管库。
CLI 输入示例：
```
aws backup start-copy-job
--region us-east-1
--recovery-point-arn arn:aws:resourcetype:region::snapshot/snap-12345678901234567
--source-backup-vault-name sourcevaultname
--destination-backup-vault-arn arn:aws:backup:us-east-1:123456789012:backup-vault:destinationvaultname
--iam-role-arn arn:aws:iam::123456789012:role/service-role/servicerole
```
------
有关更多信息，请参阅[复制备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/recov-point-create-a-copy.html)、[跨区域备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/cross-region-backup.html)和[跨账户备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-cross-account-backup.html)。
## 共享逻辑上受物理隔离的保管库
您可以使用 AWS Resource Access Manager (RAM) 与您指定的其他账户共享逻辑上存在气隙的保管库。共享文件库时，加密密钥类型信息（AWS由所有或客户管理的 KMS 密钥）会保留，与之共享保管库的账户可见。
可以与同一组织内的账户共享保管库，也可以与其他组织内的账户共享保管库。不能与整个组织共享保管库，只能与组织内的账户共享。
只有具有特定 IAM 权限的账户才能共享和管理保管库共享。
要使用共享 AWS RAM，请确保您具备以下条件：
+ 两个或更多可以访问的账户 AWS Backup
+ 打算共享的拥有保管库的账户拥有必要的 RAM 权限。此过程需要权限 `ram:CreateResourceShare`。策略 `AWSResourceAccessManagerFullAccess` 包含所有必需的 RAM 相关权限：
+ `backup:DescribeBackupVault`
+ `backup:DescribeRecoveryPoint`
+ `backup:GetRecoveryPointRestoreMetadata`
+ `backup:ListProtectedResourcesByBackupVault`
+ `backup:ListRecoveryPointsByBackupVault`
+ `backup:ListTags`
+ `backup:StartRestoreJob`
+ 至少一个逻辑气隙保管库
------
#### [ Console ]
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 从左侧导航窗格中，选择**保管库**。
1. 保管库描述下方将显示两个列表，即**该账户拥有的保管库**和**与该账户共享的保管库**。该账户拥有的保管库有资格进行共享。
1. 在**保管库名称**下，选择逻辑气隙保管库的名称以打开详细信息页面。
1. **账户共享**窗格显示正在与哪些账户共享保管库。
1. 要开始与其他账户共享或编辑已共享的账户，请选择**管理共享**。
1. 选择 “**管理共享”** 后， AWS RAM 控制台将打开。有关使用 AWS RAM 共享资源的步骤，请参阅 RAM *用户指南*[中的在 AWS RAM 中AWS 创建资源共享](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)。
1. 受邀接受共享邀请的账户有 12 小时的时间接受邀请。请参阅《AWS RAM 用户指南》**中的[接受和拒绝资源共享邀请](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-invitations.html)。
1. 如果共享步骤已完成并被接受，则保管库摘要页面将显示在**账户共享 =“已共享 - 参见下面的账户共享表**”下方。
------
#### [ AWS CLI ]
AWS RAM 使用 CLI 命令`create-resource-share`。只有拥有足够权限的账户才能访问此命令。有关 CLI 步骤，请参阅[在 AWS RAM中创建资源共享](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html)。
第 1 步到第 4 步是使用拥有逻辑气隙保管库的账户执行的。第 5 步到第 8 步是使用将与之共享逻辑气隙保管库的账户执行的。
1. 登录所属账户，或者请求您组织中具有足够凭证的用户访问源账户，完成这些步骤。
1. 如果之前创建了资源共享，且您希望向其添加其他资源，请使用 CLI `associate-resource-share`，而不是新保管库的 ARN。
1. 获取具有足够权限的角色的凭证，以便通过 RAM 进行共享。[将这些输入到 CLI 中](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-quickstart.html#getting-started-quickstart-new)。
1. 此过程需要权限 `ram:CreateResourceShare`。该策略[AWSResourceAccessManagerFullAccess](https://console.aws.amazon.com/iamv2/home?region=us-east-1#/policies/details/arn%3Aaws%3Aiam%3A%3Aaws%3Apolicy%2FAWSResourceAccessManagerFullAccess)包含所有与 RAM 相关的权限。
1. 使用 [create-resource-share](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/create-resource-share.html)。
1. 包括逻辑气隙保管库的 ARN。
1. 输入示例：
```
aws ram create-resource-share
--name MyLogicallyAirGappedVault
--resource-arns arn:aws:backup:us-east-1:123456789012:backup-vault:test-vault-1
--principals 123456789012
--region us-east-1
```
1. 示例输出：
```
{
"resourceShare":{
"resourceShareArn":"arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543",
"name":"MyLogicallyAirGappedVault",
"owningAccountId":"123456789012",
"allowExternalPrincipals":true,
"status":"ACTIVE",
"creationTime":"2021-09-14T20:42:40.266000-07:00",
"lastUpdatedTime":"2021-09-14T20:42:40.266000-07:00"
}
}
```
1. 在输出中复制资源共享 ARN（后续步骤需要这样做）。将 ARN 交给您邀请接收共享的账户操作员。
1. 获取资源共享 ARN
1. 如果您没有执行第 1 步 resourceShareArn 到第 4 步，请向执行者索取。
1. 示例：`arn:aws:ram:us-east-1:123456789012:resource-share/12345678-abcd-09876543`
1. 在 CLI 中，假设接收账户的凭证。
1. 通过 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-share-invitations.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/get-resource-share-invitations.html) 获取资源共享邀请。有关更多信息，请参阅《AWS RAM 用户指南》**中的[接受和拒绝邀请](https://docs.aws.amazon.com/ram/latest/userguide/working-with-shared-invitations.html)。
1. 在目的地（恢复）账户中接受邀请。
1. 使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/accept-resource-share-invitation.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/accept-resource-share-invitation.html)（也可使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/reject-resource-share-invitation.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ram/reject-resource-share-invitation.html)）。
您可以使用 AWS RAM CLI 命令查看共享项目：
+ 已共享的资源：
`aws ram list-resources --resource-owner SELF --resource-type backup:backup-vault --region us-east-1`
+ 显示主体：
`aws ram get-resource-share-associations --association-type PRINCIPAL --region us-east-1`
+ 其他账户共享的资源：
`aws ram list-resources --resource-owner OTHER-ACCOUNTS --resource-type backup:backup-vault --region us-east-1`
------
## 从逻辑上受物理隔离的保管库中还原备份
您可以从拥有该保管库的账户或与之共享保管库的任何账户，还原存储在逻辑上受物理隔离的保管库中的备份。
有关如何通过 AWS Backup 控制台还原恢复点的信息，请参阅[还原备份](https://docs.aws.amazon.com/aws-backup/latest/devguide/restoring-a-backup.html)。
将备份从逻辑上受物理隔离的保管库共享到您的账户后，您可以使用 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/start-restore-job.html) 来还原备份。
示例 CLI 输入可能包括以下命令和参数：
```
aws backup start-restore-job
--recovery-point-arn arn:aws:backup:us-east-1:accountnumber:recovery-point:RecoveryPointID
--metadata {\"availabilityzone\":\"us-east-1d\"}
--idempotency-token TokenNumber
--resource-type ResourceType
--iam-role arn:aws:iam::number:role/service-role/servicerole
--region us-east-1
```
## 删除逻辑上受物理隔离的保管库
参阅[删除保管库](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault.html#delete-a-vault)。如果保管库仍包含备份（恢复点），则无法将其删除。在启动删除操作之前，请确保保管库中没有备份。
根据密钥删除策略，保管库删除操作还会在该保管库被删除七天后删除与该保管库关联的密钥。
以下示例 CLI 命令 [https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/backup/delete-backup-vault.html) 可用于删除保管库。
```
aws backup delete-backup-vault
--region us-east-1
--backup-vault-name testvaultname
```
## 逻辑上受物理隔离的保管库的其他编程选项
可以修改 CLI 命令 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html)，以列出该账户拥有和存在的所有保管库：
```
aws backup list-backup-vaults
--region us-east-1
```
要仅列出逻辑气隙保管库，请添加参数
```
--by-vault-type LOGICALLY_AIR_GAPPED_BACKUP_VAULT
```
包括用于筛选返回的保管库列表的参数 `by-shared`，以仅显示共享的逻辑上受物理隔离的保管库。响应将包括每个共享保管库的加密密钥类型信息。
```
aws backup list-backup-vaults
--region us-east-1
--by-shared
```
显示加密密钥类型信息的响应示例：
```
{
"BackupVaultList": [
{
"BackupVaultName": "shared-logically air-gapped-vault",
"BackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:shared-logically air-gapped-vault",
"VaultType": "LOGICALLY_AIR_GAPPED_BACKUP_VAULT",
"EncryptionKeyType": "AWS_OWNED_KMS_KEY",
"CreationDate": "2024-07-25T16:05:23.554000-07:00",
"Locked": true,
"MinRetentionDays": 7,
"MaxRetentionDays": 30
}
]
}
```
**注意**
在逻辑上隔开的保管库不可用的区域，API 响应中不包含该`VaultType`字段。
## 了解逻辑上存在气隙的保管库的加密密钥类型
从逻辑上讲，气隙保管库支持不同的加密密钥类型，这些信息可通过 AWS Backup APIs 控制台查看。通过 AWS RAM 或 MPA 共享文件库时，会保留加密密钥类型信息，并使与之共享保管库的账户可见。这种透明度有助于您了解保管库的加密配置，并就备份和还原操作做出明智的决策。
### 加密密钥类型值
该`EncryptionKeyType`字段可以有以下值：
+ `AWS_OWNED_KMS_KEY`-保管库使用 AWS自有密钥加密。如果未指定客户管理的密钥，则这是逻辑上空隙保管库的默认加密方法。
+ `CUSTOMER_MANAGED_KMS_KEY`-使用由您控制的客户管理的 KMS 密钥对保管库进行加密。此选项提供了对加密密钥和访问策略的额外控制。
**注意**
AWS Backup 建议将 AWS 拥有的密钥与逻辑上隔开的保管库一起使用。
如果您的组织政策要求使用客户托管密钥，则除了测试之外， AWS 不建议使用来自同一账户的密钥。对于生产工作负载，最佳做法是使用辅助组织中另一个账户的客户托管密钥，专门用于恢复。您可以参考博客 [Encrypt AWS Backup 带有客户管理密钥的逻辑气隙保管库](https://aws.amazon.com/blogs/storage/encrypt-aws-backup-logically-air-gapped-vaults-with-customer-managed-keys/)，以收集有关设置基于 CMK 的逻辑气隙保管库的更多见解。
您只能在创建保管库期间选择 AWS KMS 加密密钥。创建后，保管库中包含的所有备份都将使用该密钥进行加密。您不能更改或迁移您的保管库以使用不同的加密密钥。
### 创建 CMK 加密的逻辑空隙保管库的密钥策略
使用客户托管密钥创建逻辑上隔绝的保管库时，必须将 AWS-managed 策略应用`AWSBackupFullAccess`于您的账户角色。此策略包括 AWS Backup 允许在备份、复制和存储`Allow`操作期间与 AWS KMS KMS 密钥进行交互以创建授权的操作。此外，您必须确保您的客户托管密钥（如果使用）策略包含所需的特定权限。
+ 必须与逻辑上存在气隙的保管库所在的账户共享 CMK
```
{
"Sid": "Allow use of the key to create a logically air-gapped vault",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[account-id]:role/TheRoleToAccessAccount"
},
"Action": [
"kms:CreateGrant",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
}
```
**复制/恢复的密钥策略**
为防止任务失败，请查看您的 AWS KMS 密钥策略，确保其包含所有必需的权限，并且不包含任何可能阻止操作的拒绝语句。以下条件适用：
+ 对于所有复制方案，都 CMKs 必须与源副本角色共享
```
{
"Sid": "Allow use of the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Source copy role]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*",
"Condition": {
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
},
{
"Sid": "Allow AWS Backup to create grant on the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Source copy role]
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
},
"StringLike": {
"kms:ViaService": "backup.*.amazonaws.com"
}
}
}
```
+ 从 CMK 加密的逻辑空隙保管库复制到备份保管库时，还必须与目标账户 SLR 共享 CMK
```
{
"Sid": "Allow use of the key for copy from a CMK encrypted logically air-gapped vault to normal backup vault",
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole", //[Source copy role]
"arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow AWS Backup to create grant on the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::[source-account-id]:role/service-role/AWSBackupDefaultServiceRole", //[Source copy role]
"arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
```
+ 使用 RAM/MPA 共享的逻辑隔空保管库从恢复账户进行复制或还原时
```
{
"Sid": "Allow use of the key for copy/restore from a recovery account",
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::[recovery-account-id]:role/service-role/AWSBackupDefaultServiceRole", //[Recovery account copy/restore role]
"arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"] //[Destination SLR]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
},
{
"Sid": "Allow AWS Backup to create grant on the key for copy",
"Effect": "Allow",
"Principal": {
"AWS": ["arn:aws:iam::[recovery-account-id]:role/service-role/AWSBackupDefaultServiceRole" //[Recovery account copy/restore role]
"arn:aws:iam::[destination-account-id]:role/aws-service-role/backup.amazonaws.com/AWSServiceRoleForBackup"], //[Destination SLR]
},
"Action": [
"kms:CreateGrant"
],
"Resource": "*",
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
}
```
**IAM 角色**
在执行逻辑上隔开的保管库复制操作时，客户可以利用包含托 AWS管策略`AWSBackupDefaultServiceRole`的。`AWSBackupServiceRolePolicyForBackup`但是，如果客户更喜欢实施最低权限策略方法，则他们的 IAM 策略必须包括一项具体要求：
+ 源账户的复制角色必须同时具有源账户和目标账户的访问权限 CMKs。
```
{
"Version": "2012-10-17" ,
"Statement": [
{
"Sid": "KMSPermissions",
"Effect": "Allow",
"Action": "kms:DescribeKey",
"Resource": [
"arn:aws:kms:*:[source-account-id]:key/*", - Source logically air-gapped vault CMK -
"arn:aws:kms:*:[destination-account-id]:key/*". - Destination logically air-gapped vault CMK -
]
},
{
"Sid": "KMSCreateGrantPermissions",
"Effect": "Allow",
"Action": "kms:CreateGrant",
"Resource": [
"arn:aws:kms:*:[source-account-id]:key/*", - Source logically air-gapped vault CMK -
"arn:aws:kms:*:[destination-account-id]:key/*". - Destination logically air-gapped vault CMK -
]
"Condition": {
"Bool": {
"kms:GrantIsForAWSResource": "true"
}
}
},
]
}
```
因此，最常见的客户错误之一发生在复制过程中，客户未能为其 CMKs 和副本角色提供足够的权限。
### 查看加密密钥类型
您可以通过 AWS Backup 控制台查看加密密钥类型信息，也可以使用 AWS CLI 或 SDKs以编程方式查看加密密钥类型信息。
**控制台：**在控制 AWS Backup 台中查看逻辑上存在气隙的保管库时，加密密钥类型显示在保管库详细信息页面的安全信息部分下。
**AWS CLI/API：**在查询逻辑上存在气隙的保管库时，以下操作的响应中会返回加密密钥类型：
+ `list-backup-vaults`（包括`--by-shared`共享文件库）
+ `describe-backup-vault`
+ `describe-recovery-point`
+ `list-recovery-points-by-backup-vault`
+ `list-recovery-points-by-resource`
### 保管库加密的注意事项
在处理逻辑上存在气隙的保管库和加密密钥类型时，请考虑以下几点：
+ **创建期间的密钥选择：在创建**逻辑上隔绝的保管库时，您可以选择指定客户管理的 KMS 密钥。如果未指定，则将使用 AWS拥有的密钥。
+ **共享保管库可见性：**与之共享保管库的账户可以查看加密密钥类型，但不能修改加密配置。
+ **恢复点信息：**在逻辑上存在气隙的保管库中查看恢复点时，也可以使用加密密钥类型。
+ **还原操作：**了解加密密钥类型有助于您规划还原操作并了解任何潜在的访问要求。
+ **合规性：**加密密钥类型信息通过提供用于备份数据的加密方法的透明度，支持合规性报告和审计要求。
## 服务自有密钥的使用
AWS Backup 创建和管理加密密钥，这些密钥用于加密存储在逻辑气隙保管库中的所有备份数据，以保护和防止在数据丢失事件期间丢失对加密密钥的访问权限。
+ 这些密钥是免费的，不计入您账户的 AWS KMS 配额。
+ 单个密钥仅用于特定的保管库，不与任何其他账户或其他目的共享。
+ 一旦分配的（空）保管库也被删除，这些密钥就会被删除。
+ 这些密钥是使用 [SYMMETRIC\$1](https://docs.aws.amazon.com/kms/latest/developerguide/symm-asymm-choose-key-spec.html#symmetric-cmks) DEFAULT 密钥规范创建的。
+ 默认轮换政策为 90 天。您可以通过支持票请求轮换（每 6 个月一次）为逻辑上空隙的保管库轮换（每 6 个月一次）。
请访问[AWS KMS 文档](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html)以了解更多信息。
## 安全自动修复的注意事项
将 EC2 (AMI) 备份 AWS Backup 复制到逻辑上空隙的保管库时，它会暂时`launchPermission`（在 AMI 上）和`createVolumePermission`（在关联的 EBS 快照上）向服务拥有的账户授权。复制完成后，这些权限将自动撤销。
这些操作会在您的 AWS CloudTrail 日志中生成`ModifyImageAttribute``ModifySnapshotAttribute`事件，`userIdentity.invokedBy`设置为`backup.amazonaws.com`。
如果您有用于监控这些事件并撤消跨账户共享的安全自动修复逻辑（例如，Amazon EventBridge 规则 AWS Lambda），则必须将事件排除在外。`userIdentity.invokedBy` `backup.amazonaws.com`否则，将任务复制到逻辑上隔绝的保管库将失败，并显示：“您无权访问此 ami 的存储。”
这种排除是安全的，因为副本由您的文件库访问策略（`backup:CopyFromBackupVault`源文件库和`backup:CopyIntoBackupVault`目标文件库）授权，这些策略将在任何 EC2 属性修改发生之前进行评估。临时权限仅授予固定 AWS 服务拥有的账户，并在复制完成后自动撤销。
排除 AWS Backup 操作的 EventBridge 规则事件模式示例：
```
{
"source": ["aws.ec2"],
"detail-type": ["AWS API Call via CloudTrail"],
"detail": {
"eventSource": ["ec2.amazonaws.com"],
"eventName": ["ModifySnapshotAttribute", "ModifyImageAttribute"],
"userIdentity": {
"invokedBy": [{"anything-but": "backup.amazonaws.com"}]
}
}
}
```
## 解决逻辑上受物理隔离的保管库问题
如果工作流中出现错误，请查阅以下错误和建议解决方案的示例：
### `EC2 AMI copy job to logically air-gapped vault fails with permission error`
**错误**：`Copy job fails with "You do not have permission to access the storage of this ami."`
**可能的原因：**在将 EC2 AMI 复制到逻辑上空隙的保管库的任务中， AWS Backup 临时向服务拥有的账户授予启动权限 (AMI) 和创建卷权限（EBS 快照），从而在日志中生成`ModifyImageAttribute``ModifySnapshotAttribute`事件。 AWS CloudTrail 如果您有安全自动修复逻辑（例如使用 Lambda 的 EventBridge规则）来监控这些事件并自动撤消跨账户共享权限，则它可以在复制完成之前删除临时访问权限。
**注意**
对于其他资源（如 Amazon）的拷贝任务，同样也会发生这种情况 FSx。
**解决方案：**更新您的 EventBridge 规则事件模式以排除由执行的操作 AWS Backup。具体而言，排除事件`userIdentity.invokedBy`是`backup.amazonaws.com`为了确保您的自动修复逻辑不会撤消在复制过程中 AWS Backup 授予的临时跨账户权限。
### `AccessDeniedException`
**错误**：`An error occured (AccessDeniedException) when calling the [command] operation: Insufficient privileges to perform this action."`
**可能的原因：**在 RAM 共享的保管库上运行以下请求之一时未包括参数 `--backup-vault-account-id`：
+ `describe-backup-vault`
+ `describe-recovery-point`
+ `get-recovery-point-restore-metadata`
+ `list-protected-resources-by-backup-vault`
+ `list-recovery-points-by-backup-vault`
**解决方案：**重试返回错误的命令，但要包括指定拥有该保管库的账户的参数 `--backup-vault-account-id`。
### `OperationNotPermittedException`
**错误：**在 `CreateResourceShare` 调用后返回 `OperationNotPermittedException`。
**可能的原因：**如果您尝试与其他组织共享资源（例如逻辑上受物理隔离的保管库），则可能会出现此异常。保管库可以与其他组织内的账户共享，但不能与其他组织本身共享。
**解决方案：**重试该操作，但指定一个账户（而不是组织或 OU）作为 `principals` 的值。
### 未显示加密密钥类型
**问题：**查看逻辑上存在气隙的保管库或其恢复点时，加密密钥类型不可见。
**可能的原因：**
+ 您正在查看在添加加密密钥类型支持之前创建的较旧保管库
+ 您使用的是 AWS CLI 或 SDK 的旧版本
+ API 响应不包含加密密钥类型字段
**解决方法：**
+ AWS CLI 将你的版本更新到最新版本
+ 对于较旧的保管库，加密密钥类型将自动填充并应出现在后续的 API 调用中
+ 验证您使用的是返回加密密钥类型信息的 API 操作是否正确
+ 对于共享文件库，请验证保管库是否已通过正确共享 AWS Resource Access Manager
### CloudTrail 日志 AccessDeniedException 中 VaultState 有 “失败”
**错误在 CloudTrail：**`"User: is not authorized to perform: kms:CreateGrant on this resource because the resource does not exist in this Region, no resource-based policies allow access, or a resource-based policy explicitly denies access"`
**可能的原因：**
+ 文件库是使用客户托管密钥创建的，但代入的角色没有使用该密钥创建文件库所需的密钥策略的 CreateGrant 权限
**解决方法：**
+ 授予该[创建 CMK 加密的逻辑空隙保管库的密钥策略](#key-policy-lag-vault-creation)部分中指定的权限，然后重试文件库创建工作流程。
# 目标为逻辑上受物理隔离的保管库的主备份
## 概述
逻辑空隙保管库主备份功能使您可以选择将逻辑上空隙的保管库指定为同一账户内的主备份目标，用于定时备份和按需备份任务。这样就无需在标准备份保管库和逻辑气隙保管库中维护单独的副本，从而降低了成本并简化了工作流程，同时保留了逻辑气隙的安全优势。
在备份计划、组织范围的策略或按需备份中，您可以将逻辑上空隙的保管库指定为主要目标。以前，要备份到逻辑上存在气隙的保管库，您首先必须在备份保管库中创建备份，然后将其复制到逻辑上空隙的保管库中。使用此功能，根据资源类型， AWS Backup 可以直接在逻辑上空隙的保管库中创建备份，或者自动管理复制到逻辑上空隙保管库然后删除的临时备份。
行为取决于两个因素：
+ 逻辑上空隙存储库是否支持资源类型。
+ 资源类型是否支持[完全 AWS Backup 管理](https://docs.aws.amazon.com/aws-backup/latest/devguide/whatisbackup.html#full-management)。
**警告**
如果您采用多方批准 (MPA) 功能，我们建议您将逻辑上的气隙保管库与[多方批准](https://docs.aws.amazon.com/aws-backup/latest/devguide/multipartyapproval.html) (MPA) 集成。即使无法访问拥有文件库的帐户，也可以恢复保管库中的备份。
此功能没有新的定价。您只需为存储在逻辑空隙存储库中的备份以及按现行费率为适用资源的临时快照（在系统中的保留期内）付费。有关详细信息，请参阅[AWS Backup 定价](https://aws.amazon.com/backup/pricing/)。
**Topics**
+ [概述](#lag-primary-backup-overview)
+ [工作原理](#lag-primary-backup-how-it-works)
+ [成本注意事项](#lag-primary-backup-cost)
+ [配置逻辑上空隙的保管库主备份](#lag-primary-backup-configure)
+ [监控逻辑上空隙的保管库主备份](#lag-primary-backup-monitor)
+ [入职和迁移](#lag-primary-backup-onboarding)
+ [问题排查](#lag-primary-backup-troubleshooting)
## 工作原理
您可以通过更新现有备份计划或创建新的备份计划并添加逻辑上空隙的保管库 ARN（字段名:`TargetLogicallyAirGappedBackupVaultArn`）作为主备份目标来加入此功能。您可以通过 AWS Backup 控制台或 AWS Backup CLI 命令执行此操作。
```
"TargetLogicallyAirGappedBackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:AirGappedVault",
```
将备份保管库和逻辑上空隙的保管库指定为备份任务的目标时，将根据资源类型和加密配置 AWS Backup 确定适当的工作流程。
![\[alt text not found\]](http://docs.aws.amazon.com/zh_cn/aws-backup/latest/devguide/images/lag-vault-primary-backup-execution.png)
**支持将主备份到逻辑上空隙的保管库的资源**
要查看逻辑空隙保管库支持资源的完整列表，[请参阅 AWS Backup](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-for-all-resources)功能可用性。在使用此功能时，所有支持逻辑气隙保管库的资源都遵循的原则，即仅维护备份的一个副本，而不是存储两个单独的副本。
**警告**
目前不支持此功能的资源将来可能会启用其支持。发生这种情况时，您新支持的资源将使用上面显示的工作流程自动开始在逻辑上空隙的保管库中进行备份。
**注意事项和限制：**
+ **仅限相同的账户和区域** — 逻辑上存在空隙的保管库必须与您的资源位于相同的 AWS 账户和区域才能使用此功能。您不能直接跨账户或跨区域创建备份。我们建议备份到同一区域中逻辑上存在气隙的保管库，这样无需复制即可更快地恢复。如果您需要在第二个区域复制数据以进行灾难恢复 (DR)，我们建议您跨区域复制主要资源以实现快速故障转移，或者将跨区域恢复点复制到锁定的备份保管库。
+ **使用 AWS 托管密钥的限制**-无法将不支持完全 AWS Backup 管理且使用 AWS 托管密钥加密的资源（例如`aws/ebs`，`aws/rds`）复制到逻辑上存在气隙的保管库。这些资源必须使用客户托管的 KMS 密钥进行加密或解密。支持全面 AWS Backup 管理的资源**没有此限制。**
+ **备份频率和并发副本** — 对于不支持完全 AWS Backup 管理的资源，请确保备份频率有足够的时间完成副本。如果计划备份的频率高于副本完成的频率，则拷贝作业将排队并最终可能会失败。有关并发复制限制的指导，[请参阅配额](aws-backup-limits.md#lag-vault-quotas-table)。
+ **生命周期兼容性**-备份计划中指定的保留期必须与为逻辑上隔绝的保管库配置的最小和最大保留期限兼容。
+ 已@@ **锁定的备份存储库**-如果您的目标备份存储库启用了文件库锁定，则无法手动删除临时恢复点，这些恢复点将一直保留到复制完成或保留期到期。
+ **恢复测试、索引和扫描** — 还原测试、恢复点索引和恶意软件扫描将忽略`DELETE_AFTER_COPY`生命周期中的临时恢复点。恢复点索引不支持逻辑上存在气隙的保管库中的恢复点。恶意软件扫描不支持对复制的恢复点进行计划扫描，包括作为主备份的一部分自动复制到逻辑上空隙的保管库。
### 支持全面 AWS Backup 管理的资源
某些支持完全管理的资源类型，例如支持 AWS Backup 完全管理的 Amazon EFS、Amazon S3、[AWS Backup 具有高级](https://docs.aws.amazon.com/aws-backup/latest/devguide/advanced-ddb-backup.html)功能的 Amazon DynamoDB 等，可以直接备份到您的逻辑气隙保管库中。您的备份保管库中未创建恢复点，也无需执行复制操作。备份计划中的任何计划复制操作都使用逻辑上空隙的保管库中的恢复点作为来源。
支持持续备份的资源（例如 Amazon S3）也可以直接向逻辑上空隙的保管库执行连续备份。
有关支持完全 AWS Backup 管理和逻辑空隙保管库的资源类型列表，请参阅标有 “完全管理” 和 “逻辑空隙保管库” 的列中[按资源划分的功能可用性](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource)。
### 资源不支持完全 AWS Backup 管理
诸如亚马逊 EBS/EC2、Amazon Aurora 和亚马逊之类的资源 FSx 无法直接备份到逻辑上存在气隙的保管库。对于这些资源类型，在备份保管库中 AWS Backup 创建一个临时恢复点，然后自动将其复制到逻辑上存在气隙的保管库中。
临时恢复点有一个名为的特殊生命周期设置`DELETE_AFTER_COPY`。成功完成对逻辑隔断保管库的复制后， AWS Backup 会自动删除临时恢复点。备份计划中的所有其他计划复制操作都与复制到逻辑上隔绝的保管库并行开始，不会影响您当前的复制体验。
如果复制到逻辑上空隙的保管库失败，则临时恢复点将根据您指定的保留期保留在备份保管库中。这可以帮助您确保在备份任务完成后始终有一个可用的恢复点。如果稍后手动将恢复点复制到逻辑上存在气隙的保管库，则会根据规则自动将其清除。`DELETE_AFTER_COPY`
**警告**
不支持将使用 AWS 托管密钥加密的资源（例如`aws/ebs`）复制到逻辑上隔开的保管库。这些资源必须使用 AWS Key Management Service 客户管理的密钥进行加密或解密。支持全面 AWS Backup 管理的资源没有此限制。
#### 复制生命周期结束后删除
临时恢复点有一个名为的新生命周期属性`DeleteAfterEvent`，其值为`DELETE_AFTER_COPY`。此属性表示恢复点将在所有拷贝作业完成后或在您指定的保留期过后（以先到者为准）自动删除。
满足以下所有条件时，临时恢复点将被删除：
+ 所有自动和定时复印作业均已完成。
+ 您的目标存储库的复制任务已完成，其保留期至少与源恢复点一样长。
如果您需要防止在复制过程中手动删除临时恢复点，请考虑使用锁定的备份保管库作为目标备份存储库。
#### 对不支持完全 AWS Backup 管理的资源进行持续备份
对于诸如 Amazon Aurora 之类的资源，如果您启用连续备份，则会在您的备份库中 AWS Backup 创建一个持续恢复点，并拍摄临时快照，然后将其复制到逻辑上空隙的保管库中。无论复制成功还是失败，都应在复制完成后自动删除临时快照，因为您在备份存储库中保留了持续的恢复点。
如果您不想在备份保管库中为 Amazon Aurora 创建持续恢复点，但希望在逻辑隔绝的保管库中为 Amazon S3 创建持续恢复点，则可以在当前计划中禁用连续备份 (`EnableContinuousBackup`) 设置，并从其他计划中启用 S3 连续备份。
您可以在了解[亚马逊 Aurora 备份存储空间使用情况中了解有关 Aurora 备份存储](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/aurora-storage-backup.html#aurora-storage-backup.automated)的更多信息。
### 不支持的数据来源
如果某种资源类型不受逻辑间隙存储库的支持，或者使用托管密钥对非完全托管的资源进行加密，则仅在您的备份保 AWS 管库中 AWS Backup 创建备份。不会尝试复制到逻辑上存在气隙的保管库。备份任务成功完成，并显示一条消息，说明为什么备份没有进入逻辑上存在气隙的保管库。
## 成本注意事项
+ 此功能不会产生新的费用。您只需为保管库中的存储空间付费。
+ 对于支持完全 AWS Backup 管理的资源，与在备份保管库和逻辑上空隙的保管库中同时维护两个备份副本相比，仅在逻辑上存在气隙的保管库中维护备份可以节省大量成本。
+ 对于不支持完全 AWS Backup 管理的资源，您需要为备份保管库中的临时恢复点和逻辑上空隙的保管库中的恢复点付费。
+ 仅保留一个备份副本仍然可以显著节省成本，但是这些节省可能因备份频率和更改率而异。
+ 较低的备份频率通常会带来更大的节省，因为临时恢复点在计费周期中占用的存储空间比例较小。
+ 有些资源的计费期限最短，这会增加临时恢复点的成本。
+ 如果您不使用这些 S3 功能，请在备份配置中禁用标签或 ACLs 元数据检索。这减少了复制操作期间的 API 调用和元数据检查的相关费用。
## 配置逻辑上空隙的保管库主备份
您可以通过 AWS Backup 控制台、、或备份策略配置逻辑上空隙的保管库主 AWS Organizations 备份。 AWS CLI AWS CloudFormation
### 配置 Backup 计划
------
#### [ Console ]
**为备份计划配置逻辑上空隙的保管库主备份**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com//backup) 上打开 AWS Backup 控制台。
1. 在导航窗格中，选择 **Backup** plans，然后选择**创建备份计划**或选择要编辑的现有备份计划。
1. 在 **Backup 规则配置**部分，指定您的备份规则设置。
1. 对于 **Backup V** ault，请选择用于存储临时恢复点（对于非完全托管的资源）的备份保管库，或者如果无法将备份放置在逻辑上空隙的保管库中，则将其存储在哪里。
1. 对于**逻辑气隙保管库（可选）**，请选择要存储备份的逻辑气隙保管库。
**注意**
逻辑上存在空隙的保管库必须与您的备份保管库位于相同的账户和区域中。
1. 配置其余的备份规则设置，包括生命周期和复制选项。
1. 选择**创建计划**或**保存更改**。
------
#### [ AWS CLI ]
使用 CLI 命令[https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-cli](https://docs.aws.amazon.com/aws-backup/latest/devguide/creating-a-backup-plan.html#create-backup-plan-cli)创建新计划或[https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UpdateBackupPlan.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_UpdateBackupPlan.html)更新现有计划，并将`TargetLogicallyAirGappedBackupVaultArn`参数包含在备份规则中。
使用 JSON 文档创建备份计划的 CLI 命令示例：
```
aws backup create-backup-plan --cli-input-json file://PATH-TO-FILE/test-backup-plan.json
```
直接在 CLI 中创建备份计划的 CLI 命令示例：
```
aws backup create-backup-plan --backup-plan '{
"BackupPlanName": "MyPlan",
"Rules": [
{
"RuleName": "MyRule",
"TargetBackupVaultName": "MyBackupVault",
"TargetLogicallyAirGappedBackupVaultArn": "arn:aws:backup:us-east-1:123456789012:backup-vault:MyLagVault",
"ScheduleExpression": "cron(0 1 ? * * *)",
"ScheduleExpressionTimezone": "America/Los_Angeles",
"StartWindowMinutes": 60,
"CompletionWindowMinutes": 120,
"Lifecycle": {
"DeleteAfterDays": 35
}
}
]
}'
```
------
### 配置按需备份
------
#### [ Console ]
**为按需备份配置逻辑上空隙的保管库主备份**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com//backup) 上打开 AWS Backup 控制台。
1. 在导航窗格中，选择**受保护的资源**。
1. 在**受保护的资源**页面上，选择**创建按需备份**。
1. 选择要备份的资源类型和资源 ARN。
1. 对于 **Backup 保管库**，请选择备份保管库。
1. 对于**逻辑气隙保管库（可选）**，请选择要存储备份的逻辑气隙保管库。
1. 配置其余设置并选择**创建按需备份**。
------
#### [ AWS CLI ]
使用带有新`--logically-air-gapped-backup-vault-arn`参数的 start-backup-job命令：
```
aws backup start-backup-job \
--backup-vault-name MyBackupVault \
--logically-air-gapped-backup-vault-arn arn:aws:backup:us-east-1:123456789012:backup-vault:MyLagVault \
--resource-arn arn:aws:ec2:us-east-1:123456789012:volume/vol-abcd1234 \
--iam-role-arn arn:aws:iam::123456789012:role/service-role/AWSBackupDefaultServiceRole \
--lifecycle DeleteAfterDays=35
```
------
## 监控逻辑上空隙的保管库主备份
您可以使用 AWS Backup 控制台或 Amazon EventBridge 事件监控备份和复制任务的状态。 AWS CLI
### 监控 Backup 作业
监控备份任务状态 ([https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupJob.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupJob.html)) 以确保您的资源受到保护。备份任务失败表示未创建恢复点。
+ **验证恢复点的创建位置**-备份任务成功完成后，您的目标备份保管库或逻辑上存在气隙的目标保管库中就会有一个恢复点。选中该`BackupVaultArn`字段以确定恢复点的创建位置。
+ **验证任务状态**-如果逻辑上存在气隙的保管库不支持某个资源，则备份任务结束时会显示为，`LOGICALLY_AIR_GAPPED_BACKUP_VAULT_NOT_SUPPORTED`并显示一条状态消息，说明为何改为在备份保管库中创建备份。`MessageCategory`
+ **验证临时恢复点类型**-要检查恢复点是否为临时恢复点，请查找值为的`RecoveryPointLifecycle.DeleteAfterEvent`字段`DELETE_AFTER_COPY`。
### 监视拷贝作业
监控复制任务 ([https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html)) 到逻辑上空隙的保管库中是否出现故障。复印任务失败意味着您的恢复点仍保留在标准备份保管库中，而没有逻辑上的气隙保管库保护。
+ **验证复印作业状态**-您可以使用现有`Copy Job State Change` EventBridge 事件监视复印作业的状态。或者，对目标存储库 (`destinationBackupVaultArn`) 进行筛选，将重点放在逻辑上存在气隙的保管库副本上。
+ **验证源恢复点的副本**-使用带有新`BySourceRecoveryPointArn`筛选器的 [https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListCopyJobs.html)API 来查找与特定恢复点关联的所有拷贝作业，包括自动复制到逻辑上隔空的保管库和到其他目的地的计划副本。
+ **验证临时恢复点的删除**-跟踪临时恢复点删除的完成情况。如果拷贝作业状态为`RUNNING`，则恢复点尚未被删除。如果逻辑上存在气隙的保管库的副本有`FAILED`，则恢复点将在您指定的保留期内保留。
**注意**
复印任务记录将在完成 30 天后过期并被删除。在此时间段之后，您将无法使用`ListCopyJobs`来确定历史副本状态。
### 监控恢复点
监控`EXPIRED`恢复点 ([https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListRecoveryPointsByBackupVault.html))，这可能表示 AWS Backup 无法将其删除（可能是由于缺少权限）。 `EXPIRED`恢复点可能会产生成本影响。
+ **验证恢复点状态**-使用现有的恢复点状态更改 EventBridge 事件来监控过期情况。
+ **验证是否删除了临时恢复点**-如果`DeleteAfterEvent: DELETE_AFTER_COPY`尚未删除带有的恢复点，请使用 `ListCopyJobs` API 确定原因，如上所述。
## 入职和迁移
如果您当前使用复制操作将备份复制到逻辑上空隙的保管库，则可以迁移到逻辑上空隙的保管库主备份以降低成本。您还可以将现有 Amazon S3 连续备份从备份库迁移到逻辑上存在气隙的保管库。本指南说明了迁移到逻辑上空隙的保管库主备份功能所需的先决条件和步骤。
### 先决条件和最佳实践
在有效使用逻辑上空隙的保管库主备份功能之前，需要先满足先决条件和推荐的最佳实践。
**先决条件**
当前，作为主备份目标的逻辑空隙保管库仅支持与您的备份资源位于同一 AWS 账户和 AWS 区域内的备份。从逻辑上讲，空隙保管库备份本质上存储在不同的服务账户中，无需将副本复制到单独的账户即可提供跨账户/跨组织隔离。如果您需要跨区域备份，请继续使用逻辑上空隙的保管库作为复制目标。在迁移到此功能之前，请确保满足以下要求：
+ **地区和账户要求**
+ 您的逻辑隔空保管库必须与您的资源位于同一个 AWS 账户和区域中
+ **资源兼容性**
+ 在 “按资源划分的[功能可用](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource)性” 中，验证您的资源是否受逻辑空隙保管库的支持。
+ 检查您的资源是否支持[完全 AWS Backup 管理](https://docs.aws.amazon.com/aws-backup/latest/devguide/backup-feature-availability.html#features-by-resource)。这两种类型的资源之间创建气隙备份的体验有所不同，尽管两者的结果相似。
+ **加密要求**
+ 不支持完全 AWS Backup 管理的资源必须未加密或使用客户托管密钥加密（CMKs）。 AWS 逻辑气隙保管库不支持托管密钥 (AMK) 加密资源。
**最佳实践**
+ 从试点迁移非关键资源开始。
+ 根据复印作业的性能查看和调整备份频率。
+ 在完全迁移之前实施全面监控。
+ 定期验证在目标文件库中创建的恢复点。
### 规划您的迁移
+ 查看现有的备份计划和策略。
+ 确定哪些资源支持全面 AWS Backup 管理，哪些不支持。
+ 支持完全 AWS Backup 管理的资源（例如 EFS、S3）-可以直接备份到逻辑上空隙的保管库
+ 不支持完全 AWS Backup 管理的资源（例如 EC2、EBS 等 FSx）-需要在备份保管库中进行临时备份，然后才能复制到逻辑上空隙的保管库
+ 查看您当前的备份量和频率，并确保您的配置符合所有不支持完全 AWS Backup 管理的资源的并发复制限制。
+ 如果您已经以与标准保管库备份相同的频率复制到逻辑上存在气隙的保管库，请跳过此步骤。
+ 如果需要，可以考虑调整备份频率，以防止复印作业排队。
+ 如果出现复印任务排队，则在等待完成复制到逻辑上空隙的保管库时，标准备份保管库中仍将有一个可用的恢复点。但是，该恢复点无法提供逻辑气隙保管库所提供的保护级别。
### 支持完整 AWS Backup 管理迁移路径的资源
对于完全托管的资源，您可以直接备份到逻辑上空隙的保管库，而无需执行复制操作。
#### 用于基于快照的备份
此过程适用于所有快照方案，无论您的备份保管库是否已锁定。迁移现有备份计划或在新备份计划中使用现有的备份存储库（主存储库）和逻辑隔空保管库（副本）时：
1. 维护现有的备份保管库或将其添加为备份目标 (`TargetBackupVaultName`)。此保管库不会存储任何备份，但必须提供该保管库以实现向后兼容。
1. 更新您的备份计划，将存在于同一账户中的逻辑空隙保管库 (`TargetLogicallyAirGappedBackupVaultArn`) 作为主要目标。
1. 查看向另一个逻辑上隔绝的保管库执行的任何现有复制操作，以确定是否仍然需要该操作。如果此保管库位于同一个账户中，您也可以在步骤 2 中将其作为主要目标进行移动。
#### 对于 Amazon S3 持续备份
作为主要备份目标的逻辑间隙保管库支持 Amazon S3 的持续备份。但是，您只能在单个存储库中为每个资源维护一个活跃的持续恢复点。如果您已有处于活动状态的 Amazon S3 持续恢复点，则必须先取消关联或删除该恢复点，然后才能在其他保管库中创建新的恢复点。在备份计划中添加逻辑上空隙的保管库目标（来自同一个账户），并具有现有活跃的 Amazon S3 持续恢复点，将导致持续备份任务失败。
要将您的 Amazon S3 持续恢复点从**解锁的备份**保管库迁移到逻辑上存在气隙的保管库，请执行以下操作：
1. 更新您的备份计划，将复制操作添加到逻辑上空隙的保管库中。这将降低在逻辑上存在气隙的保管库中生成初始备份的成本。如果您已经在复制到逻辑上存在气隙的本地保管库，请跳过此步骤。
1. 在继续操作之前，请确认逻辑上存在气隙的保管库中至少有一个快照副本成功完成。
1. 取消关联现有 Amazon S3 持续恢复点。调用 [DisassociateRecoveryPoint](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DisassociateRecoveryPoint.html)API 将恢复点状态从 “可用” 更改为 “已停止”。此操作可保留您现有的备份数据，同时阻止添加新数据。
1. 更新备份计划以添加逻辑上空隙的保管库 (`TargetLogicallyAirGappedBackupVaultArn`) 作为备份目标。
1. 移除计划中之前的所有复制操作。
1. 在下次执行备份计划时，将在逻辑上空隙的保管库中创建一个新的持续恢复点。根据步骤 1 中复制的快照，此恢复点将是增量的。
要将您的 Amazon S3 持续恢复点从**锁定的备份**库迁移到逻辑上存在气隙的保管库，请执行以下操作：
1. 更新您的备份计划，将复制操作添加到逻辑上空隙的保管库中。这将降低在逻辑上存在气隙的保管库中生成初始备份的成本。如果您已经在复制到逻辑上存在气隙的本地保管库，请跳过此步骤。
1. 在继续操作之前，请确认逻辑上存在气隙的保管库中至少有一个快照副本成功完成。确保复制的快照的保留期足够长，以便在完成所有步骤之前保持可用。
1. 将逻辑上存在气隙的保管库添加为主要目标，并移除所有复制操作。
1. 此步骤是必需的，因为锁定的电子仓库不支持取消连续恢复点的关联。
1. 您在锁定的备份保管库中现有的持续恢复点将继续累积数据，直到数据过期，具体取决于其生命周期。
1. 新的连续备份任务将失败，因为每个资源只能存在一个活动的连续恢复点。由于这些作业失败，因此不会执行任何复制操作。
1. 等待现有的持续恢复点到期。到期后，将在逻辑上存在气隙的保管库中创建一个新的持续恢复点。此恢复点将基于步骤 1 中复制的快照进行增量恢复，前提是该快照仍存在于逻辑上空隙的保管库中。
1. 标准保管库中积累的所有数据将在到期时丢失。只有在逻辑气隙保管库中创建新的恢复点后备份的数据才会被保留。
### 资源不支持完整 AWS Backup 管理迁移路径
非完全托管的资源需要对逻辑上存在气隙的存储库执行复制操作。该过程会在您的标准备份保管库中创建一个临时恢复点（可计费），该恢复点会自动复制到逻辑上空隙的保管库，然后在复制完成后将其删除。当您更新备份计划以包含逻辑上空隙的存储库目标时：
+ Backup 任务将在您的备份保管库中创建一个恢复点。其生命周期由`DELETE_AFTER_COPY`事件决定。
+ 复印任务会自动启动将恢复点传输到逻辑上存在气隙的保管库。
+ 成功完成复制后，将删除保管库中的临时恢复点。
+ 如果复制失败，则临时恢复点将根据您指定的保留期限保留最长时间，从而确保您有可用的恢复点。
## 问题排查
### Backup 或复印作业因生命周期不兼容错误而失败
**备份任务出错：**`Backup job failed because the lifecycle is outside the valid range for backup vault.`
**复印作业出错：**`Copy job failed. The retention specified in the job is not within the range specified for the target Backup Vault.`
**可能的原因：**由于保留期与逻辑上隔绝的保管库的最小或最大保留期设置不兼容，备份任务或复印任务失败。
**解决方案：**更新您的备份计划，以指定一个保留期，该保留期不超过为逻辑上空隙的保管库配置的最小和最大保留期。
### 连续备份作业失败，并显示 “已启用连续备份”
**错误**：`Bucket {bucket_name} already has continuous backup enabled for another vault Backup job failed.`
**可能的原因：**连续备份任务失败，因为另一个保管库中的资源已经有一个持续的恢复点。
**解决方案：**每种资源只能有一个连续恢复点。如果您的备份保管库已解锁，请使用[disassociate-recovery-point](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DisassociateRecoveryPoint.html)命令取消关联现有的持续恢复点。如果您的备份保管库已锁定，请根据其生命周期等待，直到现有的持续恢复点到期。
### Backup 作业完成时显示 “已完成，但存在问题”-资源类型不支持
**消息**：`Backup job completed successfully to the target backup vault. This resource type is not supported by logically air-gapped backup vault.`
**可能的原因：**不受支持的非完全托管资源的备份任务显示 “已完成，但存在问题”，并显示一条消息，表明该资源不受支持。
**解决方案：**不支持的资源类型只会备份到备份保管库。如果您想将这些备份保留在备份保管库中，则无需执行任何操作。如果您不想将不支持的资源与逻辑上存在气隙的保管库混用，则可以：
+ 从这些资源的备份计划中移除资源或逻辑上存在空隙的存储库目标，然后继续仅备份到您的备份保管库。随后，您可以将该资源作为其他计划的一部分进行添加。
### Backup 作业完成时显示 “已完成，但存在问题”-加密密钥不支持
**消息**：`Backup job completed successfully to the target backup vault. This resource is encrypted with an AWS managed key and cannot be copied to a logically air-gapped backup vault.`
**可能的原因：**不受支持的非完全托管资源的备份任务显示 “已完成，但存在问题”，并显示一条消息，表明该资源已使用 AWS 托管密钥加密。
**解决方案：**使用托管密钥加密的非完全 AWS 托管资源无法复制到逻辑上存在气隙的保管库。如果您想将这些备份保留在备份保管库中，则无需执行任何操作。如果您不想将不支持的资源与逻辑上存在气隙的保管库混用，则可以：
+ 使用客户托管的 KMS 密钥重新加密您的资源，或者
+ 从这些资源的备份计划中移除资源或逻辑上存在空隙的存储库目标，然后继续仅备份到您的备份保管库。随后，您可以将该资源作为其他计划的一部分进行添加。
### 恢复点保持`EXPIRED`状态
**可能的原因：**临时恢复点变为`EXPIRED`状态但未被删除。
**解决方案：** AWS Backup 可能缺少删除恢复点的权限。验证您的备份角色是否具有必要的 IAM 权限。您可能需要手动删除`expired`恢复点。
### 由于备份频率高，拷贝作业排队或失败
**可能的原因：**由于计划备份的频率高于副本完成的频率，因此复制到逻辑上空隙的保管库的任务正在排队或失败。
**解决方案：**降低备份频率或调整备份计划，以便在两次备份之间留出更多时间。有关并发副本限制的信息，请参阅[AWS Backup 配额文档](aws-backup-limits.md#lag-vault-quotas-table)。
# 逻辑上受物理隔离的保管库的多方审批
## 逻辑上受物理隔离的保管库中的多方审批概述
AWS Backup 为您提供向逻辑隔绝的保管库添加[多方批准](https://docs.aws.amazon.com/mpa/latest/userguide/what-is.html)的选项，该功能来自于 AWS Organizations逻辑隔绝的保管库。多方审批提供一个额外的选项，可通过分布式审批流程帮助保护关键操作。
多方审批旨在帮助保护关键资源，并最大限度地缩短恢复全面运行的时间，例如恶意行为者或恶意软件事件造成的中断。此设置可以帮助您还原可能已被损坏的逻辑上受物理隔离的保管库中的内容。
集成和结合使用多方审批团队与 AWS Backup 逻辑上受物理隔离的保管库无需支付额外费用（如[定价](https://aws.amazon.com/backup/pricing)页面所示，亚马逊将收取存储和跨区域传输费用）。
作为 AWS Backup 客户，您可以使用多方批准将某些操作的批准权限授予一组受信任的个人，如果怀疑存在可能影响主账户使用的恶意活动，他们可以协作批准从单独创建的恢复账户访问逻辑上空隙的保管库。
以下步骤概述了设置恢复 AWS 组织，设置多方审批，然后结合使用多方审批和逻辑上受物理隔离的保管库的建议流程：
1. 管理员[通过 Organizations 创建一个新组织](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_getting-started.html)用于执行恢复操作。
1. 在这个新组织的管理账户中，管理员创建并配置一个 IAM Identity Center（IDC）实例（要启用组织实例，请参阅《IAM Identity Center 用户指南》**中的[启用 IAM Identity Center](https://docs.aws.amazon.com/singlesignon/latest/userguide/enable-identity-center.html)）。另请参阅《多方审批用户指南》**中的[创建多方审批身份源](https://docs.aws.amazon.com/mpa/latest/userguide/setting-up.html)，了解操作顺序。
1. 然后，管理员将[创建一个审批团队](https://docs.aws.amazon.com/mpa/latest/userguide/create-team.html)，这个核心小组由可信任的个人组成，他们将是多方审批的主要用户。
1. 管理员使用 AWS RAM 与每个拥有逻辑上隔绝的保管库的账户以及需要请求访问该保管库的恢复账户[共享一个审批小组](multipartyapproval-tasks-administrator.md#share-multipartyapproval-team-using-ram)。
1. 逻辑上存在气隙的保管库拥有账户的管理员[将该文件库与审批小组关联起来](multipartyapproval-tasks-requester.md#associate-multipartyapproval-team)。
1. 恢复账户[请求访问](multipartyapproval-tasks-requester.md#create-restore-access-vault)一个账户，该账户的逻辑上受物理隔离的保管库与多方审批团队（简称“团队”）相关联。与该账户关联的团队[批准或拒绝请求](https://docs.aws.amazon.com/mpa/latest/userguide/respond-request.html)。
1. 拥有逻辑上受物理隔离的保管库的账户的管理员可以请求[取消审批团队与保管库的关联](multipartyapproval-tasks-requester.md#disassociate-multipartyapproval-team)。请求需要当前团队的批准。
1. 管理员可以在必要时根据其安全实践或者在人员加入或离开组织时[更新审批团队成员资格](https://docs.aws.amazon.com/mpa/latest/userguide/update-team.html)。
## 结合使用多方审批和逻辑上受物理隔离的保管库的先决条件和最佳实践
您需要具备先决条件并遵循建议的最佳实践，才能有效且安全地结合使用多方审批和逻辑上受物理隔离的保管库。
**最佳实践：**
+ 通过 Organizations 创建两个（或更多） AWS 组织。一个应该是主组织，在这个组织中，您的一个或多个账户拥有至少一个逻辑上受物理隔离的保管库。辅助组织应该是恢复组织。多方审批团队将在这个组织中进行管理。
**先决条件**
1. 您已[设置多方审批](https://docs.aws.amazon.com/mpa/latest/userguide/setting-up.html)，并且拥有至少一个审批团队。
1. 主组织中至少有一个账户必须拥有逻辑上受物理隔离的保管库（以及原始备份保管库）。
1. 主组织中的管理账户可以选择加入多方审批。
**提示**
AWS Backup 建议您将服务控制策略 (SCP) 应用于您的主要组织，并使用该组织和每个审批小组的相应权限对其进行配置。有关示例策略，请参阅[多方审批术语](#multipartyapproval-terms)部分。
1. 辅助（恢复）组织中的多方审批团队与拥有逻辑上受物理隔离的保管库的账户和恢复账户[通过 AWS RAM共享](multipartyapproval-tasks-administrator.md#share-multipartyapproval-team-using-ram)。
## 使用多方审批时的跨区域注意事项和依赖项
当您在不同的区域中启用多方审批和 IAM Identity Center 实例时，多方审批会跨区域调用 IAM Identity Center。这意味着用户和组信息会跨区域移动。多方审批团队资源只能 AWS 区域 在美国东部（弗吉尼亚北部）创建和存储。
其他 AWS 区域 参考多方审批团队资源的内容将取决于 AWS 区域 美国东部（弗吉尼亚北部）。因此，如果您的 Identity Center 实例 and/or 逻辑上存在空隙的保管库不在美国东部（弗吉尼亚北部），则多方批准将进行跨区域调用。
## 多方审批术语、概念和用户角色
逻辑上隔绝的保管库中的多方批准是 AWS Organizations AWS 账户管理 AWS Backup、和以及 AWS Identity and Access Management (IAM) 和 AWS RAM (RAM) 功能的集成。通过 CLI，您可以与每项服务交互以发送相应的命令。您也可以使用控制台，但需要导航到相应服务的控制台才能完成特定任务。
您与多方批准的互动方式取决于您在组织中的角色和职责，以及您在 AWS Backup 账户中拥有的权限。
如[《多方审批用户指南》](https://docs.aws.amazon.com/mpa/latest/userguide/what-is.html)中所示，组织中使用多方审批的成员可以是***请求者***、***管理员***或***审批者***。特定权限应用于各项[工作职能](https://docs.aws.amazon.com/mpa/latest/userguide/mpa-concepts.html)。根据安全最佳实践，用户只能履行一项工作职能。
**控制台、门户和会话**
AWS Backup 拥有一个或多个逻辑空隙文件库的账户可以使用多方批准。
在多方批准流程之前，管理员会利用创建用于恢复目的的辅助组织（**恢复组织**）（前 AWS Organizations 提是之前尚未建立此类组织）。
然后，管理员利用 AWS Resource Access Manager (RAM) 在主组织和恢复组织之间建立跨组织共享。
**主组织**包含拥有并使用逻辑上受物理隔离的保管库（用于存储受保护的数据）的账户。
恢复组织包含至少一个**恢复账户**。该账户具有一个接入点，该接入点可以作为共享逻辑上受物理隔离的保管库的关键“后门”。该接入点称为**恢复访问权限备份保管库**。此访问权限保管库不存储数据，而是充当接入点或挂载点，用于针对源逻辑上受物理隔离的保管库的内容执行镜像操作，但不包含可以更改或删除的数据。例如，如果客户在恢复访问权限备份保管库中执行恢复点的还原过程，则逻辑上受物理隔离的保管库中的恢复点将通过恢复账户利用跨账户还原进行还原。
为了确保获得额外的安全保护，客户使用此恢复账户在主账户中执行受保护的操作，但前提是这些操作获得了[审批会话中的关联审批团队](https://docs.aws.amazon.com/mpa/latest/userguide/mpa-concepts.html#mpa-resources)的批准。会话是在批准请求发送 AWS 后创建的，当批准团队成员达到批准或拒绝请求的阈值或允许的会话时间过后，该会话就会结束。
团队由**审批者**（实际上是多方审批的*各方*部分）组成，他们会收到有关受保护操作请求的电子邮件通知。这些电子邮件确认针对请求的审批会话已开始。一旦达到规定的所需最低批准人数，便会获得批准。可以在创建**多方审批团队**（简称“团队”）时设置此规定人数。
多方审批团队通过 Organizations **多方审批门户**（“门户”） AWS 进行管理，该门户是一个托管应用程序，为身份提供一个集中的位置，审批团队成员可以在那里接收和回复审批小组的邀请和操作请求。
# 管理员任务
一些涉及 AWS Backup 和多方概述的任务需要具有管理员权限和管理账户访问权限的用户。
## 创建审批团队
贵组织中拥有 AWS 账户管理员权限的用户需要[设置多方批准](https://docs.aws.amazon.com/mpa/latest/userguide/setting-up.html)（[概述](multipartyapproval.md#multipartyapproval-overview)中的步骤 3）。
在执行此步骤之前，建议的最佳实践是通过 AWS Organizations 设置主组织和辅助组织（用于恢复目的）（[概述](multipartyapproval.md#multipartyapproval-overview)中的第 1 步）。
要创建团队，请参阅《多方审批用户指南》**中的[创建审批团队](https://docs.aws.amazon.com/mpa/latest/userguide/create-team.html#create-team-steps)。
在 [https://docs.aws.amazon.com/mpa/latest/APIReference/API_CreateApprovalTeam.html](https://docs.aws.amazon.com/mpa/latest/APIReference/API_CreateApprovalTeam.html) 操作过程中，其中一个参数是 `policies`。这是多方批准资源策略的 ARNs （Amazon 资源名称）列表，这些策略定义了保护团队的权限。
《多方审批用户指南》**中的[创建审批团队](https://docs.aws.amazon.com/mpa/latest/userguide/create-team.html#create-team-steps)步骤中的示例显示的策略包含具有多个必要权限的策略 `["arn:aws:mpa::aws:policy/backup.amazonaws.com/CreateRestoreAccessVault"]`。
按照以下步骤使用 `mpa list-policies` 返回可用策略列表：
1. 列出策略：
```
aws mpa list-policies --region us-east-1
```
1. 列出所有策略版本：
```
aws mpa list-policy-versions --policy-arn arn:aws:mpa:::aws:policy/backup.amazonaws.com/CreateRestoreAccessVault --region us-east-1
```
1. 获取有关策略的详细信息：
```
aws mpa get-policy-version --policy-version-arn arn:aws:mpa:::aws:policy/backup.amazonaws.com/CreateRestoreAccessVault/1 --region us-east-1
```
展开下方，查看此操作将创建并附加到审批团队的策略：
### 恢复访问权限保管库策略
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "VaultOwnerPermissions",
"Effect": "Allow",
"Principal": {
"AWS": "*"
},
"Resource": "*",
"Action": [
"mpa:StartSession",
"mpa:CancelSession"
],
"Condition": {
"StringEquals": {
"mpa:RequestedOperation": "backup:RevokeRestoreAccessBackupVault",
"mpa:ProtectedResourceAccount": "${aws:PrincipalAccount}"
},
"Bool": {
"aws:ViaAWSService": "true"
}
}
}
]
}
```
------
## 使用共享多方审批团队 AWS RAM
您可以使用 [AWS Resource Access Manager (RAM)](https://docs.aws.amazon.com/ram/latest/userguide/working-with-sharing-create.html) [概述](multipartyapproval.md#multipartyapproval-overview)中的步骤 4 与其他 AWS 账户共享多方审批团队。
------
#### [ Console ]
**使用共享多方审批团队 AWS RAM**
1. 登录 [AWS RAM 控制台](https://console.aws.amazon.com/ram/home?region=us-east-1)。
1. 在导航窗格中，选择**资源共享**。
1. 选择**创建资源共享**。
1. 对于**名称**字段，输入资源共享的描述性名称。
1. 在**资源类型**下，从下拉菜单中选择**多方审批团队**。
1. 在**资源**下，选择要共享的审批团队。
1. 在 “**委托人**” 下，指定要与之共享审批团队的 AWS 账户。
1. 要与特定 AWS 账户共享，请选择**AWS 账户**并输入 12 位数的账户 IDs。
1. 要与组织或组织单元共享，请选择**组织**或**组织单元**并输入相应的 ID。
1. （*可选*）在**标签**下，添加要与此资源共享关联的所有标签。
1. 选择**创建资源共享**。
资源共享状态最初将显示为 `PENDING`。接收方账户接受邀请后，状态将更改为 `ACTIVE`。
------
#### [ CLI ]
要 AWS RAM 通过 CLI 共享多方审批团队，请使用以下命令：
首先，确定要共享的审批团队的 ARN：
```
aws mpa list-approval-teams --region us-east-1
```
使用 create-resource-share以下命令创建资源共享：
```
aws ram create-resource-share \
--name "MPA-Team-Share" \
--resource-arns "arn:aws:mpa:us-east-1:ACCOUNT_ID:approval-team/TEAM_ID" \
--principals "ACCOUNT_ID_TO_SHARE_WITH" \
--permission-arns "arn:aws:ram::aws:permission/AWSRAMMPAApprovalTeamAccess" \
--region us-east-1
```
要与组织而不是特定账户共享，请执行以下操作：
```
aws ram create-resource-share \
--name "MPA-Team-Share" \
--resource-arns "arn:aws:mpa:us-east-1:ACCOUNT_ID:approval-team/TEAM_ID" \
--permission-arns "arn:aws:ram::aws:permission/AWSRAMMPAApprovalTeamAccess" \
--allow-external-principals \
--region us-east-1
```
检查资源共享的状态：
```
aws ram get-resource-shares \
--resource-owner SELF \
--region us-east-1
```
接收方账户需要接受资源共享邀请：
```
aws ram get-resource-share-invitations --region us-east-1
```
在接收方账户中运行以接受邀请：
```
aws ram accept-resource-share-invitation \
--resource-share-invitation-arn "arn:aws:ram:REGION:ACCOUNT_ID:resource-share-invitation/INVITATION_ID" \
--region us-east-1
```
接受邀请后，多方审批团队即可在接收方账户中使用。
------
AWS 提供共享账户访问权限的工具，包括通过[AWS Resource Access Manager](logicallyairgappedvault.md#lag-share)和[多方访问权限](https://docs.aws.amazon.com/mpa/latest/userguide/share-team.html)。当您选择与其他账户共享逻辑上受物理隔离的保管库时，请考虑以下细节：
| 功能 | AWS RAM 基于共享 | 基于多方审批的访问 |
| --- | --- | --- |
| 访问逻辑上受物理隔离的保管库 | RAM 共享完成后，便可以访问保管库。 | 其他账户的任何尝试都必须获得一定数量的多方审批团队成员的批准。审批会话将在请求启动 24 小时后自动过期。 |
| 访问权限移除 | 拥有逻辑上受物理隔离的保管库的账户可以随时结束基于 RAM 的共享。 | 要移除对保管库的访问权限，唯一的方法是向多方审批团队发送请求。 |
| 跨账户复制 and/or 区域 | 当前不支持。 | 可以在与恢复账户相同的账户或相同的组织中的其他账户中复制备份。 |
| 跨区域传输账单 | | 亚马逊向拥有恢复访问权限备份保管库的同一账户开具跨区域传输账单。 |
| 建议用途 | 主要用于数据丢失恢复和还原测试。 | 主要用于怀疑账户访问权限或安全性受到威胁的情况。 |
| 区域 | 适用于所有支持逻辑气隙保管库 AWS 区域 的地方。 | 适用于所有支持逻辑气隙保管库 AWS 区域 的地方。 |
| 恢复 | 所有支持的资源类型都可以从共享账户中还原。 | 所有支持的资源类型都可以从共享账户中还原。 |
| 设置 | 只要 AWS Backup 账户设置了 RAM 共享并且接收账户接受共享，就可以进行共享。 | 要进行共享，需要管理账户先创建团队，然后设置 RAM 共享。然后，管理账户选择加入多方审批，并将该团队分配到逻辑上受物理隔离的保管库。 |
| 共享 | 共享是通过 RAM 在同一个 AWS 组织内或跨 AWS 组织完成的。 访问权限是根据“推送”模型授予的，即拥有逻辑上受物理隔离的保管库的账户先授予访问权限。然后，其他账户接受访问权限。 | 通过同一 AWS 组织内或跨组织的 Organizations 支持的审批团队可以访问逻辑上空隙的保管库。 访问权限是根据“拉取”模型授予的，即接收账户先请求访问权限，然后审批团队批准或拒绝请求。 |
# 请求者任务
## 将多方审批团队与逻辑上隔绝的保管库关联起来
请求者：**有权访问拥有逻辑上受物理隔离的保管库的账户的用户**。
您可以将多方审批团队与逻辑上受物理隔离的保管库关联起来，以针对访问保管库的操作启用协作审批流程（[概述](multipartyapproval.md#multipartyapproval-overview)中的第 5 步）。
------
#### [ Console ]
**将多方审批团队与逻辑上隔绝的保管库关联起来**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在左侧导航窗格中，导航到**备份保管库**部分。
1. 选择要与 MPA 团队关联的逻辑上受物理隔离的备份保管库。
1. 在**保管库详细信息**页面上，选择**分配审批团队**。
1. 从下拉菜单中，选择要与保管库关联的审批团队
1. （*可选*）输入解释关联原因的备注。
1. 选择**发送请求**以提交关联请求。
如果这是第一个与保管库关联的审批团队，该团队将与保管库关联。如果保管库已有关联的团队，请参阅[更新多方审批团队](#update-multpartyapproval-team)了解相关步骤。
------
#### [ CLI ]
使用 CLI 命令 `associate-backup-vault-mpa-approval-team`，该命令用以下参数进行了修改：
```
aws backup associate-backup-vault-mpa-approval-team \
--backup-vault-name VAULT_NAME \
--mpa-approval-team-arn MPA_TEAM_ARN \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```
如果这是第一个与保管库关联的审批团队，该团队将与保管库关联。如果保管库已有关联的团队，请参阅[更新多方审批团队](#update-multpartyapproval-team)了解相关步骤。
------
## 请求访问逻辑上受物理隔离的保管库
请求者：**有权访问恢复账户的用户**。
您可以请求在其他账户中访问逻辑上受物理隔离的保管库（[概述](multipartyapproval.md#multipartyapproval-overview)中的第 6 步）。
审批小组批准请求后，在您指定的恢复账户中 AWS Backup 创建一个还原访问备份保管库，以便该账户可以访问连接的逻辑空隙保管库中的恢复点。
------
#### [ Console ]
**请求访问逻辑上受物理隔离的保管库**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在左侧导航窗格中，导航到**备份保管库**部分
1. 选择**可通过 MPA 访问的保管库**选项卡
1. 选择**申请保管库访问权限**。
1. 输入要访问的逻辑上受物理隔离的保管库的源备份保管库 ARN。
1. 输入恢复访问权限备份保管库的可选名称。如果您不输入名称，则 AWS Backup 将根据逻辑上存在空气间隙的保管库的名称分配一个名称。
1. 输入解释请求访问权限原因的请求者备注，此操作是可选的。
1. 选择**发送请求**以提交访问权限请求。
与源保管库关联的审批团队成员将收到有关批准请求的电子邮件通知。
请求获得所需数量（“规定人数”）的团队成员的批准后，系统将在恢复账户中创建恢复访问权限备份保管库。
------
#### [ CLI ]
使用 `create-restore-access-backup-vault` CLI 命令：
```
aws backup create-restore-access-backup-vault \
--source-backup-vault-arn SOURCE_VAULT_ARN \
--backup-vault-name OPTIONAL_VAULT_NAME \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```
与源保管库关联的 MPA 审批团队成员将收到有关批准请求的通知。请求获得所需数量（“规定人数”）的团队成员的批准后，系统将在恢复账户中创建恢复访问权限备份保管库。
您也可以使用以下方法查看保管库的状态：
```
aws backup describe-backup-vault \
--backup-vault-name VAULT_NAME \
--region REGION
```
------
## 取消多方审批团队与逻辑上受物理隔离的保管库的关联
请求者：**拥有逻辑上受物理隔离的保管库的账户的管理员**。
您可以取消多方审批团队与逻辑上受物理隔离的保管库的关联（[概述](multipartyapproval.md#multipartyapproval-overview)中的第 7 步）。
------
#### [ Console ]
**取消审批团队与逻辑上隔绝的保管库的关联**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在左侧导航窗格中，导航到**备份保管库**部分。
1. 选择要取消与审批团队关联的逻辑上受物理隔离的备份保管库。
1. 在**保管库详细信息**页面上，选择**取消关联审批团队**。
1. 输入解释取消关联原因的请求者备注，此操作是可选的。
1. 选择**发送请求**以提交取消关联请求。
当前的审批团队成员将收到有关批准请求的通知。
获得所需数量的团队成员的批准后，系统将取消审批团队与保管库的关联。
------
#### [ CLI ]
使用 `disassociate-backup-vault-mpa-approval-team` CLI 命令：
```
aws backup disassociate-backup-vault-mpa-approval-team \
--backup-vault-name VAULT_NAME \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```
当前的 MPA 审批团队成员将收到有关批准请求的通知。获得所需数量的团队成员的批准后，系统将取消审批团队与保管库的关联。
------
## 撤消恢复访问权限备份保管库
请求者：**拥有逻辑上受物理隔离的保管库的账户的管理员**。
您可以从源保管库账户撤消对恢复访问权限备份保管库的访问权限。
------
#### [ Console ]
**撤消恢复访问权限备份保管库**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在左侧导航窗格中，导航到**备份保管库**部分。
1. 选择要撤消访问权限的逻辑上受物理隔离的备份保管库。
1. 在**保管库详细信息**页面上，向下滚动至**通过多方审批进行访问**部分。
1. 找到要撤消的恢复访问权限备份保管库，然后选择**请求移除保管库访问权限**。
1. 输入解释撤消原因的请求者备注，此操作是可选的。
1. 选择**发送请求**以提交撤消请求。
审批团队成员将收到有关批准请求的通知。
获得所需数量的团队成员的批准后，系统将从恢复账户中删除恢复访问权限备份保管库。
------
#### [ CLI ]
首先，列出与源保管库关联的恢复访问权限备份存储库：
```
aws backup list-restore-access-backup-vaults \
--backup-vault-name SOURCE_VAULT_NAME \
--region REGION
```
然后，使用 CLI 命令 `revoke-restore-access-backup-vault`：
```
aws backup revoke-restore-access-backup-vault \
--backup-vault-name SOURCE_VAULT_NAME \
--restore-access-backup-vault-arn RESTORE_ACCESS_VAULT_ARN \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```
审批团队成员将收到有关批准请求的通知。获得所需数量的团队成员的批准后，系统将从恢复账户中删除恢复访问权限备份保管库。
------
## 更新与逻辑上隔绝的保管库关联的多方审批团队
请求者：**拥有逻辑上受物理隔离的保管库的账户的管理员**。
您可以更新与逻辑上受物理隔离的保管库关联的多方审批团队（[概述](multipartyapproval.md#multipartyapproval-overview)中的第 8 步）。
------
#### [ Console ]
**更新与逻辑上受物理隔离的保管库关联的审批团队**
1. 在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在左侧导航窗格中，导航到**备份保管库**部分。
1. 选择要更新审批团队的逻辑上受物理隔离的备份保管库。
1. 在保管库详细信息页面上，选择**请求审批团队更改**。
1. 从下拉菜单中，选择要与保管库关联的新审批团队。
1. 输入解释更改原因的请求者备注，此操作是可选的。
1. 选择**发送请求**以提交更改请求。
当前的审批团队成员将收到有关批准请求的电子邮件通知。
获得所需数量（规定人数）的当前 MPA 团队成员的批准后，系统将把新团队与保管库关联。
------
#### [ CLI ]
利用新团队 ARN 使用 CLI 命令 `associate-backup-vault-mpa-approval-team`：
```
aws backup associate-backup-vault-mpa-approval-team \
--backup-vault-name VAULT_NAME \
--mpa-approval-team-arn NEW_MPA_TEAM_ARN \
--requester-comment "OPTIONAL_COMMENT" \
--region REGION
```
当前的审批团队成员将收到有关批准请求的通知。获得所需数量（规定人数）的当前团队成员的批准后，系统将把新 MPA 团队与保管库关联。
------
# 审批者任务
作为多方审批团队成员的用户可以[批准或拒绝会话中的请求](https://docs.aws.amazon.com/mpa/latest/userguide/approver.html)。其他任务包括：
+ [响应请求的操作](https://docs.aws.amazon.com/mpa/latest/userguide/respond-request)
+ [查看审批团队](https://docs.aws.amazon.com/mpa/latest/userguide/approver-view-team)
+ [查看操作历史记录](https://docs.aws.amazon.com/mpa/latest/userguide/view-operation-history)
# 文件库访问策略
使用 AWS Backup，您可以为备份存储库及其包含的资源分配策略。通过分配策略，您可以执行诸多操作，例如，授予用户创建备份计划和按需备份的访问权限，但限制用户在创建恢复点后删除这些恢复点的能力。
有关使用策略授予或限制资源访问权限的信息，请参阅《IAM 用户指南》**中的[基于身份的策略和基于资源的策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_identity-vs-resource.html)。您还可以使用标签来控制访问。
使用 AWS Backup 文件库时，您可以使用以下示例策略来限制对资源的访问权限。与其他基于 IAM 的策略不同， AWS Backup 访问策略不支持密钥中的通配符。`Action`
有关可用于识别不同资源类型的恢复点的 Amazon 资源名称 (ARNs) 的列表，[AWS Backup 资源 ARNs](access-control.md#resource-arns-table)请参阅资源特定的恢复点。 ARNs
文件库访问策略仅控制用户对的访问权限 AWS Backup APIs。某些备份类型，例如亚马逊弹性区块存储 (Amazon EBS) 和亚马逊关系数据库服务 (Amazon RDS) 快照，也可以使用这些服务进行 APIs 访问。您可以在 IAM 中创建单独的访问策略来控制对这些备份的访问权限， APIs 从而完全控制对这些备份类型的访问权限。
无论 AWS Backup 文件库的访问策略如何，除此之外的任何操作的跨账户访问都`backup:CopyIntoBackupVault`将被拒绝；也就是说， AWS Backup 将拒绝来自与所引用资源账户不同的账户的任何其他请求。
**Topics**
+ [拒绝对备份保管库中资源类型的访问](#deny-access-to-ebs-snapshots)
+ [拒绝对备份保管库的访问](#deny-access-to-a-backup-vault)
+ [拒绝删除备份保管库中的恢复点](#deny-access-to-delete-recovery-points)
## 拒绝对备份保管库中资源类型的访问
此策略拒绝针对备份保管库中的所有 Amazon EBS 快照访问指定的 API 操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyRecoveryPointOperations",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::111122223333:role/MyRole"
},
"Action": [
"backup:UpdateRecoveryPointLifecycle",
"backup:DescribeRecoveryPoint",
"backup:DeleteRecoveryPoint",
"backup:GetRecoveryPointRestoreMetadata",
"backup:StartRestoreJob"
],
"Resource": [
"arn:aws:ec2:*:*:snapshot/*"
]
}
]
}
```
------
## 拒绝对备份保管库的访问
此策略拒绝访问针对备份保管库的指定 API 操作。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyBackupVaultOperations",
"Effect": "Deny",
"Principal": {
"AWS": "arn:aws:iam::123456789012:role/MyRole"
},
"Action": [
"backup:DescribeBackupVault",
"backup:DeleteBackupVault",
"backup:PutBackupVaultAccessPolicy",
"backup:DeleteBackupVaultAccessPolicy",
"backup:GetBackupVaultAccessPolicy",
"backup:StartBackupJob",
"backup:GetBackupVaultNotifications",
"backup:PutBackupVaultNotifications",
"backup:DeleteBackupVaultNotifications",
"backup:ListRecoveryPointsByBackupVault"
],
"Resource": "arn:aws:backup:us-east-1:123456789012:backup-vault:backup vault name"
}
]
}
```
------
## 拒绝删除备份保管库中的恢复点
根据您授予用户的访问权限来确定这些用户是否可以访问保管库以及是否能够删除存储在其中的恢复点。
请按照以下步骤在备份保管库上创建基于资源的访问策略，阻止删除备份保管库中的任意备份。
**在备份保管库上创建基于资源的访问策略**
1. 登录 AWS 管理控制台，然后在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在左侧的导航窗格中，选择 **Backup vaults (备份保管库)**。
1. 在列表中选择备份保管库。
1. 在 **Access policy (访问策略)** 部分中，粘贴以下 JSON 示例。此策略可防止不是委托人的任何用户删除目标备份保管库中的恢复点。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Principal": "*",
"Action": "backup:DeleteRecoveryPoint",
"Resource": "*",
"Condition": {
"StringNotEquals": {
"aws:userId": [
"AIDA1234567890EXAMPLE",
"AROA1234567890EXAMPLE:my-role-session",
"AROA1234567890EXAMPLE:*",
"112233445566"
]
}
}
}
]
}
```
------
要允许使用其 ARN 列出 IAM 身份，请在以下示例中使用 `aws:PrincipalArn` 全局条件密钥。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "DenyDeleteRecoveryPoint",
"Effect": "Deny",
"Principal": "*",
"Action": "backup:DeleteRecoveryPoint",
"Resource": "*",
"Condition": {
"ArnNotEquals": {
"aws:PrincipalArn": [
"arn:aws:iam::112233445566:role/mys3role",
"arn:aws:iam::112233445566:user/shaheer",
"arn:aws:iam::112233445566:root"
]
}
}
}
]
}
```
------
有关获取 IAM 实体唯一 ID 的信息，请参阅《IAM 用户指南》**中的[获取唯一标识符](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_identifiers.html#identifiers-get-unique-id)。
如果要将此限制为特定资源类型，而不是 `"Resource": "*"`，您可以明确包含要拒绝的恢复点类型。例如，对于 Amazon EBS 快照，请将资源类型更改为以下内容。
```
"Resource": ["arn:aws:ec2::Region::snapshot/*"]
```
1. 选择**附加策略**。
# AWS Backup 文件库锁
**注意**
AWS Backup Cohasset Associates已对Vault Lock进行了评估，适用于受美国证券交易委员会17a-4、美国商品期货交易委员会和美国金融监管局法规约束的环境。有关 AWS Backup Vault Lock 与这些法规的关系的更多信息，请参阅 [Cohasset Associates 合规性评估](samples/cohassetreport.zip)。
AWS Backup Vault Lock 是备份保管库的一项可选功能，它有助于增强对备份库的安全性和控制力。当锁在合规模式下处于活动状态并且宽限期结束时，客户、 account/data 所有者或 AWS 只要存储库配置包含恢复点，就无法更改或删除。每个保管库可以有一个保管库锁。
AWS Backup 确保您的备份在保留期到期之前一直可供您使用。如果任何用户（包括 root 用户）尝试删除已锁定文件库中的备份或更改其生命周期属性， AWS Backup 则会拒绝该操作。
+ 拥有充足 IAM 权限的用户可以解除锁定在**治理模式**下的保管库。
+ 冷静期（“**宽限期**”）到期后，如果保管库包含任何恢复点，则*无法删除*在**合规模式**下锁定的保管库。在宽限期内，您仍可以移除保管库锁定并更改锁定配置。
**警告**
宽限期到期后，文件库及其锁定将不可变，任何用户或任何用户都无法更改或删除。 AWS锁定文件库中的备份在生命周期结束之前无法删除，如果不小心，则会产生持续的成本。例如，确保没有保留期设置为 “始终” 的恢复点，宽限期到期后，这些恢复点将永久保留，并且无法更改或删除。
## 保管库锁定模式
创建保管库锁定时，您可以选择两种模式：**治理模式**或**合规模式**。治理模式旨在允许只有拥有充足 IAM 权限的用户才能管理保管库。治理模式可帮助组织满足治理要求，确保只有指定的人员才能对备份保管库进行更改。合规模式适用于在数据保留期结束之前永远不会删除或更改保管库（以及其内容）的备份保管库。一旦合规模式下的保管库被锁定，它就**不可变**，意味着*无法移除*锁定（如果保管库为空，而不包含任何恢复点，则可以删除保管库本身）。
拥有相应 IAM 权限的用户可以管理或删除在治理模式下锁定的保管库。
任何用户或 AWS都无法更改或删除处于合规模式下的保管库锁定。在保管库锁定并且内容和保管库锁定变为不可变之前，合规模式下的保管库锁定功能具有您设置的宽限期。
## 保管库锁定的好处
AWS Backup 文件库锁有多项好处，包括：
+ 针对您在备份保管库中存储和创建的所有备份进行 WORM（*一次写入、多次读取*）配置。
+ 额外防御层，可保护备份保管库中的备份（恢复点）免遭意外或恶意删除。
+ 强制执行保留期，防止特权用户（包括 AWS 账户 root 用户）提前删除，并符合贵组织的数据保护策略和程序。
## 使用控制台锁定备份保管库
您可以使用 Backup 控制台向 AWS Backup 保管库添加文件库锁。
要向备份保管库添加保管库锁定，请执行以下操作：
1. 登录 AWS 管理控制台，然后在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在导航窗格中，找到**备份保管库**。单击 Backup 保管库下嵌套的名为**保管库锁定**的链接。
1. 在**保管库锁定的工作原理**或**保管库锁定**下，单击 **\$1 创建保管库锁定**。
1. 在**保管库锁定详细信息**窗格中，选择要应用锁定的保管库。
1. 在**保管库锁定模式**下，选择要锁定保管库的模式。有关选择模式的更多信息，请参阅本页前面的[保管库锁定模式](https://docs.aws.amazon.com/aws-backup/latest/devguide/vault-lock.html#backup-vault-lock-modes)。
1. 对于**保留期**，选择最小和最大保留期（保留期是*可选项*）。如果保管库中创建的新备份和复制作业不符合您设置的保留期，则这些作业将失败；这些期限不适用于保管库中已有的恢复点。在启用文件库锁定之前存在于保管库中的恢复点将遵循其之前的生命周期设置。
1. 如果您选择合规模式，则会显示一个名为**保管库锁定开始日期**的部分。如果您选择治理模式，则不会显示该部分，并且可以跳过此步骤。
在合规模式下，保管库锁定的冷静期从创建保管库锁定开始，直到保管库及其锁变为不可变且不可更改。您可以选择此期限的持续时间（称为**宽限期**），但必须*至少*为 3 天（72 小时）。
**重要**
宽限期到期后，文件库及其锁定将不可变，任何用户或任何用户都无法更改或删除。 AWS
1. 如果您对配置选项感到满意，请单击**创建保管库锁定**。
1. 要确认您希望在所选模式下创建此锁定，请在文本框中键入 `confirm`，然后选中确认配置符合预期的复选框。
如果步骤已成功完成，则控制台顶部将显示“成功”横幅。
## 以编程方式锁定备份保管库
要配置 AWS Backup 文件库锁定，请使用 API `[PutBackupVaultLockConfiguration](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_PutBackupVaultLockConfiguration.html)`。要包含的参数将取决于您打算采用哪种保管库锁定模式。如果您想在治理模式下创建保管库锁定，**请不要包含 **`ChangeableForDays`。如果包含此参数，则将在合规模式下创建保管库锁定。
以下是创建合规模式保管库锁定的 CLI 示例：
```
aws backup put-backup-vault-lock-configuration \
--backup-vault-name my_vault_to_lock \
--changeable-for-days 3 \
--min-retention-days 7 \
--max-retention-days 30
```
以下是创建治理模式保管库锁定的 CLI 示例：
```
aws backup put-backup-vault-lock-configuration \
--backup-vault-name my_vault_to_lock \
--min-retention-days 7 \
--max-retention-days 30
```
您可以配置四个选项。
1. `BackupVaultName`
要锁定的保管库的名称。
1. `ChangeableForDays`（*仅*适用于合规模式）
此参数指示 AWS Backup 在**合规模式**下创建文件库锁。如果您打算在**治理模式下**创建锁定，请省略此参数。
该值以天数表示。它必须是一个不小于 3 且不大于 36,500 的数字；否则，将返回错误。
从创建此保管库锁定到指定日期到期，可以使用 `DeleteBackupVaultLockConfiguration` 将保管库锁定从保管库中删除。或者，在此期间，您可以使用 `PutBackupVaultLockConfiguration` 更改配置。
在此参数确定的指定日期及之后，备份保管库将不可变且无法更改或删除。
1. `MaxRetentionDays`*（可选）*
这是一个以天为单位的数值。这是保管库保留其恢复点的最长保留期。
您选择的最大保留时间范围应与您组织的数据保留政策保持一致。如果您的组织要求将数据保留一段时间，则可以将此值设置为该期限（以天为单位）。例如，可能需要将财务或银行数据保存 7 年（大约 2,557 天，视闰年而定）。
如果未指定， AWS Backup 文件库锁定将不会强制规定最长保留期。如果指定此参数，则生命周期保留期长于最大保留期的备份和复制到此保管库的作业将失败。保管库锁定创建之前已保存在保管库中的恢复点不受影响。您可以指定的最长保留期为 36500 天（大约 100 年）。
1. `MinRetentionDays`（*可选*；必填项 CloudFormation）
这是一个以天为单位的数值。这是保管库保留其恢复点的最短保留期。此设置应设置为您的组织维护数据*所需的* 时间。例如，如果法规或法律要求将数据保留至少七年，则以天为单位的值约为 2,557，视闰年而定。
如果未指定， AWS Backup 文件库锁定将不会强制规定最短保留期。如果指定此参数，则生命周期保留期短于最小保留期的备份和复制到此保管库的作业将失败。在保管库锁定之前已保存在 AWS Backup 保管库中的恢复点不受影响。您可以指定的最短保留期为 1 天。
## 查看备份保管库的保 AWS Backup 管库锁定配置
您可以随时致电`[DescribeBackupVault](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DescribeBackupVault.html)`或查看 AWS Backup 保管库上的文件库锁定详细信息`[ListBackupVaults](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_ListBackupVaults.html)` APIs。
要确定您是否对备份保管库应用了保管库锁定，请调用 `DescribeBackupVault` 并查看 `Locked` 属性。如果`"Locked": true`像以下示例一样，您已将 AWS Backup 文件库锁定应用于备份保管库。
```
{
"BackupVaultName": "my_vault_to_lock",
"BackupVaultArn": "arn:aws:backup:us-east-1:555500000000:backup-vault:my_vault_to_lock",
"EncryptionKeyArn": "arn:aws:kms:us-east-1:555500000000:key/00000000-1111-2222-3333-000000000000",
"CreationDate": "2021-09-24T12:25:43.030000-07:00",
"CreatorRequestId": "ac6ce255-0456-4f84-bbc4-eec919f50709",
"NumberOfRecoveryPoints": 1,
"Locked": true,
"MinRetentionDays": 7,
"MaxRetentionDays": 30,
"LockDate": "2021-09-30T10:12:38.089000-07:00"
}
```
上述输出确认了以下选项：
1. `Locked`是一个布尔值，表示您是否已将 AWS Backup 文件库锁定应用于此备份存储库。 `True`意味着 AWS Backup 文件库锁定会导致对存储在保管库中的恢复点的删除或更新操作失败（无论您是否仍处于冷静期宽限期）。
1. `LockDate` 是您的冷静宽限期结束时的 UTC 日期和时间。在此时间之后，您将无法删除或更改对此保管库的锁定。使用任何公开可用的时间转换器将此字符串转换为您的本地时间。
如果 `"Locked":false` 像以下示例一样，说明您尚未应用保管库锁定（或之前的保管库锁定已被删除）。
```
{
"BackupVaultName": "my_vault_to_lock",
"BackupVaultArn": "arn:aws:backup:us-east-1:555500000000:backup-vault:my_vault_to_lock",
"EncryptionKeyArn": "arn:aws:kms:us-east-1:555500000000:key/00000000-1111-2222-3333-000000000000",
"CreationDate": "2021-09-24T12:25:43.030000-07:00",
"CreatorRequestId": "ac6ce255-0456-4f84-bbc4-eec919f50709",
"NumberOfRecoveryPoints": 3,
"Locked": false
}
```
## 在宽限期内移除保管库锁定（合规模式）
要在宽限期（锁定保管库之后但在锁定保管库之前的时间`LockDate`）使用 AWS Backup 控制台删除文件库锁定，
1. 登录 AWS 管理控制台，然后在 [https://console.aws.amazon.com/backup](https://console.aws.amazon.com/backup) 上打开 AWS Backup 控制台。
1. 在**我的账户**下的左侧导航栏中，单击“备份保管库”，然后单击“备份保管库锁定”。
1. 单击您要移除的保管库锁定，然后单击**管理保管库锁定**。
1. 单击**删除保管库锁定**。
1. 此时，将显示一个警告框，要求您确认删除保管库锁定的意图。在文本框中键入 `confirm`，然后单击**确认**。
成功完成所有步骤后，控制台屏幕顶部将显示“成功”横幅。
要在宽限期内使用 CLI 命令删除保管库锁定，请使用 `[DeleteBackupVaultLockConfiguration](https://docs.aws.amazon.com/aws-backup/latest/devguide/API_DeleteBackupVaultLockConfiguration.html)`，如这个 CLI 示例所示：
```
aws backup delete-backup-vault-lock-configuration \
--backup-vault-name my_vault_to_lock
```
## AWS 账户 用上锁的金库关闭
当您关闭 AWS 账户 包含备份保管库的， AWS 并在备份完好无损的情况下 AWS Backup 暂停您的帐户 90 天。如果您在这 90 天内没有重新打开账户，即使保管库锁定已到位，也会 AWS 删除备份 AWS Backup 保管库中的内容。
## 其它安全注意事项
AWS Backup Vault Lock 为您的数据保护防御深度增加了一层额外的安全保护。保管库锁定可以与其他安全功能结合使用：
+ [针对您的恢复点的加密](https://docs.aws.amazon.com/aws-backup/latest/devguide/encryption.html)
+ [AWS Backup 文件库和恢复点访问策略](https://docs.aws.amazon.com/aws-backup/latest/devguide/create-a-vault-access-policy.html)，允许您在文件库级别授予或拒绝权限，
+ [AWS Backup 安全最佳实践](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-considerations.html)，包括其[客户托管策略库，这些策略](https://docs.aws.amazon.com/aws-backup/latest/devguide/security-iam-awsmanpol.html#customer-managed-policies)允许您通过 AWS 支持的服务授予或拒绝备份和恢复权限，以及
+ [AWS Backup Audit Manager](https://docs.aws.amazon.com/aws-backup/latest/devguide/aws-backup-audit-manager.html)，它允许您根据自己定义[的控制列表自动检查备份的](https://docs.aws.amazon.com/aws-backup/latest/devguide/controls-and-remediation.html)合规性。
您可以遍历[使用 AWS Backup API 创建框架](creating-frameworks-api.md)以使用 AWS Backup Audit Manager 实施控制[资源位于带有 AWS Backup 文件库锁的备份计划中](controls-and-remediation.md#backup-vault-lock-control)，从而帮助确保利用保管库锁的保护您的预期资源。
+ 使资源处于非活动状态的机制可能会影响还原资源的能力。虽然仍然无法在锁定的保管库中删除它们，但它们可能处于非活动状态。例如，允许您[禁用 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/disable-an-ami.html) 的 Amazon Elastic Compute Cloud 设置可以暂时阻止还原 EC2 实例的备份。这会影响所有 EC2 恢复点，甚至是受保管库锁定功能或法定保留影响的备份。
如果 EC2 备份被禁用，您可以[重新启用已禁用的 AMI](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/disable-an-ami.html#re-enable-a-disabled-ami)。重新启用后，它便有资格进行还原。要阻止 AMI 禁用特征，您可以使用 IAM 策略不允许 `ec2:DisableImage`。
**注意**
AWS Backup 文件库锁与 [Amazon Glacier 文件库锁](https://docs.aws.amazon.com/amazonglacier/latest/dev/vault-lock.html)的功能不同，后者仅与亚马逊 Glacier 兼容。