最佳实践
使用适用于ONTAP 的Amazon FSX进行备份和恢复
建议更改
PDF
您可以使用NetApp Snapshot技术在几分钟内创建数据库备份。
创建 Snapshot 副本所需的时间与数据库大小无关，因为 Snapshot 副本不会移动存储平台上的任何物理数据块。此外，使用 Snapshot 技术不会影响实时 SAP 系统的性能。因此，您可以计划创建 Snapshot 副本，而无需考虑对话峰值或批处理活动期间。SAP和NetApp客户通常会在一天内计划多个联机Snapshot备份；例如、每六小时备份一次很常见。这些Snapshot备份通常会在主存储系统上保留三到五天、然后再被删除或分层到更便宜的存储中以供长期保留。
Snapshot 副本还为还原和恢复操作提供了主要优势。通过NetApp SnapRestore 技术、可以根据当前可用的Snapshot副本将整个数据库或数据库的一部分还原到任意时间点。无论数据库大小如何，此类还原过程都只需几秒钟即可完成。由于在一天中可以创建多个联机Snapshot备份、因此与传统的每天一次备份方法相比、恢复过程所需的时间显著减少。由于您可以使用最长只有几小时(而不是长达24小时)的Snapshot副本执行还原、因此在正向恢复期间必须应用的事务日志更少。因此、RTO会减少到几分钟、而不是传统流式备份所需的几小时。
Snapshot 副本备份与活动联机数据存储在同一磁盘系统上。因此， NetApp 建议使用 Snapshot 副本备份作为对备份到二级位置的补充，而不是替代。大多数还原和恢复操作都通过在主存储系统上使用SnapRestore 进行管理。只有当包含 Snapshot 副本的主存储系统损坏时，才需要从二级位置进行还原。如果需要还原主位置上不再可用的备份、也可以使用二级位置。
到二级位置的备份基于在主存储上创建的 Snapshot 副本。因此，直接从主存储系统读取数据，而不会在 SAP 数据库服务器上生成负载。主存储直接与二级存储通信、并使用NetApp SnapVault 功能将备份数据复制到目标。
与传统备份相比， SnapVault 具有显著优势。在初始数据传输之后、所有数据都已从源传输到目标、所有后续备份副本只会将更改后的块移动到二级存储。因此，主存储系统上的负载以及完整备份所需的时间会显著减少。由于SnapVault 仅在目标上存储更改过的块、因此任何额外的完整数据库备份所占用的磁盘空间都会显著减少。
Snapshot备份和还原操作的运行时
下图显示了客户使用Snapshot备份操作的HANA Studio。此图显示、使用Snapshot备份技术、HANA数据库(大小约为4 TB)可在1分20秒内完成备份、而使用基于文件的备份操作则可在4小时以上完成备份。
整个备份工作流运行时间的最大一部分是执行HANA备份保存点操作所需的时间、此步骤取决于HANA数据库上的负载。存储 Snapshot 备份本身始终会在几秒钟内完成。
恢复时间目标比较
本节将对基于文件的Snapshot备份和基于存储的Snapshot备份进行恢复时间目标(RTO)比较。RTO由还原、恢复然后启动数据库所需的时间之和定义。
还原数据库所需的时间
对于基于文件的备份，还原时间取决于数据库和备份基础架构的大小，该大小定义了还原速度，以 MB/ 秒为单位。例如、如果基础架构支持以250 MBps的速度执行还原操作、则需要大约4.5小时才能在永久性的情况下还原大小为4 TB的数据库。
对于存储Snapshot副本备份、还原时间与数据库大小无关、并且始终在几秒的范围内。
启动数据库所需的时间
数据库开始时间取决于数据库大小以及将数据加载到内存所需的时间。在以下示例中、假设数据可以加载1000 Mbps。将4 TB的容量加载到内存大约需要1小时10分钟。基于文件和基于Snapshot的还原和恢复操作的开始时间相同。
恢复数据库所需的时间
恢复时间取决于还原后必须应用的日志数量。此数字由执行数据备份的频率决定。
对于基于文件的数据备份，备份计划通常每天执行一次。通常不能使用较高的备份频率，因为备份会降低生产性能。因此，在最坏的情况下，在该日写入的所有日志都必须在正向恢复期间应用。
快照备份的计划频率通常较高、因为它们不会影响SAP HANA数据库的性能。例如、如果每六小时计划一次Snapshot备份、则在最坏的情况下、恢复时间将是基于文件的备份恢复时间的四分之一(6小时/24小时=.25)。
下图显示了还原和恢复操作与基于文件的每日备份和具有不同计划的Snapshot备份的比较。
前两个条形显示、即使每天只备份一个Snapshot、由于Snapshot备份的还原操作速度较快、还原和恢复也会减少到43%。如果每天创建多个Snapshot备份、则可以进一步减少运行时间、因为在正向恢复期间需要应用的日志更少。
下图还显示、每天有四到六个Snapshot备份最有意义、因为更高的频率不再对整体运行时间产生重大影响。
加速备份和克隆操作的用例和值
执行备份是任何数据保护策略的关键部分。系统会定期计划备份、以确保您可以从系统故障中恢复。这是最明显的使用情形、但也有其他SAP生命周期管理任务、在这些任务中、加快备份和恢复操作至关重要。
SAP HANA系统升级就是一个示例、其中、升级前的按需备份以及升级失败后可能执行的还原操作会对整体计划内停机造成重大影响。以4TB数据库为例、您可以使用基于Snapshot的备份和还原操作将计划内停机时间减少8小时。
另一个用例示例是典型的测试周期、在此周期中、必须使用不同的数据集或参数通过多个迭代执行测试。在利用快速备份和还原操作时、您可以轻松地在测试周期内创建保存点、并在测试失败或需要重复时将系统重置为上述任一保存点。这样可以提前完成测试、也可以同时完成更多测试、并提高测试结果。
实施Snapshot备份后、可以使用这些备份来解决其他多种使用情形、这些使用情形需要一个HANA数据库的副本。使用适用于ONTAP 的FSX、您可以根据任何可用Snapshot备份的内容创建新卷。此操作的运行时间为几秒、与卷大小无关。
最常见的使用情形是SAP系统更新、其中需要将生产系统中的数据复制到测试或QA系统。通过利用适用于ONTAP 克隆的FSX功能、您可以在几秒钟内从生产系统的任何Snapshot副本为测试系统配置卷。然后、必须将新卷连接到测试系统并恢复HANA数据库。
第二种使用情形是创建修复系统、用于解决生产系统中的逻辑损坏问题。在这种情况下、使用生产系统的旧Snapshot备份来启动修复系统、该修复系统是生产系统的一个克隆、与发生损坏之前的数据完全相同。然后、使用修复系统分析问题并在所需数据损坏之前导出这些数据。
最后一个使用情形是、能够在不停止复制的情况下运行灾难恢复故障转移测试、从而不影响灾难恢复设置的RTO和恢复点目标(RPO)。当使用适用于ONTAP 的FSX NetApp SnapMirror复制将数据复制到灾难恢复站点时、生产Snapshot备份也可在灾难恢复站点上使用、然后可用于创建新卷以进行灾难恢复测试。
