简体中文版经机器翻译而成,仅供参考。如与英语版出现任何冲突,应以英语版为准。

NetApp 解决方案

提供者

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

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

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

您可以使用其他基于 HANA 文件的备份将数据备份到二级位置。这些基于文件的备份的计划频率可以低得多,因此对生产系统性能的影响更小。

使用 Azure NetApp Files 跨区域复制进行灾难恢复时,所有 Snapshot 备份也会复制到灾难恢复站点,然后也可用作卸载的二级备份。另请参见 "TR-4891 :《使用 Azure NetApp Files 实现 SAP HANA 灾难恢复》"

此外,您还可以使用 Azure AzCopy 工具将 Snapshot 副本卸载到 Azure Blob 存储中,以便长期保留。这需要在 SnapCenter 服务之外编写其他脚本。

下图显示了使用 Snapshot 备份和基于文件的备份的数据保护配置示例。

错误:缺少图形映像

Snapshot 备份的运行时

下图显示了在 NetApp 存储上运行 SAP HANA 的客户 HANA Studio 的屏幕截图。客户正在使用 NetApp Snapshot 副本备份 HANA 数据库。如图所示,使用 Snapshot 备份技术, HANA 数据库(大约 2.3 TB )将在 2 分 11 秒内进行备份。

整个备份工作流运行时间的最大一部分是执行 HANA 备份保存点操作所需的时间,此步骤取决于 HANA 数据库上的负载。存储 Snapshot 备份本身始终会在几秒钟内完成。

错误:缺少图形映像

恢复时间目标比较

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

还原数据库所需的时间

对于基于文件的备份,还原时间取决于数据库和备份基础架构的大小,该基础架构定义了还原速度,以 MB/ 秒( MBps )为单位。例如,如果基础架构支持以 250 MBps 的速度执行还原操作,则还原大小为 1 TB 的数据库大约需要 1 小时 10 分钟。

对于存储 Snapshot 副本备份,还原时间与数据库大小无关,并且在几秒内您可以从主存储执行还原。只有在主存储不再可用时发生灾难时,才需要从基于文件的备份进行还原。

启动数据库所需的时间

数据库开始时间取决于行和列存储的大小。对于列存储,开始时间还取决于数据库启动期间预加载的数据量。在以下示例中,我们假定开始时间为 30 分钟。基于文件的还原和恢复以及基于 Snapshot 副本的还原和恢复的开始时间相同。

恢复数据库所需的时间

恢复时间取决于还原后必须应用的日志数量。此数字由执行数据备份的频率决定。

对于基于文件的数据备份,备份计划通常每天执行一次。通常无法实现较高的备份频率,因为备份会降低生产性能。因此,在最坏的情况下,在该日写入的所有日志都必须在正向恢复期间应用。

通常, Storage Snapshot 副本数据备份的计划频率较高,因为它们不会影响 SAP HANA 数据库的性能。例如,如果 Snapshot 副本备份每六小时计划一次,则在最坏的情况下,恢复时间是基于文件的备份恢复时间的四分之一( 6 小时 /24 小时 = 1/4 )。

下图显示了使用基于文件的数据备份时 1 TB 数据库的 RTO 示例。在此示例中,每天执行一次备份。RTO 因执行还原和恢复的时间而异。如果在创建备份后立即执行还原和恢复,则 RTO 主要基于还原时间,在示例中为 1 小时 10 分钟。在进行下次备份之前立即执行还原和恢复时,恢复时间增加到 2 小时 50 分钟,最大 RTO 为 4 小时 30 分钟。

错误:缺少图形映像

下图显示了使用 Snapshot 备份时 1 TB 数据库的 RTO 示例。对于基于存储的 Snapshot 备份, RTO 仅取决于数据库开始时间和正向恢复时间,因为还原操作会在几秒钟内完成,而与数据库大小无关。根据还原和恢复的完成时间,正向恢复时间也会增加,但由于备份频率较高(在此示例中为每 6 小时),正向恢复时间最多为 43 分钟。在此示例中,最大 RTO 为 1 小时 13 分钟。

错误:缺少图形映像

下图显示了不同数据库大小和不同 Snapshot 备份频率下基于文件和基于存储的 Snapshot 备份的 RTO 比较。绿色条显示了基于文件的备份。其他条形显示备份频率不同的 Snapshot 副本备份。

与基于文件的数据备份相比,每天只需备份一个 Snapshot 副本数据, RTO 便可减少 40% 。如果每天执行四个 Snapshot 备份,则减少量将增加到 70% 。此图还显示,如果将 Snapshot 备份频率提高到每天四到六个以上的 Snapshot 备份,则此曲线将保持平稳。因此,我们的客户通常每天配置四到六个 Snapshot 备份。

错误:缺少图形映像

此图显示了 HANA 服务器 RAM 大小。计算内存中的数据库大小等于服务器 RAM 大小的一半。

还原和恢复时间是根据以下假设计算的:数据库可以以 250 MBps 的速度进行还原;每天的日志文件数是数据库大小的 50% (例如, 1 TB 数据库每天创建 500 MB 的日志文件); 并且可以在 100 Mbps 的速度下执行恢复。