TR-4614 ：《使用 SnapCenter 实现 SAP HANA 备份和恢复》
建议更改
PDF
如今，企业需要为其 SAP 应用程序提供持续，无中断的可用性。面对不断增加的数据量以及系统备份等日常维护任务的需求，他们希望性能水平保持一致。执行 SAP 数据库备份是一项关键任务，可能会对生产 SAP 系统产生显著的性能影响。
作者：Nils Bauer、NetApp
备份窗口在缩减，而要备份的数据量在增加。因此，很难找到对业务流程影响最小的备份时间。恢复和恢复 SAP 系统所需的时间值得关注，因为 SAP 生产系统和非生产系统的停机时间必须尽可能地减少，以减少数据丢失和业务成本。
以下几点总结了 SAP 备份和恢复面临的挑战：
-
* 性能对生产 SAP 系统的影响。 * 通常，由于数据库服务器，存储系统和存储网络上的负载过重，基于副本的传统备份会显著降低生产 SAP 系统的性能。
-
* 正在缩减备份时间。 * 只有在 SAP 系统上正在进行的对话或批处理活动很少时，才能进行常规备份。当 SAP 系统 24 小时运行时，备份计划变得更加困难。
-
* 数据快速增长。 * 数据快速增长和备份时间不断缩短需要对备份基础架构进行持续投资。也就是说，您必须购买更多的磁带驱动器，更多的备份磁盘空间和更快的备份网络。您还必须支付存储和管理这些磁带资产的持续费用。增量备份或差异备份可以解决这些问题，但这种安排会导致还原过程非常缓慢，繁琐且复杂，难以验证。此类系统通常会以业务无法接受的方式增加恢复时间目标（ RTO ）和恢复点目标（ RPO ）时间。
-
* 停机成本不断增加。 * SAP 系统的计划外停机通常会影响业务财务。在任何计划外停机中，很大一部分是由于需要还原和恢复 SAP 系统而造成的。因此，所需的 RTO 决定了备份和恢复架构的设计。
-
* SAP 升级项目的备份和恢复时间。 * SAP 升级项目计划至少包括 SAP 数据库的三个备份。这些备份可显著缩短升级过程所需的时间。决定是否继续通常取决于从先前创建的备份还原和恢复数据库所需的时间。快速还原可以提供更多时间来解决升级期间可能发生的问题，而不仅仅是将系统还原到先前的状态。
NetApp 解决方案
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 作为一个中央工具来管理数据保护和数据复制。下图显示了备份解决方案 的概述。
Snapshot 备份的运行时
下面的屏幕截图显示了客户在 NetApp 存储上运行 SAP HANA 的 HANA Studio 。客户正在使用 Snapshot 副本备份 HANA 数据库。此图显示，使用 Snapshot 备份技术， HANA 数据库（大小约为 2.3 TB ）将在 2 分 11 秒内备份完毕。
|
整个备份工作流运行时间的最大一部分是执行 HANA 备份保存点操作所需的时间，此步骤取决于 HANA 数据库上的负载。存储 Snapshot 备份本身始终会在几秒钟内完成。 |
恢复时间目标比较
本节将对基于文件的 Snapshot 备份和基于存储的 Snapshot 备份进行 RTO 比较。RTO 由还原数据库所需时间与启动和恢复数据库所需时间之和定义。
还原数据库所需的时间
对于基于文件的备份，还原时间取决于数据库和备份基础架构的大小，该大小定义了还原速度，以 MB/ 秒为单位。例如，如果基础架构支持以 250 MBps 的速度执行还原操作，则还原大小为 1 TB 的数据库大约需要 1 小时 10 分钟。
使用存储 Snapshot 副本备份时，还原时间与数据库大小无关，并且可以从主存储执行还原时，还原时间在几秒的范围内。只有在主存储不再可用时发生灾难时，才需要从二级存储进行还原。
启动数据库所需的时间
数据库开始时间取决于行和列存储的大小。对于列存储，开始时间还取决于数据库启动期间预加载的数据量。在以下示例中，我们假定开始时间为 30 分钟。基于文件的还原和恢复以及基于 Snapshot 的还原和恢复的开始时间相同。
恢复数据库所需的时间
恢复时间取决于还原后必须应用的日志数量。此数字由执行数据备份的频率决定。
对于基于文件的数据备份，备份计划通常每天执行一次。通常不能使用较高的备份频率，因为备份会降低生产性能。因此，在最坏的情况下，在该日写入的所有日志都必须在正向恢复期间应用。
通常， Storage Snapshot 副本数据备份的计划频率较高，因为它们不会影响 SAP HANA 数据库的性能。例如，如果每六小时计划一次 Snapshot 副本备份，则在最坏的情况下，恢复时间将是基于文件的备份恢复时间的四分之一（ 6 小时 /24 小时 = ¼ ）。
下图显示了使用基于文件的数据备份时 1 TB 数据库的 RTO 示例。在此示例中，每天执行一次备份。RTO 因执行还原和恢复的时间而异。如果在创建备份后立即执行还原和恢复，则 RTO 主要基于还原时间，在示例中为 1 小时 10 分钟。在进行下次备份之前立即执行还原和恢复时，恢复时间增加到 2 小时 50 分钟，最大 RTO 为 4 小时 30 分钟。
下图显示了使用 Snapshot 备份时 1 TB 数据库的 RTO 示例。对于基于存储的 Snapshot 备份， RTO 仅取决于数据库开始时间和正向恢复时间，因为还原操作会在几秒钟内完成，而与数据库大小无关。根据还原和恢复的完成时间，正向恢复时间也会增加，但由于备份频率较高（在此示例中为每六小时一次），正向恢复时间最多为 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 的速度下执行恢复。 |