常见问题 - 备份 Azure VM 上的 SAP HANA 数据库Frequently asked questions - Back up SAP HANA databases on Azure VMs

本文解答有关使用 Azure 备份服务备份 SAP HANA 数据库的常见问题。This article answers common questions about backing up SAP HANA databases using the Azure Backup service.


每天支持多少次完整备份?How many full backups are supported per day?

每天仅支持一次完整备份。We support only one full backup per day. 不能在同一天触发差异备份和完整备份。You can't have differential backup and full backup triggered on the same day.

成功的备份作业是否会创建警报?Do successful backup jobs create alerts?

否。No. 成功的备份作业不会生成警报。Successful backup jobs don't generate alerts. 仅针对失败的备份作业发送警报。Alerts are sent only for backup jobs that fail. 此文介绍了门户警报的详细行为。Detailed behavior for portal alerts is documented here. 但是,如果希望在作业成功的情况下也收到警报,可以使用 Azure MonitorHowever, if you're interested having alerts even for successful jobs, you can use Azure Monitor.

“备份作业”菜单中是否会显示计划的备份作业?Can I see scheduled backup jobs in the Backup Jobs menu?

“备份作业”菜单只显示按需备份作业。The Backup Job menu will only show on-demand backup jobs. 对于计划的作业,请使用 Azure MonitorFor scheduled jobs, use Azure Monitor.

未来的数据库会自动添加备份吗?Are future databases automatically added for backup?

否,目前不支持该功能。No, this isn't currently supported.

如果从实例中删除数据库,备份会发生什么情况?If I delete a database from an instance, what will happen to the backups?

如果从 SAP HANA 实例中删除某个数据库,仍会尝试数据库备份。If a database is dropped from an SAP HANA instance, the database backups are still attempted. 这意味着,已删除的数据库会在“备份项”下显示为不正常状态,但仍受保护。This implies that the deleted database begins to show up as unhealthy under Backup Items and is still protected. 停止保护此数据库的正确方法是针对此数据库执行“停止备份并删除数据”操作。The correct way to stop protecting this database is to perform Stop Backup with delete data on this database.

如果在保护数据库后更改其名称,会出现怎样的行为?If I change the name of the database after it has been protected, what will the behavior be?

已重命名的数据库被视为新数据库。A renamed database is treated as a new database. 因此,服务会将此情况视为找不到数据库,会使备份失败。Therefore, the service will treat this situation as if the database weren't found and will fail the backups. 已重命名的数据库会显示为新数据库,必须对其进行保护性配置。The renamed database will appear as a new database and must be configured for protection.

备份 Azure VM 上的 SAP HANA 数据库的先决条件是什么?What are the prerequisites to back up SAP HANA databases on an Azure VM?

请参阅先决条件预注册脚本的功能部分。Refer to the prerequisites and What the pre-registration script does sections.

应设置哪些权限以便 Azure 可以备份 SAP HANA 数据库?What permissions should be set so Azure can back up SAP HANA databases?

运行预注册脚本即可设置所需的权限,这样 Azure 就可以备份 SAP HANA 数据库。Running the pre-registration script sets the required permissions to allow Azure to back up SAP HANA databases. 可以在此处详细了解预注册脚本的功能。You can find more about what the pre-registration script does here.

将 SAP HANA 从 SDC 迁移到 MDC 后,备份是否正常进行?Will backups work after migrating SAP HANA from SDC to MDC?

请参考故障排除指南中的说明Refer to this section of the troubleshooting guide.

在同一版本中升级时应执行什么操作?What should be done while upgrading within the same version?

请参阅故障排除指南中的此部分Refer to this section in the troubleshooting guide.

是否可以针对虚拟 IP(负载均衡器)而不是虚拟机设置 Azure HANA 备份?Can Azure HANA Backup be set up against a virtual IP (load balancer) and not a virtual machine?

目前,我们无法设置单独针对虚拟 IP 的解决方案。Currently we don't have the capability to set up the solution against a virtual IP alone. 执行此解决方案需要使用虚拟机。We need a virtual machine to execute the solution.

如何将按需备份移动到本地文件系统而不是 Azure 保管库?How can I move an on-demand backup to the local file system instead of the Azure vault?

  1. 等待当前正在运行的备份在目标数据库上完成(可从工作室检查是否已完成)。Wait for the currently running backup to complete on the desired database (check from studio for completion).
  2. 按照以下步骤禁用日志备份并将目录备份设置为所需 DB 的文件系统:Disable log backups and set the catalog backup to Filesystem for the desired DB using the following steps:
  3. 双击“SYSTEMDB” -> “配置” -> “选择数据库” -> “筛选器(日志)” 。Double-click SYSTEMDB -> configuration -> Select Database -> Filter (log)
    1. 将 enable_auto_log_backup 设置为“no”。Set enable_auto_log_backup to no.
    2. 将 catalog_backup_using_backint 设置为“false”。Set catalog_backup_using_backint to false.
  4. 在所需的数据库上执行按需备份(完整/差异/增量),并等待备份和目录备份完成。Take an on-demand backup (full / differential/ incremental) on the desired database, and wait for the backup and catalog backup to complete.
  5. 如果还要将日志备份移动到文件系统,请将 enable_auto_log_backup 设置为“yes”。If you want to also move the log backups to the Filesystem, set enable_auto_log_backup to yes.
  6. 恢复到以前的设置,以允许备份流向 Azure 保管库:Revert to the previous settings to allow backups to flow to the Azure vault:
    1. 将 enable_auto_log_backup 设置为“yes”。Set enable_auto_log_backup to yes.
    2. 将 catalog_backup_using_backint 设置为“true”。Set catalog_backup_using_backint to true.


如果将备份移动到本地文件系统并再次切换回 Azure 保管库,则可能会导致保管库中日志备份的日志链中断。Moving backups to the local Filesystem and switching back again to the Azure vault may cause a log chain break of the log backups in the vault. 这会触发完整备份,成功完成后,将开始备份日志。This will trigger a full backup, which once successfully completed will start backing up the logs.

如何在设置 HANA 复制的情况下使用 SAP HANA 备份?How can I use SAP HANA Backup with my HANA Replication set-up?

目前,Azure 备份不能理解 HSR 设置。Currently, Azure Backup doesn't have the capability to understand an HSR set-up. 这意味着,HSR 的主节点和辅助节点将被视为两个不相关的独立 VM。This means that the primary and secondary nodes of the HSR will be treated as two individual, unrelated VMs. 你首先需要在主节点上配置备份。You'll first need to configure backup on the primary node. 发生故障转移时,必须在辅助节点(现在变为主节点)上配置备份。When a fail-over happens, backup must be configured on the secondary node (which now becomes the primary node). 不会自动将备份故障转移到另一个节点。There's no automatic fail-over of backup to the other node.

若要在任意给定时间点对活动(主)节点中的数据进行备份,可以将保护切换到辅助节点(它在故障转移后成为主节点)。To back up data from the active (primary) node at any given point in time, you can switch protection to the secondary node, which has now become the primary after fail-over.

若要执行此切换保护操作,请完成以下步骤:To perform this switch protection, follow these steps:

每次故障转移后都必须手动执行这些步骤。These steps must be performed manually after every fail-over. 除了 Azure 门户之外,还可以通过命令行/HTTP REST 执行这些步骤。You can perform these steps through command line / HTTP REST in addition to the Azure portal. 若要自动执行这些步骤,可以使用 Azure runbook。To automate these steps, you can use an Azure runbook.

以下详细示例介绍切换保护必须如何进行执行:Here is a detailed example of how switch protection must be performed:

在本例中,HSR 设置中有两个节点 - 节点 1(主节点)和节点 2(辅助节点)。In this example, you have two nodes - Node 1 (primary) and Node 2 (secondary) in the HSR set-up. 对节点 1 配置备份。Backups are configured on Node 1. 如上所述,请不要尝试对节点 2 配置备份。As mentioned above, don't attempt yet to configure backups on Node 2.

发生首次故障转移时,节点 2 将变为主节点。When the first failover happens, Node 2 becomes the primary. 那么:Then,

  1. 使用“保留数据”选项停止对节点 1(以前的主节点)的保护。Stop protection of Node 1 (previous primary) with the retain data option.
  2. 在节点 2(现在是主节点)上运行预注册脚本。Run the pre-registration script on Node 2 (which is now the primary).
  3. 在节点 2 上发现数据库,分配备份策略并配置备份。Discover databases on Node 2, assign backup policy, and configure backups.

然后,在节点 2 上触发第一次完整备份,并在该备份完成后启动日志备份。Then a first full backup is triggered on Node 2 and after that completes, log backups start.

发生下一次故障转移时,节点 1 再次成为主节点,节点 2 变为辅助节点。When the next fail-over happens, Node 1 becomes primary again and Node 2 becomes secondary. 现在,重复此过程:Now repeat the process:

  1. 使用“保留数据”选项停止对节点 2 的保护。Stop protection of Node 2 with retain data option.
  2. 在节点 1(已再次成为主节点)上运行预注册脚本Run the pre-registration script on Node 1 (which has become the primary again)
  3. 然后使用所需的策略在节点 1 上恢复备份(因为备份之前已在节点 1 上停止)。Then Resume backup on Node 1 with the required policy (as the backups were stopped earlier on Node 1).

然后,在节点 1 上再次触发完整备份,并在该备份完成后启动日志备份。Then full backup will again be triggered on Node 1 and after that completes, log backups start.


为什么我看不到要将数据库还原到的 HANA 系统?Why can't I see the HANA system I want my database to be restored to?

检查是否满足还原到目标 SAP HANA 实例所需的所有先决条件。Check if all the prerequisites for the restore to target SAP HANA instance are met. 有关详细信息,请参阅先决条件 - 还原 Azure VM 中的 SAP HANA 数据库For more information, see Prerequisites - Restore SAP HANA databases in Azure VM.

为什么我的数据库的“覆盖 DB”还原会失败?Why is the Overwrite DB restore failing for my database?

请确保在还原时选中“强制覆盖”选项。Ensure that the Force Overwrite option is selected while restoring.

为什么会出现“还原的源系统和目标系统不兼容”错误?Why do I see the "Source and target systems for restore are incompatible" error?

请参阅 SAP HANA 说明 1642148,了解目前支持的还原类型。Refer to the SAP HANA Note 1642148 to see what restore types are currently supported.

是否可以使用在 SLES 上运行的数据库的备份还原到 RHEL HANA 系统,或者反向操作?Can I use a backup of a database running on SLES to restore to an RHEL HANA system or vice versa?

是的,可以使用在 SLES 上运行的 HANA 数据库上触发的流备份将其还原到 RHEL HANA 系统,反之亦然。Yes, you can use streaming backups triggered on a HANA database running on SLES to restore it to an RHEL HANA system and vice versa. 也就是说,可以使用流备份进行跨操作系统还原。That is, cross OS restore is possible using streaming backups. 但是,必须确保要还原到的 HANA 系统以及用于还原的 HANA 系统都是兼容的,以便按照 SAP 的要求进行还原。However, you'll have to ensure that the HANA system you want to restore to, and the HANA system used for restore, are both compatible for restore according to SAP. 请参阅 SAP HANA 说明 1642148,了解兼容的还原类型。Refer to SAP HANA Note 1642148 to see which restore types are compatible.


为 SAP HANA 备份创建新策略时可用的不同选项Different options available during creation of a new policy for SAP HANA backup

在创建策略之前,你应该清楚 RPO 和 RTO 的要求及其相关的成本影响。Before creating a policy, you should be clear on the requirements of RPO and RTO and its relevant cost implications.

RPO(恢复点目标)表示用户/客户可接受的数据丢失量。RPO (Recovery-point-objective) indicates how much data loss is acceptable for the user/customer. 这取决于日志备份频率。This is determined by the log backup frequency. 日志备份越频繁表示 RPO 越低,Azure 备份服务支持的最小值为 15 分钟。More frequent log backups indicate lower RPO and the minimum value supported by Azure Backup service is 15 minutes. 因此,日志备份频率可以为 15 分钟或更长时间。So log backup frequency can be 15 minutes or higher.

RTO(恢复时间目标)表示在发生数据丢失情况后,应当以多快的速度将数据还原到上一个可用时间点。RTO (Recovery-time-objective) indicates how fast the data should be restored to the last available point-in-time after a data loss scenario. 这取决于 HANA 所采用的恢复策略,该策略通常取决于需要还原的文件数量。This depends on the recovery strategy employed by HANA, which is usually dependent on how many files are required for restore. 这也会影响成本,下表应当有助于你理解所有方案及其影响。This has cost implications as well, and the following table should help in understanding all scenarios and their implications.

备份策略Backup policy RTORTO 节约成本Cost
每日完整备份 + 日志Daily Full + logs 最快,因为我们只需要一个完整副本 + 所需日志来执行时间点还原Fastest, since we need only one full copy + required logs for point-in-time restore 成本最高的选项,因为每天都要创建一个完整的副本,所以越来越多的数据会累积在后端,直至保留期到期Costliest option since a full copy is taken daily and so more and more data is accumulated in backend until the retention time
每周完整备份 + 每日差异备份 + 日志Weekly Full + daily differential + logs 比上一选项慢,但比下一选项快,因为我们需要一个完整副本 + 一个差异副本 + 日志来执行时间点还原Slower than the above option, but faster than the next option since we require one full copy + one differential copy + logs for point-in-time restore 成本较低的选项,因为每日差异备份通常小于完整备份,而每周只创建一个完整副本Less expensive option since the daily differential is usually smaller than full and a full copy is taken only once a week
每周完整备份 + 每日增量备份 + 日志Weekly Full + daily incremental + logs 最慢,因为我们需要一个完整副本 + n 个增量副本 + 日志来执行时间点恢复Slowest since we need one full copy + 'n' incrementals + logs for point-in-time recovery 成本最低的选项,因为每日增量备份会小于差异备份,并且每周只创建一个完整副本Least expensive option since the daily incremental will be smaller than differential and a full copy is taken only weekly


以上选项是最常用的选项,但并不是唯一的选项。The above options are the most common, but not the only options. 例如,你可以每周执行一次完整备份 + 每周两次差异备份 + 日志。For example, you can have a weekly full backup + differentials twice a week + logs.

因此,可以根据 RPO 和 RTO 目标以及成本注意事项来选择策略变体。Therefore, you can select the policy variant based on RPO and RTO objectives and cost considerations.

修改策略会带来的影响Impact of modifying a policy

确定将备份项的策略从策略 1 (P1) 切换到策略 2 (P2) 或编辑策略 1 (P1) 会带来的影响时,应牢记几个原则。A few principles should be kept in mind when determining the impact of switching a backup item's policy from Policy 1 (P1) to Policy 2 (P2) or of editing Policy 1 (P1).

  • 所有更改还会以追溯方式应用。All changes are also applied retroactively. 最新的备份策略也会应用于先前创建的恢复点。The latest backup policy is applied on the recovery points taken earlier as well. 例如,假设每日完整备份的保留期为 30 天,并且根据当前正生效的策略创建了 10 个恢复点。For example, assume that the daily full retention is 30 days and 10 recovery points were taken according to the currently active policy. 如果每日完整备份的保留期更改为 10 天,则上一个恢复点的到期时间也会重新计算为开始时间 + 10 天。如果到期时间已过,则会将其删除。If the daily full's retention is changed to 10 days, then the previous point's expiry time is also recalculated as start time + 10 days and deleted if they're expired.
  • 更改范围还包括备份日期、备份类型以及保留期。The scope of change also includes day of backup, type of backup along with retention. 例如:如果策略在星期日从每日完整备份更改为每周完整备份,则不在星期日的所有以前的完整备份将标记为待删除。For example: If a policy is changed from daily full to weekly full on Sundays, all earlier fulls that aren't on Sundays will be marked for deletion.
  • 在子级处于活动状态/未到期之前,不会删除父级。A parent isn't deleted until the child is active/not-expired. 每个备份类型都有一个过期时间,这取决于当前生效的策略。Every backup type has an expiration time according to the currently active policy. 但是,完整备份类型会被视为后续的“差异”、“增量”和“日志”的父级。But a full backup type is considered as parent to subsequent 'differentials', 'incrementals' and 'logs'. “差异”和“日志”不是任何其他项的父级。A 'differential' and a 'log' aren't parents to anyone else. “增量”可以是后续“增量”的父级。An 'incremental' can be a parent to subsequent 'incremental'. 即使某个“父级”被标记为待删除,如果子级“差异”或“日志”未过期,也不会实际删除父级。Even if a 'parent' is marked for deletion, it's not actually deleted if the child 'differentials' or 'logs' aren't expired. 例如,如果策略在星期日从每日完整备份更改为每周完整备份,则不在星期日的所有以前的完整备份将标记为待删除。For example, if a policy is changed from daily full to weekly full on Sundays, all earlier fulls that aren't on Sundays will be marked for deletion. 但在之前每天创建的日志过期之前,不会实际删除它们。But they aren't actually deleted until the logs that were taken daily earlier are expired. 换句话说,将根据最新的日志保留期保留它们。In other words, they're retained according to the latest log duration. 日志过期后,日志和这些完整备份都会被删除。Once the logs expire, both the logs and these fulls will be deleted.

你可以根据这些原则阅读下表来了解策略更改的影响。With these principles, you can read the following table to understand the implications of a policy change.

旧策略/新策略Old policy/ New policy 每日完整备份 + 日志Daily fulls + logs 每周完整备份 + 每日差异备份 + 日志Weekly fulls + daily differentials + logs 每周完整备份 + 每日增量备份 + 日志Weekly fulls + daily incrementals + logs
每日完整备份 + 日志Daily fulls + logs - 不在一周中同一天创建的上一个完整备份将被标记为待删除,但会一直保留到日志保留期到期The previous fulls that aren't on the same day of the week are marked for deletion but kept until the log retention period 不在一周中同一天创建的上一个完整备份将被标记为待删除,但会一直保留到日志保留期到期The previous fulls that aren't on the same day of the week are marked for deletion but kept until the log retention period
每周完整备份 + 每日差异备份 + 日志Weekly fulls + daily differentials + logs 将根据最新策略重新计算以前的每周完整备份的保留期。The previous weekly fulls retention is recalculated as per latest policy. 将立即删除以前的差异备份The previous differentials are immediately deleted - 将立即删除以前的差异备份The previous differentials are immediately deleted
每周完整备份 + 每日增量备份 + 日志Weekly fulls + daily incrementals + logs 将根据最新策略重新计算以前的每周完整备份的保留期。The previous weekly fulls retention is recalculated as per latest policy. 将立即删除以前的增量备份The previous incrementals are immediately deleted 将立即删除以前的增量备份The previous incrementals are immediately deleted -

后续步骤Next steps

了解如何备份 SAP HANA 数据库(在 Azure VM 上运行)。Learn how to back up SAP HANA databases running on Azure VMs.