

本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 使用卷备份保护数据
<a name="using-backups"></a>

使用 f FSx or ONTAP，您可以通过对文件系统上的卷进行每日自动备份和用户启动的备份来保护您的数据。为卷创建定期备份是一种最佳实践，有助于满足您的数据留存和合规需求。您可以将卷备份还原到您有权访问的任何现 FSx 有 ONTAP 文件系统，该文件系统位于存储备份 AWS 区域 的位置。使用 Amazon FSx 备份可以轻松创建、查看、恢复和删除卷的备份。

Amazon FSx 支持使用读写 (RW) `OntapVolumeType` 对ONTAP卷进行备份。

**注意**  
Amazon FSx 不支持为和备份数据保护 (DP) 卷、负载共享镜像 (LSM) 卷或目标卷。FlexCache SnapMirror

**Topics**
+ [备份的工作方式](#how-backups-work)
+ [存储需求](#storage-requirements)
+ [每日自动备份](#automatic-backups)
+ [用户启动的备份](#user-initiated-backups)
+ [将标签复制到备份](#copy-tags-to-backups)
+ [在 Amazon AWS Backup 上使用 FSx](#aws-backup-and-fsx)
+ [将备份还原至新卷](#restoring-backups)
+ [备份与还原性能](#backup-performance)
+ [备份 SnapLock 卷](#snaplock-backup)
+ [创建用户启动备份](creating-backups.md)
+ [将备份还原至新卷](to-restore-backups.md)
+ [还原部分数据](data-subset-restore.md)
+ [在还原备份时监控进度](monitor-backup-restore.md)
+ [删除备份](how-to-delete-backups.md)

## 备份的工作方式
<a name="how-backups-work"></a>

所有 Amazon FSx 备份（每日自动备份和用户启动的备份）都是增量备份，这意味着它们仅存储自上次备份完成以来数据中的更改。这样可以最大程度地减少创建备份所需的时间和每次备份使用的存储量。增量备份不存储重复数据，从而优化存储成本。 FSx 对于 ONTAP，备份是按卷进行的，每个备份仅包含一个特定卷的数据。Amazon FSx 备份以冗余方式存储在多个可用区中，以实现高持久性。

Amazon FSx 备份使用快照（即卷的只读映像）来保持备份之间的增量。 point-in-time每次进行备份时，Amazon 都会 FSx 首先拍摄您的卷快照。备份快照存储在卷中，会占用卷上的存储空间。 FSx 然后，Amazon 将此快照与之前的备份快照（如果存在）进行比较，并仅将更改后的数据复制到您的备份中。

如果不存在之前的备份快照，则会将最新备份快照的全部内容复制到您的备份中。成功拍摄最新备份快照后，Amazon FSx 会删除之前的备份快照。用于最新备份的快照将保留在您的卷中，直到进行下一次备份，该过程将重复进行。为了优化备份存储成本，ONTAP 在备份中保留了卷节省的存储效率。

[删除](how-to-delete-backups.md)备份时，仅会删除该备份特有的数据。每个 Amazon FSx 备份都包含通过备份创建新卷所需的所有信息，从而有效地恢复该卷的 point-in-time快照。

每个卷 AWS 账户 和每个卷可以存储的备份数量有限制。有关更多信息，请参阅[您可以提高的配额](limits.md#soft-limits)和[每个文件系统的资源限额](limits.md#limits-ontap-resources-file-system)。

**注意**  
如果您使用 NDMP 进行备份，则 ONTAP 不允许在NDMP传输过程中继续执行诸如修补程序操作之类的维护活动。为避免延迟补丁，在文件系统的维护窗口期间应用补丁操作时，Amazon FSx 将中止所有活动的NDMP传输会话。修补完成后，您需要从客户端手动重启NDMP传输会话，因为Amazon FSx 无法自动恢复这些会话。为避免备份中断，我们建议使用支持并行 FSx 备份和补丁操作的 Amazon 备份或 AWS Backup。

## 存储需求
<a name="storage-requirements"></a>

您的卷和文件系统都必须有足够的可用 SSD 存储容量来存储备份快照。在拍摄备份快照时，快照消耗的其他存储容量不能致使卷的 SSD 存储利用率超过 98%。如果发生这种情况，备份将失败。您可以随时增加[卷](manage-volume-capacity.md)或[文件系统](storage-capacity-and-IOPS.md#increase-primary-storage)的 SSD 存储空间，以确保备份不会中断。

## 每日自动备份
<a name="automatic-backups"></a>

在创建文件系统时，默认为文件系统的卷启用每日自动备份。您可以随时为现有文件系统启用或禁用每日自动备份。所有卷的每日自动备份是在文件系统的每日备份窗口内进行的，每日备份窗口是在创建文件系统时自动设置的。您可以随时修改每日备份窗口。为获得最佳[备份性能](#backup-performance)，我们建议您在客户端和应用程序访问卷上的数据时，选择一个在正常运行时间以外的每日备份窗口。我们还建议您选择与文件系统的维护时段不重叠的备份窗口。如果窗口重叠，则优先执行维护活动，并在维护完成后进行自动备份。已在进行的备份将在维护期间继续进行，但是，在维护完成之前，可能不会创建新的备份。如果在整个窗口期间都进行维护，则在该窗口期间可能不会进行自动备份。

您可以使用控制台，在创建文件系统时或随时将每日自动备份的保留期设置为 1 到 90 天的值。每日自动备份的默认保留期为 30 天。保留期到期后，Amazon FSx 会删除每日自动备份。使用 AWS CLI 和 API，您可以将保留期设置为 0 到 90 天的值；将其设置为 0 会关闭每日自动备份。

每日自动备份、每日备份时段和备份保留期为文件系统设置，适用于文件系统上的所有卷。您可以使用 Amazon FSx 控制台 AWS CLI、或 API 来更改这些设置。有关更多信息，请参阅 [更新文件系统](updating-file-system.md)。

卷处于离线状态时无法创建卷备份（每日自动备份或用户启动的备份）。有关更多信息，请参阅 [查看离线卷](offline-volumes.md)。

**注意**  
每日自动备份的最长保留期为 90 天，但是您创建的[用户启动的备份](#user-initiated-backups)（包括使用创建的备份）将永久保留 AWS Backup，除非您或将其 AWS Backup 删除。

您可以使用 Amazon FSx 控制台、CLI 和 API 手动[删除](how-to-delete-backups.md)每日自动备份。删除卷时，也会删除该卷的每日自动备份。Amazon FSx 提供了在您删除卷之前创建最终备份的选项。最终备份将永久保存，除非将其删除。

## 用户启动的备份
<a name="user-initiated-backups"></a>

借助 Amazon FSx，您可以随时使用 AWS 管理控制台 AWS CLI、和 API 手动备份文件系统的卷。相对于可能为某个卷创建的其他备份，用户启动的备份是增量备份，除非将其删除，否则这些备份将永久保留。即使您删除了创建备份所在的卷或文件系统，用户启动备份也会保留。您只能使用亚马逊 FSx 控制台、API 或 CLI [删除用户启动的备份](how-to-delete-backups.md)。它们永远不会被亚马逊自动删除 FSx。

有关如何创建用户启动的备份的说明，请参阅 [创建用户启动备份](creating-backups.md)。

## 将标签复制到备份
<a name="copy-tags-to-backups"></a>

当使用 CLI 或 API 创建或更新卷时，您可以启用 `CopyTagsToBackups` 以[自动将卷中的标签](creating-volumes.md#create-volume-cli)复制到其备份中。但是，如果您在创建用户启动的备份时添加了任何标签，包括在使用控制台时命名备份，Amazon FSx *不会*从卷中复制标签，即使已启`CopyTagsToBackups`用。

## 在 Amazon AWS Backup 上使用 FSx
<a name="aws-backup-and-fsx"></a>

AWS Backup 是通过备份 Amazon FSx for NetApp ONTAP 卷来保护您的数据的简单且经济实惠的方法。 AWS Backup 是一项统一的备份服务，旨在简化备份的创建、恢复和删除，同时提供改进的报告和审计。使用 AWS Backup 可以更轻松地为法律法规和专业合规性制定集中式备份策略。它还提供了一个可以执行以下操作的中心位置，从而简化了对 AWS 存储卷、数据库和文件系统的保护：
+ 配置和审核要备份的 AWS 资源。
+ 计划自动备份。
+ 设置保留策略。
+ 监控所有最近的备份、复制和还原活动。

AWS Backup 使用 Amazon 的内置备份功能 FSx。使用 AWS Backup 控制台创建的备份具有相同级别的文件系统一致性和性能，与亚马逊 FSx 用户启动的对您的卷进行的任何其他备份相比是增量的，并且提供的还原选项与使用亚马逊 FSx 控制台进行的备份相同。使用 AWS Backup 来管理这些备份提供了其他功能，包括能够像每小时一样频繁地创建定时备份。您可以通过将备份存储在[备份库](https://docs.aws.amazon.com/aws-backup/latest/devguide/vaults.html)中来增加一道防护层，保护备份免遭意外或恶意删除。

由创建的备份 AWS Backup 被视为用户启动的备份，它们计入用户启动的 Amazon 备份配额。 FSx有关更多信息，请参阅 [您可以提高的配额](limits.md#soft-limits)。您可以查看和恢复 AWS Backup 使用 Amazon FSx 控制台、CLI 和 API 创建的备份。但是，您无法删除在 Amazon FSx 控制台、CLI 或 API AWS Backup 中创建的备份。有关更多信息，请参阅《 AWS Backup 开发人员指南》 AWS Backup中的[入门](https://docs.aws.amazon.com/aws-backup/latest/devguide/getting-started.html)。

AWS Backup 无法备份处于离线状态的卷。

您可以使用标签来选择哪些 FSx 适用于 ONTAP 的资源在备份计划中受到保护。这些标签必须应用于卷级别，而非整个文件系统级别。有关更多信息，请参阅《 AWS Backup 开发人员指南[》中的为备份计划分配资源](https://docs.aws.amazon.com/aws-backup/latest/devguide/assigning-resources.html)。

## 将备份还原至新卷
<a name="restoring-backups"></a>

可以将卷备份还原至文件系统上的新卷，该文件系统与存储备份所在的位置同处于 AWS 区域 。您无法将备份还原到与备份 AWS 区域 不同的文件系统中。

在 ONTAP 第二代文件系统上 FSx 恢复备份时，客户端可以在恢复卷的同时装载和读取卷中的数据。在 Amazon FSx 将所有元数据加载到新卷并且该卷报告的生命周期状态为，客户就可以装载您正在恢复的卷并读取文件数据`CREATED`。您可以在亚马逊 FSx 控制台的[**卷详细信息**](viewing-volumes.md)页面以及desc [ribe-volumes CLI命令的响应中找到卷](https://docs.aws.amazon.com/v2/documentation/api/latest/reference/fsx/describe-volumes.html)的生命周期状态。

在从备份还原卷的同时从卷中读取数据时，如果数据尚未下载到卷上，则首次访问数据将产生长达数十毫秒的读取延迟。这些读取缓存在 SSD 层中，后续读取预计会有亚毫秒的读取延迟。

Amazon FSx 使卷可供只读访问所花费的时间与备份中存储的文件元数据量成正比。文件元数据通常占总备份数据的 1-7%，具体比例取决于数据集中的平均文件大小（小文件数据集比大型文件数据集消耗更多的元数据）。

当您将FlexGroup卷备份恢复到具有不同于原始文件系统的[高可用性 (HA) 对](HA-pairs.md)数量不同的文件系统时，Amazon FSx 会添加额外的组成卷以确保组成部分均匀分布。

**注意**  
Amazon FSx 不支持在从备份中恢复SnapLock卷或第一代文件系统上的任何卷时对数据的读取权限。在还原这些备份的过程中，在还原过程完成且所有元数据和数据都加载到新卷上之后，卷就可用于挂载和访问数据。

还原备份时，所有数据最初写入 SSD 存储层。在还原过程中，根据正在还原的卷的[分层策略](volume-storage-capacity.md#volume-data-tiering)将数据分层到容量池存储。由于数据首先写入固态硬盘层，因此，如果文件系统的 SSD 存储空间用完，Amazon FSx 将暂停恢复过程。一旦有足够的 SSD 空间可用来继续此过程，还原就会自动恢复。如果还原卷的分层策略为 `All`，则定期运行的后台进程会将数据分层到容量池。如果还原卷的分层策略为 `Snapshot Only` 或 `Auto`，则在文件系统的 SSD 利用率大于 50% 且冷却速率由分层策略的冷却期决定时将数据分层到容量池。

如果在第二代文件系统上将备份还原至新卷时，工作负载需要稳定的亚毫秒级读取延迟，我们建议在启动还原时将卷的分层策略设置为 `None`，然后等到所有数据都完全下载到卷后再进行访问。所有数据都将在您尝试访问之前加载到 SSD 存储中，从而为您提供一致的低延迟数据访问。

有关如何将备份恢复到新卷的 step-by-step说明，请参阅[将备份还原至新卷](to-restore-backups.md)。

在第二代文件系统上，您还可以仅从备份中还原部分数据，而不必等待整个还原操作完成。仅还原备份的部分数据可以使您在数据意外删除、篡改或损坏时更快地恢复操作。有关更多信息，请参阅 [还原部分数据](data-subset-restore.md)。

您可以在 AWS 管理控制台、 AWS CLI和 API 中监控在第二代文件系统上恢复备份时的进度。有关更多信息，请参阅 [在还原备份时监控进度](monitor-backup-restore.md)。

**注意**  
从备份中恢复卷时，您无法创建卷快照或执行基于快照的操作，例如克隆、 SnapMirror 复制和创建卷的备份。
还原后的卷始终与原始卷具有相同的卷风格。还原时无法更改卷风格。

## 备份与还原性能
<a name="backup-performance"></a>

影响备份和还原操作性能的因素有很多。备份和还原操作是后台进程，这意味着其优先级低于客户端 IO 操作。客户端 IO 操作包括 NFS、CIFS 和 iSCSI 数据及元数据的读取和写入。所有后台进程仅利用文件系统吞吐能力中未使用的部分，可能需要几分钟到几小时来完成，具体取决于备份的大小和文件系统上未使用的吞吐能力。

影响备份和还原性能的其他因素包括存储数据的存储层和数据集配置文件。我们建议在大部分数据处于 SSD 存储上时创建卷的第一个备份。与主要包含大文件的类似大小的数据集相比，主要包含小文件的数据集通常具有较低的性能。这是因为处理大量小文件消耗的 CPU 周期和网络开销高于处理数量较少的大文件。

一般来说，在备份 SSD 存储层中存储的数据时，预计可达到以下备份速率：
+  MBps 多个并发备份中有 750 个，主要包含大文件。
+  MBps 多个并发备份中有 100 个，主要包含小文件。

通常，可以提供以下还原速率。
+  MBps 在多个并行恢复中有 250 个，主要包含大文件。
+  MBps 在多个并行还原中有 100 个，主要包含小文件。

## 备份 SnapLock 卷
<a name="snaplock-backup"></a>

您可以备份 [SnapLock](snaplock.md) 卷以获得额外的数据保护。恢复卷时，该 SnapLock 卷的原始设置（例如默认保留期、最短保留期和最长保留期）将保留。还会保留“一次写入，多次读取”（WORM）设置和依法保留。

**注意**  
无法备份 SnapLock FlexGroup 卷。

您可以将 SnapLock 卷的备份恢复为 SnapLock 卷或非 SnapLock 卷。但是，您不能将非 SnapLock 卷的备份恢复为 SnapLock 卷。

有关更多信息，请参阅 [SnapLock 的工作原理](how-snaplock-works.md)。