活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式

本文针对南大通用GBase 8c数据库，在使用`gs_probackup`执行在线物理备份时，因强制终止进程导致backup_label文件残留、备份报错无法继续的典型问题，提供完整的原理说明、异常定位与标准化修复步骤。

## 一、问题现象

通过`kill -9`方式停止`gs_probackup`备份后，再次执行`gs_probackup`时出现报错：

```
if you are sure there is no backup in progress, remove file "backup_label" and try again
```

数据库无法正常发起新备份，提示需处理backup_label文件。

## 二、核心原理

### 1. backup_label文件

backup_label是在进行在线物理备份（Hot Backup）时产生的一个极其关键的临时元数据文件，文内记录了以下内容。
![image.png](https://g1.cdn.gbase.cn/CommunityUploads/yqSM6lItCvrJU0RBUgRHO/image.png)
`START WAL LOCATION`: 备份开始时，预写日志（WAL）的起始位置（LSN）。

`CHECKPOINT LOCATION`: 备份开始时触发的检查点位置。

`BACKUP METHOD`: 备份方式（是流复制备份还是传统的`pg_start_backup`）。

`BACKUP FROM`: 备份来源（主库还是从库）。

`START TIME`: 备份开始的时间戳。

`LABEL`: 你在备份时指定的标签名称。

### 2. backup_label的作用

它是为了解决“数据一致性”问题的。

在数据库运行过程中进行物理拷贝（例如通过`cp`或`rsync`拷贝数据文件）， 会出现部分数据块正在被修改的情况，导致备份文件本身不一致。当你以后用这个备份来恢复数据库时，数据库启动后会读取backup_label文件，根据其中记录的`START WAL LOCATION`定位到WAL日志的起始点，从该位置开始重做（Redo）所有事务，最终将数据恢复到一致可用状态。

可以说，没有backup_label，物理备份就无法启动恢复流程，因为数据库不知道该从哪里开始修复数据。 正常情况：备份结束后调用`pg_stop_backup()`，backup_label文件被自动删掉。

异常情况：备份中途断电、崩溃或被强杀，backup_label文件会残留在数据目录里。

下次重启时，数据库误以为自己正处于“从备份恢复”的过程中，它会试图寻找相应的WAL日志。如果找不到（因为这其实是原始数据目录），它就会报错并拒绝启动，以保护数据不被搞乱。

### 3. backup_label的生命周期

执行`pg_start_backup()`: 数据库在数据目录下创建backup_label。

拷贝数据文件: 你手动或通过脚本拷贝整个data目录。

执行`pg_stop_backup()`: 数据库删除数据目录下的backup_label。

最终状态:

原始数据库：没有backup_label，正常运行。

备份副本：里面带有一个backup_label，静静等待被恢复的那一天。

## 三、处理方法

1.推荐，执行`select pg_stop_backup()`，自动删除backup_label文件。

2.备份backup_label文件（防止误删），再删除掉，重启数据库。



GBase 8c

南大通用GBase 8c数据库在线物理备份异常：backup_label 文件残留问题排查与修复

南大通用GBase 8c数据库在线物理备份异常：backup_label 文件残留问题排查与修复

评论

热门帖子