kingbase备份与恢复实战（二）—— sys_dump库级逻辑备份与恢复（Windows详细步骤）

引言

库级逻辑备份很适合当作“打底动作”，其包含的命令较少，风险易于控制，其恢复路径也比较直观，对于初次执行备份与恢复而言，采用它最有可能树立起信心。

文章逐步引导你把“备份—还原—验收”变成一个完整的循环，按照其中的步骤执行之后，你就能够掌握到常规的库级备份流程。

1. 在 Windows 系统当中，可以利用 sys_dump 工具来对 backup_lab 整个数据库执行备份操作。

2. 模拟“目标库不存在/原库坏了” 的真实场景：新建一个空库；

3. 用 ksql -f 把备份文件导入到新库；

4. 用一套“验收 SQL”证明恢复成功。

@[toc]

一、前置准备：把环境核对清楚（避免命令跑不通）

1.1 确认你有哪些工具

这篇文章只用到 2 个工具，足够把库级备份恢复讲清楚：

• ksql.exe：负责建库、造数据、恢复后验收
• sys_dump.exe：负责导出备份

它们一般都在安装目录的 Serverbin 下面（我这里给的是示例路径，你以自己的机器为准）：

D:ToolsKingbaseESServerbin

如果你一时找不到路径，可以按下面几种方式定位（任选其一就行）：

• 看之前《kingbase备份与恢复实战（一）—— 备份体系、RPO-RTO与选型（Windows+ksql）》里使用的 Serverbin 路径；
• 或者在资源管理器里搜索 ksql.exe；
• 或者在“金仓数据库管控工具”里找到实例安装路径后，再定位到 Serverbin。

1.2 统一演示参数（可直接复用）

为了让你复制起来不费劲，后面命令统一按这一组参数来写：

• 主机：127.0.0.1
• 端口：54321
• 用户：system
• 演示库：backup_lab
• 备份目录：D:KB_LABbackuplogical

1.3 备份前必须确认的 4 件事（否则很容易“备了个寂寞”）

这一步看起来啰嗦，但真到了生产环境，“备份跑完了却不能用”的坑，十有八九就出在下面几项没核对。 1）确认目标库存在且可连接：

cd /d D:ToolsKingbaseESServerbin
ksql -U system -d backup_lab -h 127.0.0.1 -p 54321

2）确认数据库当前处于可读写状态（至少先证明连接没问题，避免一会儿卡在锁或异常上）：

SELECT CURRENT_TIMESTAMP;

3）确认备份目录可写且空间够用（Windows 层面先打个底）：

New-Item -ItemType Directory -Force -Path D:KB_LABbackuplogical | Out-Null
Get-PSDrive -Name D | Select-Object Name,Free,Used

4）确认 sys_dump 参数以本机 --help 为准（不同版本选项细节可能不一样，先看一眼最稳）：

sys_dump --help

二、准备演示数据（第一次做建议照抄）

2.1 连接 ksql 并创建数据库

1）打开 cmd 或 PowerShell，进入工具目录：

cd /d D:ToolsKingbaseESServerbin

2）连接到一个已存在的库（例如 kingbase）：

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

3）创建演示库：

CREATE DATABASE backup_lab WITH ENCODING 'UTF8';

4）切换到演示库，创建对象并造数据：

c backup_lab

CREATE SCHEMA backup_demo;
SET search_path TO backup_demo, public;

CREATE TABLE t_account (
  id INT PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  balance NUMERIC(12,2) NOT NULL CHECK (balance >= 0),
  update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE t_order (
  order_id INT PRIMARY KEY,
  account_id INT NOT NULL,
  amount NUMERIC(12,2) NOT NULL CHECK (amount > 0),
  create_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  CONSTRAINT fk_order_account FOREIGN KEY (account_id) REFERENCES t_account(id)
);

INSERT INTO t_account(id, name, balance) VALUES
(1, 'A账户', 1000.00),
(2, 'B账户', 2000.00);

INSERT INTO t_order(order_id, account_id, amount) VALUES
(1001, 1, 88.00),
(1002, 2, 128.00);

2.2 备份前验收一次（让你知道“原始状态长什么样”）

dt backup_demo.*
SELECT COUNT(*) AS account_cnt FROM backup_demo.t_account;
SELECT COUNT(*) AS order_cnt FROM backup_demo.t_order;
SELECT SUM(balance) AS total_balance FROM backup_demo.t_account;

三、执行库级逻辑备份（sys_dump）

3.1 创建备份目录

用资源管理器创建也行，建议固定到同一位置：

New-Item -ItemType Directory -Force -Path D:KB_LABbackuplogical | Out-Null
New-Item -ItemType Directory -Force -Path D:KB_LABlogs | Out-Null

3.2 选择输出格式：先用“纯 SQL 脚本（plain）”

库级备份这里先走最直观的 plain 格式（输出成 .sql 或 .dmp 都可以，本质就是一份 SQL 脚本）。

plain 的好处也很直接：

• 一个文件就能还原（直接 ksql -f）
• 适合新手建立流程感

3.3 执行备份命令（Windows）

1）先确保你还在 Serverbin 目录：

cd /d D:ToolsKingbaseESServerbin

2）执行 sys_dump（备份整个 backup_lab）：

sys_dump -h 127.0.0.1 -p 54321 -U system -F p -E UTF8 -f D:KB_LABbackuplogical20260207_1000_backup_lab_full.sql backup_lab

如果你的环境需要密码，执行后会提示你输入，照提示输入就行。

3.3.1 强烈建议：把备份输出写到日志里（便于追溯）

写到这里，其实就可以把“可追溯”这条运维主线提前埋进去：后面第六篇会把任务计划、日志、保留策略串成体系，这里先给一个最小可用写法，让你现在就能留痕、能复盘。

sys_dump -h 127.0.0.1 -p 54321 -U system -F p -E UTF8 -f D:KB_LABbackuplogical20260207_1000_backup_lab_full.sql backup_lab > D:KB_LABlogs20260207_1000_backup_lab_full.dump.log 2>&1

接下来用两件事快速判断“这次备份到底算不算成功”：

• 命令返回码（Windows 的 %ERRORLEVEL%）
• 日志末尾是否有明显报错信息（例如连接失败、权限不足）

3.4 验证备份文件是否生成

用资源管理器查看 D:KB_LABbackuplogical 下是否有文件：

• 文件存在
• 文件大小不是 0

你也可以在 PowerShell 查看大小：

Get-Item D:KB_LABbackuplogical20260207_1000_backup_lab_full.sql | Select-Object Name,Length,LastWriteTime

四、模拟事故：恢复到一个“全新数据库”

真实场景里，事故往往没你想得那么“温柔”。很多时候不是“导回原库”就结束了，常见情况反而是：

• 原库坏了/不可用
• 或者要求恢复到新库进行比对/演练

所以这篇直接按“恢复到新库”的路线来写：隔离、安全、失败也好重来，做演练尤其合适。

4.1 创建一个干净的目标库

回到 ksql（如果你刚才退出了，就重新连一次 kingbase）：

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

创建目标库 backup_lab_restore（建议用 template0，避免继承多余对象）：

DROP DATABASE IF EXISTS backup_lab_restore;
CREATE DATABASE backup_lab_restore WITH TEMPLATE = template0 ENCODING = 'UTF8';

4.2 一个容易被忽略的事实：恢复常见失败不是“命令错”，而是“依赖缺”

逻辑备份做恢复时，最常见的翻车点往往不是命令拼错了，而是环境差一点点就会出事，比如：

• 目标库里没有同名用户/角色，导致 ALTER OWNER 或授权语句失败

• 目标库里已有同名对象，导致 CREATE 失败

目标库的编码或者排序规则存在差别，这会造成乱码或者行为上的差异，由于这种情况非常现实，所以这个系列默认以管理员账号来展示，并且更为建议采用这种方式。

• 恢复到“新库”（隔离验证、失败可重来）

• 目标库用 template0 创建（尽量干净）

五、执行恢复：用 ksql 导入备份脚本

5.1 用 ksql -f 导入（最直观）

你可以退出 ksql，也可以另开一个 cmd 窗口。这里我用 cmd 演示“一条命令把脚本导进去”：

cd /d D:ToolsKingbaseESServerbin
ksql -h 127.0.0.1 -p 54321 -U system -d backup_lab_restore -f D:KB_LABbackuplogical20260207_1000_backup_lab_full.sql

导入过程中如果没有报错，通常会刷出一堆 CREATE TABLE、INSERT 之类的输出，这是正常现象。

5.2 恢复后第一时间看 3 个信号

恢复完成后别急着关窗口，第一时间先盯住这 3 个信号，基本就能判断是否恢复到位：

1）对象是否存在：

c backup_lab_restore
dn
dt backup_demo.*

2）数据量是否对得上：

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

3）关键聚合是否一致：

SELECT SUM(balance) AS total_balance FROM backup_demo.t_account;

把这里的结果和备份前的输出对一对，确认一致就行。

六、恢复后的“二次验收”

只看 COUNT(*) 很容易漏掉“表回来了但不完整/不可用”的问题，所以建议再补两类检查，更贴近生产运维的验收习惯。

6.1 对象级检查（表、索引、约束）

dn
dt+ backup_demo.*
di+ backup_demo.*

6.2 关键约束与外键是否生效（避免“表回来了但约束丢了”）

d backup_demo.t_order

六、常见问题排查（高频）

问题 1：sys_dump 报错“找不到命令/不是内部或外部命令”

原因： 没有进入 Serverbin，或环境变量没有配置。
解决：

• 进入 ksql.exe 所在目录再执行 sys_dump.exe；
• 或把 Serverbin 加入系统 PATH。

问题 2：导入时报错“权限不足 / 无法创建 schema/table”

原因： 恢复用户权限不够（例如不是 system）。
解决： 用有足够权限的用户恢复，或提前授予对应权限。

问题 3：导入到目标库后乱码

原因： 导出/导入编码不一致。
解决：

• 导出时明确 -E UTF8（如果你的数据涉及中文，建议加上）；
• 目标库创建时指定 ENCODING 'UTF8'。

总结

到这里，“库级逻辑备份—恢复—验收”的最小闭环你就跑通了：

• sys_dump 导出整库到 SQL 脚本

• ksql -f 导入到一个全新数据库

• 用3类验收SQL显示恢复是否达成

  下文将更接近实际事故：“误删一张表”之后，怎样达成“仅把该表复原”，还会阐述为何更倾向于采用“归档格式（custom） + sys - restore”这套方案执行“精确复原”。