kingbase备份与恢复实战（四）—— Windows物理备份：停库冷备拷贝数据目录与恢复拉起

引言

如果说逻辑备份更多是在解决"能不能恢复"，那物理备份更关心的就是另一个问题：恢复能不能快。

在不少生产事故里，真到了拼速度的时候，你会发现最舒服的方式往往不是"导入一堆 SQL"，而是：

直接把实例的数据目录恢复到某个时点，然后把实例拉起来。

这篇文章还是基于 Windows 单机 + ksql ，从最通用、最容易上手的一招讲起：停库冷备（拷贝数据目录）。它不依赖复杂组件，照着做也能很快跑通闭环。

@[toc]

一、物理备份到底备的是什么？（一张图讲清楚）

1.1 逻辑备份 vs 物理备份（直观对比）

1.2 冷备是什么？为什么推荐从它开始？

冷备（Cold Backup）说白了就是三步：

先停库（确保数据文件处于一致状态）
再拷贝整个数据目录
恢复时把目录拷贝回去，再启动实例

它的优点很实在：

直观、可靠、易理解
不依赖归档/WAL/工具链（对新手友好）

它的缺点也很明确：

必须有停机窗口（RTO 可能达标，但业务可用性需要评估）

二、前置准备：你必须先找到"数据目录"

2.1 用 ksql 查询 data_directory（推荐）

连接到任意库执行：

cmd 复制代码

cd /d D:\Tools\Kingbase\ES\Server\bin
ksql -U system -d kingbase -h 127.0.0.1 -p 54322

sql 复制代码

SHOW data_directory;

输出示例（以实际为准）：

plaintext 复制代码

 data_directory
-----------------------------------------
 D:/Tools/Kingbase/ES/kes_instance

2.2 通过"金仓数据库管控工具"查看（备用路径）

如果你更习惯用 GUI，这条路也完全没问题：

打开"金仓数据库管控工具"
找到实例详情/配置
一般能看到"数据目录/实例目录/日志目录"等路径

2.3 记住 2 个关键目录

后面会反复用到两类目录，先把概念记住，后面就不容易绕晕：

数据目录（KB_DATA）：核心数据文件都在这里
备份目标目录 ：例如 D:\KB_LAB\backup\physical\20260207_1200_kes_instance_full

三、冷备的关键原则

冷备看起来简单，但坑也集中。建议原则：

冷备必须在实例完全停止后进行
- 如果实例仍在运行，数据文件可能处于不一致状态，拷贝出来也可能"备份不可用"
冷备最好不要放在同一块物理磁盘
- 同盘故障时"备份和数据一起没了"，演练环境可以同盘，生产不建议
冷备目录必须可追溯
- 目录名带时间戳、实例名/端口、是否全量等信息，方便回滚与审计

三、实操：停库冷备（Windows）

3.1 建议先做一次"备份前检查"

在停库之前，先用 ksql 把实例的关键状态记一笔（演练和复盘时特别省事）：

sql 复制代码

SELECT version();
SHOW data_directory;
SHOW port;

3.2 停止数据库实例（两种方式）

方式 A：Windows 服务管理（最通用）

1）Win + R 输入 services.msc 打开服务管理器；

2）找到你的实例服务（名称以实际为准，可能类似 KingbaseES_V9_kes_instance）；

3）右键【停止】。

方式 A.1：如何确认"真的停干净了"

很多冷备失败其实不是拷贝工具的问题，而是"服务点了停止，但进程/端口还在"。稳妥起见，建议做两步确认：

1）确认端口不再监听（端口以 SHOW port; 为准）：

powershell 复制代码

netstat -ano | findstr :54322

2）如果仍有监听，就回到服务管理器确认状态，必要时看日志再处理。别在实例还在跑的时候强行拷贝数据目录，这样备出来的东西很可能不可用。

方式 B：命令行停止（如果你的环境提供 sys_ctl）

部分安装环境会提供 sys_ctl 之类的启停工具（名称以实际为准）。常见形态类似：

cmd 复制代码

sys_ctl stop -D <data_directory>

如果你不确定是否有该工具：

cmd 复制代码

cd /d D:\Tools\Kingbase\ES\Server\bin
dir *ctl*

四、拷贝数据目录：robocopy 推荐写法（稳定）

4.1 创建物理备份目录

powershell 复制代码

New-Item -ItemType Directory -Force -Path D:\KB_LAB\backup\physical | Out-Null
New-Item -ItemType Directory -Force -Path D:\KB_LAB\backup\physical\20260207_1200_kes_instance_full | Out-Null

4.2 robocopy 执行拷贝

假设你的数据目录是：

D:\Tools\Kingbase\ES\kes_instance（以你 SHOW data_directory 为准）

然后执行拷贝：

cmd 复制代码

robocopy "D:\Tools\Kingbase\ES\kes_instance" "D:\KB_LAB\backup\physical\20260207_1200_kes_instance_full" /MIR /R:2 /W:2 /XJ

参数建议

/MIR：镜像目录（目标目录会完全一致）
/R:2 /W:2：失败重试 2 次，每次等待 2 秒
/XJ：排除目录联接（避免循环）

4.3 拷贝完成后的校验（建议做）

拷贝完别急着结束，至少做 2 件事确认一下：

1）看 robocopy 输出是否有失败项（FAILED）

2）用 PowerShell 统计文件数（简单但有效）：

powershell 复制代码

(Get-ChildItem -Recurse -File "D:\Tools\Kingbase\ES\kes_instance").Count
(Get-ChildItem -Recurse -File "D:\KB_LAB\backup\physical\20260207_1200_kes_instance_full").Count

可选校验点：

对目标目录做一次快速压测式读取（例如打开几个大文件所在目录）
或者记录 robocopy 的退出码（EXITCODE）并写入日志（便于追溯）

五、恢复演练：用冷备把实例恢复回来

这里演示"覆盖式恢复"（恢复回原实例）。生产场景中更推荐"恢复到新实例/新机器"再切换，但 Windows 单机文章先把闭环讲清楚更重要。

5.1 模拟事故：人为破坏数据（演练用）

为了模拟"库坏了/数据被误操作"，你可以用两类方式来造事故：

逻辑破坏：误删表（前一篇已讲）
物理破坏：删除数据目录下某些文件（不建议新手这么玩，容易起不来）

更推荐用逻辑破坏来演练物理恢复，既安全又直观，比如：

sql 复制代码

DROP TABLE backup_demo.t_order;

确认表已不存在：

sql 复制代码

\dt backup_demo.*

5.2 停库（同 3.2）

再次停止实例服务。

5.3 替换数据目录（核心步骤）

1）先把"当前数据目录"改名留存（这一步非常关键，避免误操作后无路可退）：

例如把：

D:\Tools\Kingbase\ES\kes_instance

改为：

D:\Tools\Kingbase\ES\kes_instance_broken_20260207_1210

cmd 复制代码

robocopy "D:\KB_LAB\backup\physical\20260207_1200_kes_instance_full" "D:\Tools\Kingbase\ES\kes_instance" /MIR /R:2 /W:2 /XJ

5.3.1 一个安全习惯：保留"回退点"

这一段属于"真能救命"的习惯：

永远先把原目录改名留存，再覆盖式拷贝
如果恢复启动失败，你可以立刻把目录切回去（减少误操作造成的二次事故）

5.4 启动实例

回到服务管理器，把实例服务启动起来。

5.5 恢复后验收

用 ksql 连接 backup_lab，检查之前误删的表是否回来了：

cmd 复制代码

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

sql 复制代码

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

如果能看到 t_order，并且行数也对得上，就说明这次物理恢复已经生效。

六、常见问题排查（冷备最常见的坑）

问题 1：恢复后启动失败

排查顺序建议，按顺序查，效率最高：

1）看实例日志目录（管控工具/数据目录下通常有日志）

2）检查端口是否冲突（SHOW port; 或服务日志）

3）确认数据目录权限（服务运行账户对目录是否有读写权限）

4）确认你拷贝的是"完整数据目录"，不是只拷了部分子目录

问题 2：恢复后能启动，但数据不对

最常见的原因是：

你恢复的备份点本来就早于事故发生（这不是失败，是"恢复点选择"问题）

处理办法也很朴素：

用更近的备份点
或者进入下一篇的 PITR：用归档日志把恢复点推进到事故前

问题 3：服务能启动，但无法连接（连接超时/拒绝）

建议按下面顺序排查：

1）端口是否与你连接参数一致（SHOW port;）

2）kingbase.conf 里监听地址配置是否变化

3）Windows 防火墙策略是否拦截（本机演练通常问题不大，远程连接时常见）

七、可选进阶：如果你的环境支持 sys_rman（了解即可）

部分版本/部署会提供 sys_rman/sys_backup.sh 这类物理备份工具链，用于更体系化的物理备份、归档与恢复。

冷备是最通用的入门方案；
如果生产对 RPO/RTO 更苛刻，应评估并使用更标准化的物理备份工具链。

总结

到这里，Windows 单机环境下"物理备份---恢复---验收"的闭环就讲清楚了：

找到数据目录（SHOW data_directory）
停库冷备（robocopy 镜像拷贝）
覆盖式恢复并拉起实例
用 ksql 验证对象与数据

下一篇会把"恢复点"再往前推进：开启归档并做 PITR 时间点恢复，把数据库恢复到"误操作前一分钟"。