数据备份失败

数据备份失败

更新时间：2026-04-10 11:58:00

编辑

本节主要介绍在物理备份过程中出现数据备份失败问题时的排查及定位方法。

本文档中以 OceanBase 数据库的安装目录为 /home/admin/oceanbase 为例提供排查指导，文档中涉及的日志的实际存放路径请以实际环境为主。

问题一：数据备份任务发起失败

数据备份任务发起失败后，可以通过以下步骤进行排查。

使用 root 用户登录集群的 sys 租户。

执行以下语句，确认任务失败的原因。

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

查询示例如下：

+----------------------------+-------------+-------------------+-----------+--------+--------+--------+-------+--------+-------+--------+-------+--------+-------+--------+------------+----------------+-------------+
| TIMESTAMP                  | MODULE      | EVENT             | NAME1     | VALUE1 | NAME2  | VALUE2 | NAME3 | VALUE3 | NAME4 | VALUE4 | NAME5 | VALUE5 | NAME6 | VALUE6 | EXTRA_INFO | RS_SVR_IP      | RS_SVR_PORT |
+----------------------------+-------------+-------------------+-----------+--------+--------+--------+-------+--------+-------+--------+-------+--------+-------+--------+------------+----------------+-------------+
| 2023-08-17 15:56:02.023265 | backup_data | start_backup_data | tenant_id | 1002   | result | -9040  |       |        |       |        |       |        |       |        |            | 11.xx.xx.xx    |        4000 |
| 2023-08-17 15:56:13.116237 | backup_data | start_backup_data | tenant_id | 1002   | result | -9040  |       |        |       |        |       |        |       |        |            | 11.xx.xx.xx    |        4000 |
| 2023-08-17 15:56:38.050299 | backup_data | start_backup_data | tenant_id | 1002   | result | -9040  |       |        |       |        |       |        |       |        |            | 11.xx.xx.xx    |        4000 |
| 2023-08-17 15:57:11.236784 | backup_data | start_backup_data | tenant_id | 1002   | result | -9040  |       |        |       |        |       |        |       |        |            | 11.xx.xx.xx    |        4000 |
4 rows in set

查询结果中，重点关注以下几列的值：

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

根据实际查询结果，如果 NAME2 列中 result 对应的 VALUE2 的值不为 0，则需要进行下一步排查，确认报错点。

根据上一步获取到的 RS_SVR_IP，登录 Root Service 所在的机器，搜索 rootservice.log 日志，确认报错点。
1. 登录 Root Service 所在的机器。
2. 进入日志所在的目录。
```
cd /home/admin/oceanbase/log
```
3. 执行以下命令，搜索 ret=\result 的日志，找到报错点。
```
grep "ret=\result" rootservice.log* | grep "ob_backup_data_scheduler"  
```
  其中，result 需要替换为上一步中 result 对应的 VALUE2 中的值，下面以 result 对应的值为 -9040 为例：
```
grep "ret=\-9040" rootservice.log* | grep "ob_backup_data_scheduler"  
```
  根据搜索到的日志信息，如果是以下情况导致的备份任务发起失败，则符合预期：
  - 未配置数据备份目的端 data_backup_dest
    
    有关配置备份目的端的详细操作，请参见备份前准备。
  - 日志归档未开启
    
    有关开启日志归档的详细操作，请参见开启归档模式。
  - 租户正处于备份中
  - 租户状态不处于 Normal
  对于其他情况导致的数据备份任务发起失败，获取搜索到的日志报错信息后，联系技术支持人员协助处理。

问题二：数据备份卡在某个状态不结束

数据备份卡在某个状态不结束时，可以通过以下步骤进行排查：

使用 root 用户登录集群的 sys 租户。
执行以下语句，确认任务卡住的状态。
```
SELECT * FROM oceanbase.CDB_OB_BACKUP_TASKS WHERE tenant_id = xxx;
```
根据查询结果，重点关注 STATUS 列的值，该列表示的是备份状态。通常数据备份卡住一直不结束时，就会显示 BACKUP_META、BACKUP_DATA 等状态。

如果 STATUS 列的值为 BACKUP_META 或 BACKUP_DATA，则需要执行下一步进一步进行排查。

执行以下语句，获取任务执行信息。

SELECT * FROM oceanbase.__all_virtual_backup_schedule_task WHERE tenant_id = xxx;

查询结果示例如下：

+-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+
| tenant_id | job_id | task_id | ls_id | type | trace_id                          | destination       | is_schedule | generate_ts      | schedule_ts      | executor_ts      |
+-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+
|      1002 |    339 |       3 |  1001 |    0 | YB42C0A80C44-0005F637014C8DE6-0-0 | 192.xx.xx.xx:2882 |      True   | 1679378679020065 | 1679378679205546 | 1679378679302303 |
+-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+
1 row in set

根据查询结果，重点关注 destination 和 trace_id 列的值：

trace_id：数据备份任务对应的 trace_id。
destination：执行数据备份任务的机器的 IP 及端口号。

根据上一步中获取到的信息，登录到 destination 列所显示的机器上，执行以下命令，搜索日志。
```
grep 'YB42C0A80C44-0005F637014C8DE6-0-0' observer.log
```
其中，YB42C0A80C44-0005F637014C8DE6-0-0 为上一步查询出来的 trace_id 的值。

注意

如果在 observer.log 中 grep 不到相关日志，可能是因为 observer.log 切了文件，可以执行 grep 'YB42C0A80C44-0005F637014C8DE6-0-0' observer.log.*。
获取搜索到的日志报错信息后，联系技术支持人员协助处理。

问题三：备份任务执行失败

发起数据备份后，查看视图 CDB_OB_BACKUP_JOB_HISTORY 或 DBA_OB_BACKUP_JOB_HISTORY，查询结果如下图所示，发现对应备份任务的 STATUS 列为 FAILED，表示备份任务执行失败。

*************************** 1. row ***************************
              TENANT_ID: 1004
                 JOB_ID: 8
            INCARNATION: 1
          BACKUP_SET_ID: 8
    INITIATOR_TENANT_ID: 1
       INITIATOR_JOB_ID: 10
     EXECUTOR_TENANT_ID: 1004
        PLUS_ARCHIVELOG: OFF
            BACKUP_TYPE: INC
              JOB_LEVEL: USER_TENANT
        ENCRYPTION_MODE: NONE
                 PASSWD:
        START_TIMESTAMP: 2023-04-27 12:41:27.451141
          END_TIMESTAMP: 2022-04-27 12:42:24.352493
                 STATUS: FAILED
                 RESULT: 4016
                COMMENT:(server)ls_id: 1002，addr: 11.xx.xx.xx:4004,module:BACKUP_DATA,result: -4016(Internal error),trace_id: YFA40BA2D90B-005FA487348F363-0-0
            DESCRIPTION:
                   PATH:file:///data/nfs/backup/backup_1682565410121
1 row in set

视图的 COMMENT 列中展示了备份任务相关的一些信息：

(server)：执行当前备份任务的机器的类型。server 表示执行当前备份任务的是某个 OBServer 节点；rootservice 表示执行当前备份任务的是 Root Service 所在的机器。
addr: 11.xx.xx.xx:4004：执行当前备份任务的机器的 IP 地址及端口号。
result: -4016(Internal error)：当前备份任务失败的错误码信息。
trace_id: YFA40BA2D90B-005FA487348F363-0-0：当前备份任务对应的 trace_id。

您可以通过 COMMENT 列中的信息搜索日志进行进一步定位，具体步骤如下：

登录到 addr: 11.xx.xx.xx:4004 对应的机器。
进入日志所在目录。
```
cd /home/admin/oceanbase/log
```
执行以下命令，搜索日志。
- 如果该机器是 OBServer 节点，则执行以下命令搜索任务时间点附近的日志。
```
grep 'YFA40BA2D90B-005FA487348F363-0-0' observer.log
```
  注意
  
  如果在 observer.log 中 grep 不到相关日志，可能是因为 observer.log 切了文件，可以 grep 'YFA40BA2D90B-005FA487348F363-0-0' observer.log.*。
- 如果该机器是 ROOT Service，则执行以下命令搜索任务时间点附近的日志。
```
grep 'YFA40BA2D90B-005FA487348F363-0-0' rootservice.log
```
  注意
  
  如果在 rootservice.log 中 grep 不到相关日志，可能是因为 rootservice.log 切了文件，可以 grep 'YFA40BA2D90B-005FA487348F363-0-0' rootservice.log.*。
获取搜索到的日志报错信息后，联系技术支持人员协助处理。

常见错误码及排查方法

`-4012` 和 `-9086`

如果出现 -4012 和 -9086 的错误码，可以根据本文中介绍的排查方法查看报错日志。例如，搜索到的日志如下：

[2023-05-19 13:23:25.238790] WDIAG [STORAGE] advance_checkpoint_by_flush (ob_backup_task.cpp:141) [8999][T1004_BACKUP][T1004][Y509E645869DC-0005FC029426456E-0-0] [lt=26][errcode=0] clog checkpoint scn has not passed start scn, retry again(i=0, tenant_id=1004, ls_id={id:1}, clog_checkpoint_scn={val:1684465461355302830}, start_scn={val:1684465461355303000}, need_advance_checkpoint=true, advance_checkpoint_interval=2000000, cur_ts=1684473805238742, last_advance_checkpoint_ts=1684472010015535)

根据日志信息可知，此类报错通常与 Checkpoint 推进慢有关，需要确认冻结转储是否有问题。此外，如果您是在物理备库上执行的数据备份，则还需要考虑备库的日志同步是否已停止。

`-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 节点上搜索日志进行确认。