OceanBase备份常见问题

备份介质常见问题
- [NFS Hung问题](#NFS Hung问题)
- 对象存储问题
数据备份常见问题
数据备份调优

⭐️日志归档和数据备份的关系：

日志归档可以单独开启，不依赖数据备份。需要开启日志归档的场景：
- OMS增量/反向增量同步
- 主备租户（基于日志传输）
- 克隆租户
数据备份必须先开启日志归档，后续可以关闭归档，但会影响数据恢复完整性。
日志归档+数据备份=全量数据，即可以恢复到归档期间任意时间点位。

⭐️备份目录结构示例：

bash 复制代码

[admin@observer ~]$ tree -L 4 /obbak
/obbak
└── nfs
    ├── arch               #--> 归档路径
    │   ├── check_file  
    │   ├── format.obbak                         # 归档路径的格式化信息
    │   ├── piece_d1001r1p1                      # piece目录，命名格式为piece_dsetID_roundID_pieceID
    │   ├── pieces                               # piece占位符目录
    │   └── rounds                               # rounds占位符目录
    └── data               #--> 备份路径
        ├── backup_set_1_full       # 全量备份集1
        │   ├── backup_set_1_full_20260414T153714_20260414T153714.obbak  # 占位符，展示全量备份的开始和结束时间
        │   ├── complement_log
        │   ├── infos
        │   ├── logstream_1                      # 1号日志流
        │   ├── logstream_1001                   # 1001号日志流
        │   ├── single_backup_set_info.obbak     # 当前备份集的元信息
        │   └── tenant_backup_set_infos.obbak    # 当前租户的全量备份集信息
        ├── backup_set_2_inc        # 增量备份集2
        │   ├── backup_set_2_inc_20260415T130905_20260415T131102.obbak
        │   ├── infos
        │   ├── logstream_1
        │   ├── logstream_1001
        │   ├── single_backup_set_info.obbak
        │   └── tenant_backup_set_infos.obbak
        ├── backup_sets             # 数据备份列表的汇总目录，记录了所有的数据备份集列表
        │   ├── backup_set_1_full_end_success_20260414T153714.obbak   # 全量备份结束占位符
        │   ├── backup_set_1_full_start.obbak                         # 全量备份起始占位符
        │   ├── backup_set_2_inc_end_success_20260415T131102.obbak    # 增量备份结束占位符
        │   └── backup_set_2_inc_start.obbak                          # 增量备份起始占位符
        ├── check_file
        │   └── 1004_connect_file_20260414T153253.obbak   # 连通性检查文件
        └── format.obbak                                  # 备份路径的格式化信息

21 directories, 17 files

⚠️ 当前日志归档的清理依赖数据备份的清理策略，即日志归档无法单独清理，单独开启日志归档的场景需要清理时，其实就是删除历史的piece目录。

备份介质常见问题

NFS Hung问题

对observer的影响：

NFS hung以后会导致Linux的load变大，影响observer的性能。
访问NFS的归档、备份、清理、恢复的线程会被NFS的请求hung住，导致这些后台线程无法释放。

⭐️ NFS Hung常见现象

dmesg出现nfs相关的错误日志。通过dmesg | grep -i nfs判断。
系统日志/var/log/messages出现nfs相关的错误。通过grep -i nfs /var/log/messages判断。

bash 复制代码

Jan 18 05:25:45 observer1 kernel: [<ffffffffc09b6a3a>] ? nfs initiate_pgio+0xda/0x160 [nfs]
Jan 18 05:25:45 observer1 kernel: [<ffffffffc0a701c7>] nfs4_file_fsync+0x87/0x170 [nfsv4]
Jan 18 05:25:45 observer1 kernel: [<ffffffffc09ab9fb>] nfs_file write+0xbb/0x1e0 [nfs]
Jan 18 05:25:45 observer1 kernel: [<ffffffffc09b6a3a>] ? nfs initiate_pgio+0xda/0x160 [nfs]
Jan 18 05:25:45 observer1 kernel: [<ffffffffc0a701c7>] nfs4 file fsync+0x87/0x170 [nfsv4]

在nfs的目录下面执行strace ls卡住或者strace ls ${backup_path}卡住。
执行nfsiostat 2，发现iops不为0，但是流量为0。
在所有observer节点执行以下命令查看是否异常信息。

bash 复制代码

sudo cat /proc/'pidof observer`/task/*/stack | grep -i nfs

⭐️ NFS Hung处理思路

先排查NFS Server端的问题，客户端主要是挂载参数和目录权限相关。

建议按OB官网NFS部署章节进行检查，一般权限和挂载参数不一致问题居多。

bash 复制代码

# Centos7版本, NFS默认使用 nfsnobody 作为默认的匿名用户
# Cent0S 8及之后版本, NFS默认使用 nobody 作为默认的匿名用户

# NFS 3.x, OB4.2.5 BP1开始支持
sudo mount -tnfs -o rw,nfsvers=3,sync,lookupcache=positive,hard,nolock,timeo=600,wsize=1048576,rsize=1048576,namlen=255 10.10.10.1:/data/nfs_server /data/nfs

# NFS 4.x
sudo mount -tnfs -o rw,nfsvers=4.1,sync,lookupcache=positive,hard,timeo=600,wsize=1048576,rsize=1048576,namlen=255 10.10.10.1:/data/nfs_server /data/nfs

其中：

nfsvers=4.1：推荐使用nfs 4.1及以上版本。如果NFS服务站端安装的NFS版本为4.2，这边可以改成nfsvers=4.2。
sync：使用同步写保证数据能及时刷到服务端，从而保证数据的一致性。
lookupcache=positive：用于避免并发访问目录或者文件时误报目录或文件不存在的问题，保证数据的一致性
hard：在NFS不可用时，会卡住应用的读写请求，以保证数救据一致性。不能使用soft选项，会有数据错误的风险。

再排查OBServer和NFS Server之间的网络是否有问题，包括延迟、丢包、防火墙等。

观察ifconfig里面网卡的error或者drop个数。
查看tsar --live中的retran，如果超过0.2一般认为网络有问题。
可以尝试访问备份的目录,或者跑一个fio测试下nfs的清况,观察nfsiostat 2的监控是否正常。

对象存储问题

⭐️ 对象存储常见问题

OB_OSS_ERROR(-9003)

V4.3.5之后该错误码替换为OB_OBJECT_STORAGE_IO_ERROR，一般是网络请求失败，错误原因可以搜索。

bash 复制代码

grep -C 2 "print_oss_info" observer.log
grep -C 2 "ob_storage_oss_base" observer.log

# 如果请求发送成功, aos_ret->code 会打印HTTP错误码, 否则会打印SDK内部的错误码
# aos_ret->error_code 表示错误名
# aos_ret->error_msg 会打印错误原因

[2025-09-19 15:50:17.522432] WDIAG print_oss_info (ob_storage_oss_base.cpp:752) [31551][][T500]|[Y0-0000000000000000-0-0] [lt-67][errcode-0] oss info (aos_ret->code=403, aos_ret->error_code=InvalidAccessKeyId, aos_ret->error_msg=The OSS Access Key Id you provided doesnot exist in our records., aos_ret->req_id=66EBD7B96E537B3733B3035A, delay_time=, oss_account_.oss_domain_=xxxxxx,_oss_endpoint_=oss-cn-hangzhou.aliyuncs.com, oss_account_.oss_id_=)

OB_COS_ERROR(-9060)

V4.3.5之后该错误码被替换为OB_OBJECT_STORAGE_IO_ERROR，错误原因可以搜索。

bash 复制代码

grep -C 2 "ob_cos_wrapper" observer.log

OB_S3_ERROR(-9105)

V4.3.5之后该错误码被替换为OB_OBJECT_STORAGE_IO_ERROR，错误原因可以搜索。

bash 复制代码

grep -C 5 "log_s3_status" observer.log
grep -C 2 "ob_storage_s3_base" observer.log

# err_msg 会提示错误原因, exception是错误名

[2025-09-19 14:44:49.757902] WDIAG log_s3_status (ob_storage_s3_base.cpp:724) [113679][][T500][Y0-0000000000000000000-0-0] [lt=26][errcode=-9105] S3 info(request_id="xxxxx", code=403, exception="SignatureDoesNotMatch", err_msg="The Signature you specified is invalid."

OB_IO_LIMIT(-9061)

表示对象存储被限流了，会限制带宽或QPS，需要检查IO占用情清况。

如果是minio，可能是磁盘写满或者磁盘负载高。
以下是不同对象存储官方文档中对带宽、QPS限流该说明：
- 若目的端是COS，会限制带宽和QPS
- 若目的端是OBS，会限制带宽和QPS
- 若目的端是GCS，会限制带宽和QPS
- 若目的端是OSS，会限制带宽
- 若目的端是S3，会限制QPS

OB_BACKUP_PERMISSION_DENIED(-9071)

表示对象存储使用的账号权限不足。目前OB所需接口集合：

PutObject：上传单个对象
DeleteObject：删除单个对象
DeleteObjects：批量删除对象
GetObject：下载单个对象
ListObjects：列路举径下的所有对象
HeadObject：获取某个对象的元数据
PutObjectTagging（可选项）：设置对象标签
GetObjectTagging（可选项）：获取对象标签
CreateMultipartUpload：初始化分片上传
UploadPart：上传单个分片
CompleteMultipartUpload：合并已上传分片为一个对象
AbortMultipartUpload：中止分片上传,删除已上传分片
ListMultipartUploads：列出上传的分片
ListParts：列出上传任务中已完成上传的分片信息

OB_S3_REGION_MISMATCH(-9117)

目的端为S3时，设定的region字段与host不匹配。或者没有传入s3_region字段，没有传入的情况下，region会使用默认值：US_EAST_1。

OB_INVALID_OBJECT_STORAGE_ENDPOINT(-9118)

目的端非法，常见bucket不存在、bucket命名非法、创建的buIcket名带了点（.）。

OB_OBJECT_NOT_EXIST(-9120)/OB_BACKUP_FILE_NOT_EXIST(-9011)

表示文件不存在。一般原因都是文件未写入就访问，或者被删除后再次访问，可能是使用了未兼容的对象存储。

⭐️ 对象存储问题排查思路

HttploError/curlCode: xxx：若错误信息中看到HttploError，或者出现了curlCode: xxx等错误信息，一般是请求失败，失败的原因很多，包括DNS失败，建立连接失败、连接超时、连接被中断等等。

📖常见的curl相关错误码有：

curlCode: 28：连接超时。可能是网络不稳定，也可能是网络不可达。

首先检测网络是否可达：curl -v bucket-name.host。
网络不可达，很可能是目的端不支持bucket域名 导致的，或者OB版本对path_style支持性问题等。
若host是一个ip地址：curl -v host，长时间夯住就表示网络不可达，一般原因是目的端不支持bucket域名、或者服务器没有开放外网、或者没有开放http/https端口等。
目的端为minio时，出现该错误，一般是因为minio使用的磁盘IOPS或者网络带宽被打满。
目的端非minio时，可能是observer所在服务器负载太高或者带宽被打满。

curlCode: 56：接收网络数据失败，可能网络不稳定造成的，只能重试。也有可能请求被server端中断了，可以检查server端是不是有安全机制。
curlCode: 6：DNS解析失败。可能host字段填写错误，或者目的端不支持bucket域名等。同curlCode: 28。
curlCode: 7：Couldn't connect to server。无法连接到服务器，可能是minio的端口错误，同curlCode: 28。
curlCode: 1：请使用ob_admin的test_io_device检查网络连通性。需要特别注意如若使用https端口，hots字段需添加https://前缀。

数据备份常见问题

备份任务发起失败

⭐️ 备份发起失败常见原因:

未正确配置数据备份的目的端data_backup_dest，比如数据备份目录设置不合法：ERROR 9026 (HY000): backup destination is not valid。归档目录需要加"LOCATION="，数据备份目录是不需要的。
日志归档未开启，这种情况会直接报错：ERROR 9040(HY000): backup can not start, because log archive status is not doing。
租户正处于备份中，同一租户同一时间只支持存在一个备份任务。
租户状态非NORMAL，非NORMAL状态的租户不支持备份。

⭐️ 备份发起失败排查思路

查询DBA_OB_ROOTSERVICE_EVENT_HISTORY视图

sql 复制代码

SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE module like '%backup_data%' AND event like '%start_backup_data%';

其中：

NAME1、VALUE1：显示tenant_id及其对应的值。
NAME2、VALUE2：显示result及其对应的值。
RS_SVR_IP：RootService所在机器的IP。

去RS_SVR_IP过滤rootservice日志。

bash 复制代码

[admin@observer log]$ grep "ret=\-9040" rootservice.log* | grep "ob_backup_data_scheduler"
[2025-09-20 18:04:35.552134] WDIAG [RS] start_tenant_backup_data_ (ob_backup_data_scheduler.cpp:587) [83101][DDLQUieueTh0][T1][Y10B420BA1CC68-000629B5EBAE474A-00] [lt=21][errcode=-9040] log archive is not doing, can't start backup(ret=-9040)

备份长时间不结束

⭐️ 备份长时间不结束排查思路

排查是否有子任务反复失败

sql 复制代码

# 查询任务日志流级备份任务的状态
# 重点关注destination和trace_id列
SELECT * FROM oceanbase.__all_virtual_backup_schedule_task WHERE tenant_id = 1002;

# 到destination节点过滤trace_id
# 关注WDIAG和EDIAG级别信息,如果没有可疑信息,一般是数据量太大,备份慢
grep "YB42C0A80C44-0005F637014C8DE6-0-0" observer.log*

如果没有子任务失败，排查备份速率

涉及并发度参数、磁盘IO、网络IO等。

sql 复制代码

# 查看备份性能
# OUTPUT_RATE_BYTES: 每秒输出字节数
# DATA_PROGRESS: 备份进度, 计算方法: 完成的宏块个数/总宏块个数
SELECT * FROM oceanbase.CDB_OB_BACKUP_TASKS where tenant_id=1002;

# 备份并发度参数,默认是0,表示使用2个线程进行备份
# 可以增大并发度,建议调整8、16进行观察
show parameters like "%ha_low_thread_score";
alter system set ha_low_thread_score= 8;

观察备份介质的磁盘IO性能,比如NFS可以使用nfsiostat命令,观察延迟。

备份任务执行失败

系统租户查看CDB_OB_BACKUP_JOB_HISTORY备份任务的STATUS字段为FAILED，表示备份任务执行失败。

⭐️ 备份任务执行失败排查思路

sql 复制代码

# 查看备份任务状态信息
select * from CDB_OB_BACKUP_JOB_HISTORY\G

# 根据 COMMENT 中server节点和trace_id信息过滤日志
grep "YFA40BA2D90B-005FA487348F363-0-0" observer.log 
grep "YFA40BA2D90B-005FA487348F363-0-0" rootservice.log

# 或者查看历史事件是否有失败原因
select * from __all_server_event_history where module like '%backup%' and event like '%result%' order by gmt_create desc limit 10;

⭐️ 备份任务执行失败常见报错

-4143：备份期间升级。不支持在升级期间做备份，已发起的备份会主动失败。
-9029和**-9027**：归档处于非DOING状态。不支持在非归档期间备份。如果归日档状态异常，已发起的数据备份会主动失败。
-4554：如果出现-4554的错误码，则是Root Service在检测任务状态发现对应的任务超时，就会记录该错误码。

任务超时的可能原因如下:

如果搜索到的报错日志为backup dest server is not exist或server status may not active or in service则是对应的OBServer节点无法访问。
如果无上述日志信息，则可能是Root Service未收到OBServer节点返回的备份结果信息。可以根据日志中ls_task记录的trace_id登录到对应的OBServer节点上搜索日志进行确认。该备份日志排查流程参考前面备份长时间不结束的场景。

-4009 ：备份盘被占满，有可能备份太多也未达到过期清理，可以修改过期时间，让系统自动清理。也可能是磁盘规格小，备份期间数据膨胀，建议备份前做一次合并 ，适当调小ha_low_thread_score参数，降低备份并发，可以降低膨胀。

备份数据清理

自动备份清理默认是每小时触发一次，清理结果记录在CDB/DBA_OB_BACKUP_DELETE_JOB_HISTORY和CDB/DBA_OB_BACKUP_DELETE_TASK_HISTORY视图中，通常清理失败查看该视图能明确看到错误码信息。

常见清理失败问题:

清理的备份目录权限不正确：目录权限或属组或用户UID变更等。
备份介质问题：NFS hang住清理线程卡住。或磁盘性能低，清理慢影响后续清理任务，或者format文件被删除。
对象存储开启了多版本控制：多版本控制可能会出现显示DELETED但备份文件未删除。
磁盘占满 ：磁盘打满，报-4009 IO ERROR。
不满足清理条件 ：数据备份并不是到期就必须清理，清理的前提是当前清理周期外的备份文件能满足完整的数据恢复，例如如果仅有1个全备情况下，过期不管设置多久，都不会清理。

🍎 案例：假设备份保留周期是7天，今天是21号，往前推7天是当月14号，而14号当天没有做全量备份，距离14号最近的一次全量备份发生在11号。为了确保能够恢复到14号的状态，11号当天做的全量备份就不会因为自动清理策略被删除。

数据备份调优

ha_low_thread_score：控制数据备份的并发度。
- 小规格租户（<=4C）建议设置为默认值0，默认并发度为2；
- 大规格租户可以先设置为10，慢的话可以按需翻倍调整。
- 性能测试建议直接调整到最大值1100。
sys_bkgd_net_percentage：控制后台系统任务（其中包括备份恢复任务）可占用总网络带宽的百分比，默认是60% 。如果不影响前台任务情况

下可以适当增大。

Referennces

【1】备份恢复性能调优，https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002517603

【2】备份目录结构，https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000001500556

【3】部署NFS，https://www.oceanbase.com/docs/common-oceanbase-database-standalone-1000000003577389

【4】Transfer问题排查手册，https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000001017357

【5】OceanBase V4.x中的常用备份恢复SQL总结，https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000340642

【6】ob_admin安装，https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000003379568