--- title: "数据备份失败 - OceanBase 数据库 V4.3.1 | OceanBase 文档中心" description: 数据备份失败 本节主要介绍在物理备份过程中出现数据备份失败问题时的排查及定位方法。 本文档中以 OceanBase 数据库的安装目录为 /home/admin/oceanbase 为例提供排查指导，文档中涉及的日志的实际存放路径请以实际环境为主。 问题一：数据备份任务发起失败 数据备份任务发起失败后，可以通过以下步骤… --- 切换语言 - 中文站 - 简体中文 - International - English - 日本站 - 日本語 文档反馈![](https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*P8CuR4UJ_FkAAAAAAAAAAAAADiGDAQ/original) OceanBase 数据库分布式版 - V 4.3.1 # 数据备份失败 更新时间：2026-04-10 11:58:00 [编辑](https://github.com/oceanbase/oceanbase-doc/edit/V4.3.1/zh-CN/600.manage/1000.troubleshooting/900.backup-and-recovery/100.data-backup-failed.md) 本节主要介绍在物理备份过程中出现数据备份失败问题时的排查及定位方法。 本文档中以 OceanBase 数据库的安装目录为 `/home/admin/oceanbase` 为例提供排查指导，文档中涉及的日志的实际存放路径请以实际环境为主。 ## 问题一：数据备份任务发起失败 数据备份任务发起失败后，可以通过以下步骤进行排查。 1. 使用 `root` 用户登录集群的 `sys` 租户。 2. 执行以下语句，确认任务失败的原因。 ```sql SELECT * FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY WHERE module='backup_data' AND event ='start_backup_data'; ``` 查询示例如下： ```shell +----------------------------+-------------+-------------------+-----------+--------+--------+--------+-------+--------+-------+--------+-------+--------+-------+--------+------------+----------------+-------------+ | 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，则需要进行下一步排查，确认报错点。 3. 根据上一步获取到的 `RS_SVR_IP`，登录 Root Service 所在的机器，搜索 `rootservice.log` 日志，确认报错点。 1. 登录 Root Service 所在的机器。 2. 进入日志所在的目录。 ```shell cd /home/admin/oceanbase/log ``` 3. 执行以下命令，搜索 `ret=\result` 的日志，找到报错点。 ```shell grep "ret=\result" rootservice.log* | grep "ob_backup_data_scheduler" ``` 其中，`result` 需要替换为上一步中 `result` 对应的 `VALUE2` 中的值，下面以 `result` 对应的值为 `-9040` 为例： ```shell grep "ret=\-9040" rootservice.log* | grep "ob_backup_data_scheduler" ``` 根据搜索到的日志信息，如果是以下情况导致的备份任务发起失败，则符合预期： - 未配置数据备份目的端 `data_backup_dest` 有关配置备份目的端的详细操作，请参见 [备份前准备](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000818811)。 - 日志归档未开启 有关开启日志归档的详细操作，请参见 [开启归档模式](https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000818802)。 - 租户正处于备份中 - 租户状态不处于 Normal 对于其他情况导致的数据备份任务发起失败，获取搜索到的日志报错信息后，联系技术支持人员协助处理。 ## 问题二：数据备份卡在某个状态不结束 数据备份卡在某个状态不结束时，可以通过以下步骤进行排查： 1. 使用 `root` 用户登录集群的 `sys` 租户。 2. 执行以下语句，确认任务卡住的状态。 ```sql SELECT * FROM oceanbase.CDB_OB_BACKUP_TASKS WHERE tenant_id = xxx; ``` 根据查询结果，重点关注 `STATUS` 列的值，该列表示的是备份状态。通常数据备份卡住一直不结束时，就会显示 `BACKUP_META`、`BACKUP_DATA` 等状态。 如果 `STATUS` 列的值为 `BACKUP_META` 或 `BACKUP_DATA`，则需要执行下一步进一步进行排查。 3. 执行以下语句，获取任务执行信息。 ```sql SELECT * FROM oceanbase.__all_virtual_backup_schedule_task WHERE tenant_id = xxx; ``` 查询结果示例如下： ```shell +-----------+--------+---------+-------+------+-----------------------------------+-------------------+-------------+------------------+------------------+------------------+ | 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 及端口号。 4. 根据上一步中获取到的信息，登录到 `destination` 列所显示的机器上，执行以下命令，搜索日志。 ```shell 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.*`。 5. 获取搜索到的日志报错信息后，联系技术支持人员协助处理。 ## 问题三：备份任务执行失败 发起数据备份后，查看视图 `CDB_OB_BACKUP_JOB_HISTORY` 或 `DBA_OB_BACKUP_JOB_HISTORY`，查询结果如下图所示，发现对应备份任务的 `STATUS` 列为 `FAILED`，表示备份任务执行失败。 ```shell *************************** 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` 列中的信息搜索日志进行进一步定位，具体步骤如下： 1. 登录到 `addr: 11.xx.xx.xx:4004` 对应的机器。 2. 进入日志所在目录。 ``` 3. 执行以下命令，搜索日志。 - 如果该机器是 OBServer 节点，则执行以下命令搜索任务时间点附近的日志。 ```shell grep 'YFA40BA2D90B-005FA487348F363-0-0' observer.log ``` #### 注意 如果在 `observer.log` 中 `grep` 不到相关日志，可能是因为 `observer.log` 切了文件，可以 `grep 'YFA40BA2D90B-005FA487348F363-0-0' observer.log.*`。 - 如果该机器是 ROOT Service，则执行以下命令搜索任务时间点附近的日志。 ```shell grep 'YFA40BA2D90B-005FA487348F363-0-0' rootservice.log ``` #### 注意 如果在 `rootservice.log` 中 `grep` 不到相关日志，可能是因为 `rootservice.log` 切了文件，可以 `grep 'YFA40BA2D90B-005FA487348F363-0-0' rootservice.log.*`。 4. 获取搜索到的日志报错信息后，联系技术支持人员协助处理。 ## 常见错误码及排查方法 ### `-4012` 和 `-9086` 如果出现 `-4012` 和 `-9086` 的错误码，可以根据本文中介绍的排查方法查看报错日志。例如，搜索到的日志如下： ```java [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 在检测任务状态发现对应的任务超时时，就会记录该错误码。 任务超时的可能原因如下： 1. 如果搜索到的报错日志为 `backup dest server is not exist` 或 `server status may not active or in service` 则是对应的 OBServer 节点无法访问。 2. 如果无上述日志信息，则可能是 Root Service 未收到 OBServer 节点返回的备份结果信息。您可以根据日志中 `ls_task` 记录的 `trace_id` 登录到对应的 OBServer 节点上搜索日志进行确认。 上一篇 下一篇 ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线