NetApp Snapshot 技术可用于在几分钟内创建数据库备份。创建 Snapshot 副本所需的时间与数据库大小无关，因为 Snapshot 副本不会移动存储平台上的任何物理数据块。此外，使用 Snapshot 技术不会对实时 SAP 系统产生性能影响，因为在创建 Snapshot 副本或更改活动文件系统中的数据时， NetApp Snapshot 技术不会移动或复制数据块。因此，可以计划创建 Snapshot 副本，而无需考虑对话峰值或批处理活动期间。SAP 和 NetApp 客户通常会在一天内计划多个联机 Snapshot 备份；例如，每四小时备份一次很常见。这些 Snapshot 备份通常会在主存储系统上保留三到五天，然后再被删除。

Snapshot 副本还为还原和恢复操作提供了主要优势。通过 NetApp SnapRestore 数据恢复软件，可以根据可用的 Snapshot 副本将整个数据库或数据库的一部分还原到任意时间点。无论数据库大小如何，此类还原过程都只需几分钟即可完成。由于在一天中会创建多个联机 Snapshot 备份，因此与传统备份方法相比，恢复过程所需的时间显著减少。由于可以使用仅使用几小时（而不是长达 24 小时）的 Snapshot 副本执行还原，因此必须应用较少的事务日志。因此， RTO 减少到几分钟，而不是传统单周期磁带备份所需的几小时。

Snapshot 副本备份与活动联机数据存储在同一磁盘系统上。因此， NetApp 建议使用 Snapshot 副本备份作为对备份到二级位置的补充，而不是替代。大多数还原和恢复操作都通过在主存储系统上使用 SnapRestore 来处理。只有当包含 Snapshot 副本的主存储系统损坏时，才需要从二级位置进行还原。如果需要还原 Snapshot 副本不再提供的备份，也可以使用二级位置：例如，月末备份。

到二级位置的备份基于在主存储上创建的 Snapshot 副本。因此，直接从主存储系统读取数据，而不会在 SAP 数据库服务器上生成负载。主存储直接与二级存储通信，并使用 NetApp SnapVault 磁盘到磁盘备份将备份数据发送到目标。

与传统备份相比， SnapVault 具有显著优势。在初始数据传输（所有数据均已从源传输到目标）之后，所有后续备份仅会将更改过的块复制到二级存储。因此，主存储系统上的负载以及完整备份所需的时间会显著减少。由于 SnapVault 仅在目标上存储更改过的块，因此完整的数据库备份所需的磁盘空间更少。

解决方案 还可以无缝扩展到混合云操作模式。可以从内部 NetApp ONTAP 系统到云中运行的 Cloud Volumes ONTAP 实例进行数据复制，以实现灾难恢复或异地备份。无论 SAP HANA 系统是在内部还是在云中运行，您都可以使用 SnapCenter 作为一个中央工具来管理数据保护和数据复制。下图显示了备份解决方案 的概述。

下面的屏幕截图显示了客户在 NetApp 存储上运行 SAP HANA 的 HANA Studio 。客户正在使用 Snapshot 副本备份 HANA 数据库。此图显示，使用 Snapshot 备份技术， HANA 数据库（大小约为 2.3 TB ）将在 2 分 11 秒内备份完毕。

本节将对基于文件的 Snapshot 备份和基于存储的 Snapshot 备份进行 RTO 比较。RTO 由还原数据库所需时间与启动和恢复数据库所需时间之和定义。