kingbase备份与恢复实战（三）—— 表-模式级备份与误删表精准恢复（sys_dump+sys_restore）

引言

真实运维里最常见的事故之一，不是“整库没了”，而是：

某个业务同学误执行了 DROP TABLE；
或者批量脚本把一张表 TRUNCATE 清空；
或者在错误库里执行了删除，导致局部数据损坏。

这类事故最理想的处理方式是：不用整库回滚，而是“只把出问题的对象救回来”，这就是“表/模式级备份 + 精准恢复”的价值。

本文会在 Windows 环境下，按以下路径讲清楚闭环：

用 sys_dump 生成一个**归档格式（custom）**的备份；
用 sys_restore 查看备份内容，并只恢复指定的表/模式；
模拟误删 t_order，只把 t_order 恢复回来（不影响其他表的新增数据）。

@[toc]

一、为什么这篇要用 custom 归档格式？

如果你在第二篇用的是 plain SQL 脚本（.sql）：

它能恢复全库，但“只恢复某张表”会很麻烦（要在脚本里手动截取对象片段，风险高）。

而 custom 格式（-F c）的优势是：

可以用 sys_restore 选择性恢复：只恢复某张表、只恢复某个 schema、只恢复数据/只恢复结构；
备份文件通常更紧凑（默认压缩）；
更适合“生产环境日常备份 + 应急恢复”。

二、把“精准恢复”讲清楚：3 种粒度、2 条原则

事故形态	推荐粒度	推荐工具链	说明
误删单表 / 单对象	表级恢复	custom + sys_restore -t	影响面最小
模块级损坏（同一 schema 多表）	schema 级恢复	custom + sys_restore -n	恢复效率更高
全库损坏 / 需重建环境	全库恢复	custom + sys_restore -d	适合演练/迁移

两条原则也建议写死：

备份阶段尽量用 custom（给恢复留选择空间）
恢复阶段先恢复到隔离库验证，再考虑影响生产

二、前置准备：确保 sys_restore 可用

2.1 确认工具存在

进入 Server\bin 目录，确认有：

sys_dump.exe
sys_restore.exe
ksql.exe

示例：

cd /d D:\Tools\Kingbase\ES\Server\bin
dir sys_dump* sys_restore* ksql*

如果找不到 sys_restore，通常有两种情况：

你的版本工具名称略有差异（可在 Server\bin 里搜索 *restore*）
或安装包没有安装完整客户端工具（建议补装/重装客户端组件）

2.2 准备演示库（沿用前两篇）

本文默认你已经有库 backup_lab，并且有模式 backup_demo 下的两张表：

backup_demo.t_account
backup_demo.t_order

如果不确定是否存在，先连 ksql 检查：

ksql -U system -d backup_lab -h 127.0.0.1 -p 54321

\dt backup_demo.*
SELECT COUNT(*) FROM backup_demo.t_order;

三、执行备份：生成 custom 归档文件

3.1 备份命令（全库，custom 格式）

1）准备目录：

New-Item -ItemType Directory -Force -Path D:\KB_LAB\backup\logical | Out-Null

2）执行备份：

cd /d D:\Tools\Kingbase\ES\Server\bin
sys_dump -h 127.0.0.1 -p 54321 -U system -F c -f D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump backup_lab

custom 格式是给 sys_restore 用的，这是 sys_dump 的标准能力

3.2 备份后先做一件事：列出归档内容

这一步相当于“验收备份集是否包含你要的对象”，非常关键。

cd /d D:\Tools\Kingbase\ES\Server\bin
sys_restore -l D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump > D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.list.txt

打开 *.list.txt，你会看到归档里包含哪些 schema/table/index 等对象。

建议明确这个“可执行检查点”：

在 *.list.txt 里全文搜索 backup_demo，确认目标 schema 与表都在归档里
如果你要恢复 backup_demo.t_order，在 list 里至少能看到 TABLE DATA backup_demo t_order 等条目

四、模拟事故：误删一张表（t_order）

4.1 先插入一条“事故前后对比”的新数据

为了证明我们是“精准恢复”，先给 t_account 加一条新数据（模拟备份之后产生的新业务数据）：

INSERT INTO backup_demo.t_account(id, name, balance) VALUES (3, 'C账户', 3000.00);
SELECT COUNT(*) AS account_cnt FROM backup_demo.t_account;

这条数据是“备份后新增”的，理论上我们不应该因为“恢复一张表”而让它消失。

4.2 误删表（模拟事故）

DROP TABLE backup_demo.t_order;

验证表确实没了：

\dt backup_demo.*

五、精准恢复：只恢复 t_order（不动其他表）

5.1 恢复策略说明（先看再做）

要做到“只恢复一张表”，推荐你遵循两个原则：

备份用归档格式（custom），恢复用 sys_restore；
恢复时只选择目标对象（-t 指定表），不要全量覆盖。

5.2 仅恢复 t_order 的“结构 + 数据”

1）先确保你在 Server\bin：

cd /d D:\Tools\Kingbase\ES\Server\bin

2）执行恢复（只恢复一张表）：

sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab -t backup_demo.t_order D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump

执行过程中如果提示输入密码，输入即可。

5.2.1 如果你只想恢复“结构”或只想恢复“数据”

生产事故里经常出现两种特殊需求：

表结构误改了，但数据还在（想只恢复结构）
表被清空了，但结构还在（想只恢复数据）

在动手之前，先明确一个前提：你用 -d 指定恢复到哪个数据库，后面的“验收”就必须连接到同一个数据库执行。

如果你在 backup_lab 里误删，就恢复到 -d backup_lab，验收也连 backup_lab
如果你在 backup_lab_restore 里误删，就恢复到 -d backup_lab_restore，验收也连 backup_lab_restore

这类选项在不同版本里命名可能略有差异，务必以本机 sys_restore --help 为准。最稳妥的写法是先看帮助：

sys_restore --help

然后在可用选项中选择（常见为 --schema-only / --data-only）：

schema-only（只恢复结构，不回放数据）
data-only（只恢复数据，不创建表结构）

这里最容易踩坑的一点是：data-only 不会创建表。因此：

如果你的目标库里这张表已经不存在（例如你执行过 DROP TABLE），只做 data-only 的结果通常就是：恢复阶段报错或被跳过，验收时仍提示“关系不存在”
正确姿势是：先 schema-only 把表建回来，再 data-only 把数据灌回去

下面给一套可执行的“二段式恢复”示例（把 <目标库> 替换成你实际误删发生的库名）：

1）只恢复结构（先把表建回来）：

sys_restore -h 127.0.0.1 -p 54321 -U system -d <目标库> --schema-only -t backup_demo.t_order D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump

2）验收结构是否已恢复：

\dt backup_demo.*

这一步的预期是：backup_demo.t_order 已重新出现，但行数通常为 0（因为你只恢复了结构）。

3）只恢复数据（把数据灌回去）：

sys_restore -h 127.0.0.1 -p 54321 -U system -d <目标库> --data-only -t backup_demo.t_order D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump

4）再做数据验收：

SELECT COUNT(*) AS order_cnt FROM backup_demo.t_order;

如果你恢复的是“备份时刻的那张表”，order_cnt 应该等于备份时的行数（本系列示例数据通常为 2 行）。

5.3 恢复后验收（必须做）

回到 ksql：

\dt backup_demo.*
SELECT COUNT(*) AS order_cnt FROM backup_demo.t_order;
SELECT COUNT(*) AS account_cnt FROM backup_demo.t_account;
SELECT id, name, balance FROM backup_demo.t_account ORDER BY id;

你应该看到：

t_account 仍然包含 id=3 的那条“备份后新增”数据（没有被覆盖掉）。

t_order 的预期结果取决于你采用的恢复方式：

你做的恢复方式	预期结果
默认恢复（结构 + 数据）	`t_order` 存在，`order_cnt` 为备份时行数
只恢复结构（schema-only）	`t_order` 存在，但 `order_cnt` 可能为 0 或查询为空表
只恢复数据（data-only）	前提是 `t_order` 已存在；否则验收大概率仍提示“关系不存在”

六、进阶：恢复整个 schema（适合模块级救急）

如果事故不是一张表，而是一个模块（一个 schema 下多张表）都被破坏了，你可以按 schema 维度恢复。

常见做法（建议你按“可执行步骤”写）：

1）先确认归档里包含该 schema：

sys_restore -l D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump > D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.list.txt

2）按 schema 恢复（参数以 --help 为准，很多版本使用 -n）：

sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab -n backup_demo D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump

3）恢复后验收：

\dt backup_demo.*

如果 schema 下对象很多，建议优先恢复到新库做隔离验证，避免误覆盖生产对象。

七、常见问题排查

问题 1：恢复时报错“relation does not exist / schema does not exist”

原因： 目标 schema 不存在或搜索路径不对。
解决：

确认 schema 存在：\dn
恢复时用全限定名：backup_demo.t_order

问题 2：恢复时报错“权限不足”

原因： 恢复用户不是对象所有者且权限不够。
解决： 用管理员用户执行恢复（例如 system），或提前处理对象所有者与授权。

问题 3：恢复后外键报错/依赖对象缺失

原因： 你恢复的是表，但该表依赖的对象（例如引用的父表、类型、函数）未恢复。
解决：

优先恢复依赖链“上游”对象；
或按 schema/全库恢复，避免遗漏依赖。

问题 4：恢复时卡住很久、看不到进度

把恢复输出重定向到日志文件（方便复盘）
同时在 ksql 里观察是否正在执行 DDL/DML（权限允许时）

例如：

sys_restore -h 127.0.0.1 -p 54321 -U system -d backup_lab -t backup_demo.t_order D:\KB_LAB\backup\logical\20260207_1100_backup_lab_full.dump > D:\KB_LAB\logs\restore_t_order.log 2>&1

总结

这篇文章的核心价值在于把“精准恢复”做成了可执行的流程：

备份：sys_dump -F c（custom 归档）
验收：sys_restore -l（先确认归档内容）
救急：sys_restore -t schema.table（只恢复目标表，不动其他表）

下一篇会进入更偏运维的部分：物理备份。在 Windows 单机环境里，我们会从“停库冷备拷贝数据目录”开始，讲清楚怎么做、怎么恢复、怎么验证，以及它和逻辑备份的关系。