阿里云上的SAP备份指南

3.1.1 云盘快照的工作原理

阿里云云盘快照采用增量快照机制。首次创建快照时，会完整复制云盘上的所有数据；后续每次快照仅记录自上一次快照以来发生变更的数据块。尽管采用增量存储，每个快照在逻辑上都是完整的，可以独立用于恢复操作。

快照数据存储在阿里云的分布式对象存储系统中，具备高可靠性（99.9999999%），与原始云盘的存储介质物理隔离，即使云盘损坏也不影响快照数据的安全性。

3.1.2 自动快照策略配置

通过阿里云控制台或API可以创建自动快照策略，定义快照的创建时间、重复周期和保留天数。建议为SAP S/4HANA系统的所有数据云盘（包括/hana/data、/hana/log、/usr/sap等挂载点对应的云盘）配置自动快照策略。

推荐配置：每日凌晨创建快照，保留7-14天。对于HANA数据盘，应在全量数据库备份之前或之后创建快照，以确保数据一致性。

3.1.3 基于HANA Storage Snapshot的一致性快照

直接对运行中的数据库所在云盘创建快照，可能导致快照数据处于不一致状态（即快照包含部分写入的数据页）。SAP HANA原生提供了Storage Snapshot功能，通过 BACKUP DATA CREATE SNAPSHOT 和 BACKUP DATA CLOSE SNAPSHOT 两个SQL命令，在存储快照创建前后"通知"HANA数据库，使其主动完成Savepoint刷盘并冻结数据文件写入，从而保证快照的应用一致性。

完整流程分为三个步骤：

步骤一：准备HANA内部快照

以具备BACKUP OPERATOR或BACKUP ADMIN权限的用户连接HANA数据库，执行以下SQL命令。HANA会触发Savepoint，将内存中的脏页刷写到磁盘，并冻结数据文件的写入操作：

BACKUP DATA FOR FULL SYSTEM CREATE SNAPSHOT COMMENT '<快照描述信息>';

执行成功后，需要通过查询备份目录获取此次操作的 BACKUP_ID，后续步骤会用到：

SELECT BACKUP_ID FROM M_BACKUP_CATALOG
WHERE ENTRY_TYPE_NAME = 'data snapshot'
  AND STATE_NAME = 'prepared'
ORDER BY UTC_START_TIME DESC;

步骤二：创建阿里云ECS云盘快照

在HANA准备就绪后（此时数据文件处于一致状态），调用阿里云API创建底层存储快照。建议对HANA数据卷（/hana/data）和日志卷（/hana/log）同时创建快照，确保多卷之间的时间点一致性。可以通过阿里云CLI执行：

aliyun ecs CreateSnapshot --DiskId <data-disk-id> --SnapshotName "hana-data-<timestamp>"
aliyun ecs CreateSnapshot --DiskId <log-disk-id> --SnapshotName "hana-log-<timestamp>"

步骤三：确认或放弃快照

根据存储快照是否创建成功，执行对应的SQL命令更新HANA备份目录：

• 快照创建成功时，确认备份并记录外部标识：

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID <backup_id> SUCCESSFUL '<快照标识>';

• 快照创建失败时，放弃本次快照操作：

BACKUP DATA FOR FULL SYSTEM CLOSE SNAPSHOT BACKUP_ID <backup_id> UNSUCCESSFUL;

上述三步流程可以编写自动化脚本，结合cron定时执行。HANA数据文件的冻结时间仅覆盖步骤二（存储快照API调用），通常在秒级完成，对业务影响极小。

3.1.4 跨地域快照复制

对于有容灾需求的场景，可以将快照复制到另一个阿里云地域。通过阿里云控制台或API调用 CopySnapshot 接口，可以将快照从源地域异步复制到目标地域。复制完成后，可以在目标地域基于快照创建云盘并挂载到新的ECS实例，实现跨地域的系统恢复。

3.1.5 快照的恢复流程

当需要通过快照恢复数据时，可以选择以下两种方式：

• 回滚云盘：将云盘回滚到指定快照时间点的状态。此操作需要先停止ECS实例，回滚后实例上的数据将恢复到快照创建时的状态。适用于整盘恢复的场景。

• 基于快照创建云盘：以快照为数据源创建新的云盘，挂载到目标ECS实例上。此方式不影响原有系统的运行，适用于数据验证、测试恢复或部分数据提取的场景。

完成存储层的卷恢复或云盘挂载后，需要启动HANA并执行数据库级别的恢复操作。由于备份时使用了HANA Storage Snapshot机制，恢复时需指定 USING SNAPSHOT 关键字：

• 恢复到快照时间点（不回放日志）：

RECOVER DATA USING SNAPSHOT CLEAR LOG;

• 配合日志备份做时间点恢复（将数据库恢复到快照之后的某个时间点）：

RECOVER DATABASE UNTIL TIMESTAMP '<yyyy-MM-dd HH:mm:ss>' CLEAR LOG USING SNAPSHOT;

如果是MDC多租户环境，需要分别恢复System DB和Tenant DB。System DB使用 recoverSys.py 脚本恢复，Tenant DB通过SQL命令恢复：

RECOVER DATABASE FOR <Tenant-SID> UNTIL TIMESTAMP '<yyyy-MM-dd HH:mm:ss>' CLEAR LOG USING SNAPSHOT;

4.2.1 ossutil工具介绍

ossutil是阿里云提供的OSS命令行工具，支持文件的上传、下载、同步、复制等操作。它是实现文件系统级别备份到OSS的推荐工具。ossutil支持增量同步、断点续传和并发上传，适合大批量文件的备份场景。

安装方式（以Linux x86_64为例）：

curl -o ossutil64 https://gosspublic.alicdn.com/ossutil/install.sh
chmod 755 ossutil64
./ossutil64 config   # 根据提示配置AccessKey和Endpoint

4.2.2 定时备份脚本设计

以下是一个基于cron和ossutil实现定时备份的示例方案。该脚本将SAP关键目录同步到OSS Bucket中，并按日期组织备份数据：

#!/bin/bash
# sap_file_backup.sh - SAP文件系统备份脚本
DATE=$(date +%Y%m%d)
SID="S4H"
BUCKET="oss://sap-backup-bucket"
PREFIX="${BUCKET}/file-backup/${SID}/${DATE}"

# 同步SAP关键目录到OSS
ossutil64 sync /usr/sap/${SID}/ ${PREFIX}/usr_sap_${SID}/ --update
ossutil64 sync /sapmnt/${SID}/ ${PREFIX}/sapmnt_${SID}/ --update
ossutil64 sync /usr/sap/trans/ ${PREFIX}/usr_sap_trans/ --update

# 备份系统配置文件
tar czf /tmp/etc_backup_${DATE}.tar.gz /etc/fstab /etc/hosts /etc/sysconfig/
ossutil64 cp /tmp/etc_backup_${DATE}.tar.gz ${PREFIX}/
rm -f /tmp/etc_backup_${DATE}.tar.gz

将该脚本配置到cron定时任务中：

0 3 * * * /opt/scripts/sap_file_backup.sh >> /var/log/sap_file_backup.log 2>&1

4.2.3 文件级增量备份策略

ossutil的sync命令默认支持增量同步：通过 --update 参数，仅同步源端比目标端更新的文件。这意味着每次执行同步时，只有自上次备份以来发生变更的文件才会被上传到OSS，大幅减少备份时间和带宽消耗。

对于需要保留历史版本的场景，可以启用OSS Bucket的版本控制（Versioning）功能，每次文件更新都会自动保留旧版本，可以按需恢复到任意历史版本。

5.1.1 HANA备份类型

SAP HANA提供三种主要的备份类型：

• 数据备份（Data Backup）：将HANA数据库的持久化数据（数据卷中的数据页和Undo日志）备份到指定目标。数据备份是恢复操作的起点，分为全量备份、增量备份和差异备份三种子类型。

• 日志备份（Log Backup）：将数据库的Redo Log段（Log Segment）备份到指定目标。日志备份在数据备份的基础上，通过回放事务日志实现时间点恢复。HANA在 log_mode 设置为 normal 时自动执行日志备份。

• 快照备份（Storage Snapshot）：利用底层存储的快照能力创建数据库备份。快照备份速度极快，但依赖于存储层的快照功能，且无法单独实现时间点恢复。

5.1.2 备份目标：Backint vs. 文件系统

HANA支持两种备份目标：

对于阿里云上的SAP S/4HANA生产系统，推荐使用Backint接口配合OSS作为主要备份目标，以获得更好的扩展性和容灾能力。

5.1.3 多租户数据库容器（MDC）的备份考量

SAP HANA 2.0采用多租户数据库容器（MDC）架构，一个HANA实例可以承载多个租户数据库（Tenant Database）。在MDC架构下，备份操作需要注意以下几点：

• System DB和每个Tenant DB需要独立配置备份策略和执行备份操作

• System DB的备份包含系统元数据，是恢复整个HANA实例的前提

• Tenant DB的备份可以独立恢复到其他HANA实例，支持跨系统的数据库迁移

• 建议在OSS Backint Agent的配置中使用 storage-prefix 参数区分不同数据库的备份路径

5.2.1 方案架构与工作原理

OSS Backint Agent是阿里云提供的、符合SAP Backint接口标准的备份代理工具。它使SAP HANA能够通过SAP标准的Backint接口，将备份数据直接传输到阿里云对象存储OSS中。

Backint接口标准：SAP Backint for Oracle/SAP HANA是SAP定义的备份集成接口规范。HANA数据库在执行备份时，通过调用Backint代理程序来完成数据的传输操作。Backint代理负责接收HANA发送的数据流，并将其写入到目标存储系统。

管道传输模式：OSS Backint Agent采用管道（Pipe）模式工作。HANA将备份数据以流的形式通过管道传递给Backint Agent，Agent再以分片并发上传的方式将数据写入OSS。这种模式避免了在本地磁盘上生成临时备份文件，节省了本地存储空间。

数据流路径：HANA Database → Pipe → OSS Backint Agent → Multipart Upload → Alibaba Cloud OSS Bucket。整个过程中备份数据不落地本地磁盘，直接从内存流式传输到OSS。

5.2.2 安装与部署

前提条件：

• 已部署SAP HANA数据库的阿里云ECS实例

• 已确定SAP HANA的SID（System Identifier）

• 已创建用于存储备份数据的OSS Bucket（建议与ECS实例在同一地域，使用内网Endpoint传输以节省流量费用）

• ECS实例具备访问OSS的网络连通性

安装步骤：

以用户（如s4hadm）登录HANA所在的ECS实例，执行以下命令：

1. 创建Backint配置目录：

mkdir -p /usr/sap/<SID>/SYS/global/hdb/opt/hdbconfig/

2. 下载安装脚本：

curl -o install.sh https://gosspublic.alicdn.com/hdbbackint/install.sh

3. 执行安装：

chmod +x install.sh && ./install.sh <SID>

4. 验证安装：

/usr/sap/<SID>/SYS/global/hdb/opt/hdbbackint -v

如果安装成功，上述命令将输出OSS Backint Agent的版本信息。

5.2.3 认证方式配置

OSS Backint Agent支持多种认证方式连接阿里云OSS，以下按推荐程度排序：

方式一：ECS RAM角色（推荐）

当HANA部署在阿里云ECS实例上时，推荐使用ECS RAM角色认证。该方式无需在配置文件中保存任何密钥信息，Agent通过ECS实例的元数据服务自动获取临时安全凭证。

# oss-backint-agent.ini
[credentials]
mode = EcsRamRole

前提：需要在阿里云控制台为ECS实例绑定一个RAM角色，并确保该角色具有对目标OSS Bucket的读写权限。

方式二：AccessKey对

直接在配置文件中指定阿里云RAM用户的AccessKey ID和AccessKey Secret。该方式配置简单，但安全性较低，不建议在生产环境中使用。

# oss-backint-agent.ini
[credentials]
access-key-id = <your-access-key-id>
access-key-secret = <your-access-key-secret>

方式三：RAM角色ARN（跨账号场景）

当OSS Bucket属于另一个阿里云账号时，可以使用RAM角色ARN方式，通过STS（Security Token Service）获取临时凭证实现跨账号访问。

# oss-backint-agent.ini
[credentials]
mode = RamRoleArn
access-key-id = <your-access-key-id>
access-key-secret = <your-access-key-secret>
role-arn = acs:ram::<account-id>:role/<role-name>
role-session-name = backint-session

方式四：外部进程自定义认证

通过配置一个外部可执行程序来获取认证凭证。Agent会调用该程序并解析其JSON格式的输出以获取临时凭证。适用于需要集成企业内部密钥管理系统的场景。

# oss-backint-agent.ini
[credentials]
mode = Process
process-command = /usr/local/bin/get_credentials.sh

5.2.4 核心配置参数详解

OSS Backint Agent的配置文件为 oss-backint-agent.ini，以下是各类参数的详细说明：

基础参数

性能调优参数

内存消耗估算公式：峰值内存 ≈ job × pipe-parallel × pipe-part-size。例如默认配置下：5 × 3 × 6 MiB = 90 MiB。对于大型数据库，可以适当增大 pipe-part-size 以提升传输效率，但需注意内存消耗的相应增长。

存储策略参数

加密配置参数

网络与日志参数

5.2.5 启用Backint备份

完成OSS Backint Agent的安装和配置后，需要在HANA数据库中启用Backint作为备份目标。

步骤一：配置HANA使用Backint进行数据备份

以SYSTEM用户连接HANA数据库，执行以下SQL命令：

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('backup', 'catalog_backup_using_backint') = 'true'
WITH RECONFIGURE;

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('backup', 'data_backup_parameter_file') =
'/usr/sap/<SID>/SYS/global/hdb/opt/hdbconfig/oss-backint-agent.ini'
WITH RECONFIGURE;

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('backup', 'log_backup_using_backint') = 'true'
WITH RECONFIGURE;

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('backup', 'log_backup_parameter_file') =
'/usr/sap/<SID>/SYS/global/hdb/opt/hdbconfig/oss-backint-agent.ini'
WITH RECONFIGURE;

步骤二：设置日志模式

为支持时间点恢复，需要将HANA的日志模式设置为 normal（默认值为 overwrite）：

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('persistence', 'log_mode') = 'normal'
WITH RECONFIGURE;

步骤三：验证配置

执行测试备份以验证Backint通道是否正常工作：

BACKUP DATA USING BACKINT ('oss-backint-agent-test');

如果备份成功完成且没有报错，说明OSS Backint Agent已正确配置。可以登录阿里云OSS控制台，在目标Bucket中确认备份文件已生成。

5.2.6 数据备份操作

全量数据备份

通过SAP HANA Studio、HANA Cockpit或SQL命令执行全量数据备份：

BACKUP DATA USING BACKINT ('COMPLETE_DATA_BACKUP');

备注：括号中的字符串为备份前缀（Backup Prefix），用于标识备份用途，可自定义。

增量与差异数据备份

增量备份和差异备份可以显著减少备份时间和存储空间：

-- 增量备份（自上次任意类型备份以来的变更）
BACKUP DATA INCREMENTAL USING BACKINT ('INCR_BACKUP');

-- 差异备份（自上次全量备份以来的变更）
BACKUP DATA DIFFERENTIAL USING BACKINT ('DIFF_BACKUP');

备份调度

建议通过以下方式设置自动备份调度：

• SAP DBA Cockpit / DB13：SAP提供的标准数据库管理工具，可以在SAP GUI中配置备份计划。适用于SAP Basis管理员。

• 操作系统crontab：通过cron定时执行hdbsql命令实现备份调度。灵活性高，适合运维自动化场景。

  crontab示例（每日凌晨2点执行全量备份）：

0 2 * * * /usr/sap/<SID>/HDB<inst>/exe/hdbsql -U BACKUP_KEY "BACKUP DATA USING BACKINT ('DAILY_FULL')"

5.2.7 日志备份配置

日志备份是实现时间点恢复的关键组件。在HANA的日志模式设置为 normal 且启用了Backint日志备份后，HANA会在日志段（Log Segment）写满时自动触发日志备份。

自动日志备份：当 log_mode = normal 且 log_backup_using_backint = true 时，HANA会自动将写满的日志段通过Backint Agent传输到OSS。

日志备份间隔：可以通过以下参数控制日志备份的最大间隔时间，确保即使在低负载期间（日志段未写满时）也能定期执行日志备份：

ALTER SYSTEM ALTER CONFIGURATION ('global.ini', 'SYSTEM')
SET ('persistence', 'log_backup_timeout_s') = '900'
WITH RECONFIGURE;

上述配置将日志备份的最大间隔设置为900秒（15分钟），即使日志段未写满，也会在15分钟后自动触发备份。根据RPO需求调整此值。

5.2.8 备份监控与管理

HANA Studio / SAP HANA Cockpit监控

SAP HANA Studio和HANA Cockpit提供了图形化的备份监控界面，可以查看备份历史记录、备份状态、备份耗时和备份大小等信息。建议运维团队定期检查备份状态，及时发现并处理备份失败的情况。

备份目录（Backup Catalog）管理

HANA维护一个备份目录（Backup Catalog），记录所有历史备份的元数据信息。随着时间推移，备份目录会持续增长，建议定期清理过期的备份目录条目：

-- 查看备份目录
SELECT * FROM M_BACKUP_CATALOG ORDER BY UTC_START_TIME DESC;

-- 删除指定日期之前的备份目录条目（同时删除OSS中的备份文件）
BACKUP CATALOG DELETE ALL BEFORE TIMESTAMP '2026-01-01 00:00:00'
USING BACKINT COMPLETE;

OSS侧备份文件的生命周期管理

通过阿里云OSS的生命周期规则（Lifecycle Rule），可以自动将老旧的备份数据转换为更低成本的存储类型，或在超过保留期限后自动删除：

• 近期备份（0-30天）：保持标准存储（Standard），保证快速恢复能力

• 中期备份（30-90天）：自动转换为低频访问存储（IA），降低约50%存储成本

• 长期备份（90天以上）：自动转换为归档存储（Archive），存储成本降低至标准存储的约25%

5.3.1 全量恢复

全量恢复将数据库恢复到最近一次数据备份的状态。在HANA Studio或Cockpit中选择目标备份进行恢复，或使用命令行方式：

-- 停止HANA数据库
HDB stop

-- 使用hdbnsutil执行恢复
hdbnsutil -recoverSys --command="RECOVER DATA USING BACKINT"

全量恢复适用于数据库完全损坏、需要回滚到已知良好状态等场景。

5.3.2 时间点恢复（Point-in-Time Recovery）

时间点恢复允许将数据库恢复到过去任意时间点的状态，前提是：拥有该时间点之前的一个完整数据备份，以及从该备份到目标时间点之间的所有日志备份。

RECOVER DATABASE UNTIL TIMESTAMP '2026-03-20 14:30:00'
USING BACKINT;

时间点恢复是应对数据误操作（如误删表、错误的批量更新）最有效的恢复手段。

5.3.3 归档存储类型对象的解冻注意事项

如果备份数据已通过生命周期规则转换为归档存储类型（Archive），在执行恢复操作前，必须先将相关备份对象解冻（Restore/Unfreeze）。归档存储的解冻通常需要1-5分钟（快速解冻模式）或数小时（标准解冻模式），这将直接影响恢复的RTO。

建议在OSS生命周期策略中，为可能需要紧急恢复的近期备份保留标准存储类型，仅对确定不需要快速恢复的长期备份使用归档存储。

5.3.4 恢复演练建议

备份方案的有效性必须通过定期恢复演练来验证。建议：

1. 每季度至少执行一次完整的数据库恢复演练，覆盖全量恢复和时间点恢复两种场景

2. 恢复演练应在独立的测试环境中进行，避免影响生产系统

3. 记录每次恢复演练的耗时、遇到的问题和改进措施，持续优化恢复流程

4. 将恢复演练纳入运维团队的标准操作流程（SOP），确保相关人员熟悉恢复步骤