您可以使用NetApp快照技术在几分钟内创建数据库备份。创建快照副本所需的时间与数据库的大小无关，因为快照副本不会移动存储平台上的任何物理数据块。此外，由于所有操作都在存储系统中执行，因此使用快照技术不会对实时 SAP 系统的性能产生影响。因此，您可以安排创建快照副本，而无需考虑对话高峰期或批量活动期。SAP on NetApp客户通常会在一天内安排多次在线快照备份；例如，每六小时备份一次很常见。这些快照备份通常会在主存储系统上保留三到五天，然后被删除或分层存储到更便宜的存储系统中以进行长期保留。

快照副本也为恢复操作提供了关键优势。恢复操作会根据备份状态将文件系统中的数据恢复原状。恢复操作是利用数据库日志备份将数据库状态回滚到某个时间点。

NetApp SnapRestore技术能够根据当前可用的快照备份恢复整个数据库，或者只恢复数据库的一部分。无论数据库大小如何，恢复过程都会在几秒钟内完成。由于一天内可以创建多个在线快照备份，因此与传统的每天一次备​​份方法相比，恢复过程所需的时间大大减少。因为可以使用最多只有几个小时（而不是最多 24 小时）的快照副本执行还原，所以在向前恢复期间需要应用的事务日志更少。与传统流式备份相比，恢复和还原所需的时间显著减少。

由于快照备份与活动在线数据存储在同一磁盘系统上， NetApp建议将快照副本备份作为补充，而不是替代备份到辅助位置。大多数恢复操作都是通过在主存储系统上使用SnapRestore来管理的。只有当包含快照副本的主存储系统不可用时，才需要从辅助位置进行恢复。如果需要恢复主存储上不再可用的备份，也可以使用辅助备份。

备份到辅助位置是基于在主存储上创建的快照副本。因此，数据直接从主存储系统读取，不会对 SAP 数据库服务器及其网络造成负载。主存储直接与辅助存储通信，并使用SnapVault或 ANF 备份功能将备份数据复制到目标位置。

与传统备份相比， SnapVault和 ANF 备份具有显著优势。在初始数据传输（即所有数据从源传输到目标）之后，所有后续备份仅将更改的数据块复制到辅助存储。因此，主存储系统的负载和完整备份所需的时间都显著减少。由于目标位置只存储已更改的数据块，因此任何额外的完整数据库备份都会占用更少的磁盘空间。

下图显示了客户的 HANA Studio 使用快照备份操作的情况。图像显示，使用快照备份技术备份 HANA 数据库（大小约为 4TB）仅需 1 分 20 秒，而使用基于文件的备份操作则需要 4 个多小时。

整个备份工作流程运行时间中，执行 HANA 数据库快照操作所需的时间占比最大。存储快照备份本身只需几秒钟即可完成，与 HANA 数据库的大小无关。

本节对基于文件的快照备份和基于存储的快照备份的恢复时间目标 (RTO) 进行了比较。RTO 定义为恢复数据库、重启数据库以及启动数据库所需的时间之和。

执行备份是任何数据保护策略的关键部分。系统会定期计划备份、以确保您可以从系统故障中恢复。这是最明显的使用情形、但也有其他SAP生命周期管理任务、在这些任务中、加快备份和恢复操作至关重要。

SAP HANA 系统升级就是一个例子，升级前进行按需备份以及升级失败时进行可能的恢复操作，会对整体计划停机时间产生重大影响。以 4TB 数据库为例，使用基于快照的备份和恢复操作，您可以将计划停机时间减少 8 小时，或者您可以多出 8 小时来分析和修复错误。

另一个应用场景是典型的测试周期，其中必须使用不同的数据集或参数进行多次迭代测试。利用快速备份和恢复操作，您可以在测试周期内轻松创建保存点，并在测试失败或需要重复测试时将系统重置到任何先前的保存点。这样可以提前完成测试，或者同时进行更多测试，从而提高测试结果。

实施快照备份后，它们可以用于解决其他多个需要 HANA 数据库副本的用例。您可以基于任何可用快照备份的内容创建新卷。该操作的运行时间为几秒钟，与卷的大小无关。

最常见的用例是 SAP 系统刷新，即需要将生产系统中的数据复制到测试或 QA 系统中。利用ONTAP或 ANF 克隆功能，您可以在几秒钟内从生产系统的任何快照副本为测试系统配置卷。然后必须将新卷连接到测试系统，并恢复 HANA 数据库。

第二个用例是创建修复系统，用于解决生产系统中的逻辑损坏。在这种情况下，使用生产系统的较早快照备份来启动修复系统，该系统是生产系统的完全相同的克隆，包含损坏发生之前的数据。然后利用修复系统分析问题，并在数据损坏之前导出所需数据。

最后一个用例是能够在不停止复制的情况下运行灾难恢复故障转移测试，因此不会影响灾难恢复设置的 RTO 和恢复点目标 (RPO)。当使用ONTAP SnapMirror复制或 ANF 跨区域复制将数据复制到灾难恢复站点时，生产快照备份在灾难恢复站点也可用，然后可以用于创建新卷以进行灾难恢复测试。