kingbase备份与恢复实战（一）—— 备份体系、RPO-RTO与选型（Windows+ksql）

引言

做数据库运维，最怕的不是“遇到事故”，而是事故发生时才发现：没有备份、备份不可用、恢复不会做、不知道要恢复到哪里。

这套《备份与恢复实战》系列沿用之前《ksql 指南》的文章逻辑和环境配置：Windows + ksql 为主线，辅以 KingbaseES 自带的备份恢复工具（如sys_dump/sys_restore，以及部分版本提供的物理备份工具链），把“从备份到恢复再到验收”的闭环做成一套能直接照做的流程。
如果你没有前置知识，建议先学习ksql系列前置文章👉：
【金仓数据库】ksql 指南（一） 连接本地 KingbaseES 数据库与基础交互
【金仓数据库】ksql 指南（二） —— 创建与管理本地数据库
【金仓数据库】ksql 指南（三） —— 创建与管理表空间和模式
【金仓数据库】ksql 指南（四） —— 创建与管理表（KingbaseES 数据存储核心）
【金仓数据库】ksql 指南（五） —— 创建与管理索引和视图（KingbaseES 查询优化核心）
【金仓数据库】ksql 指南（六）—— 创建与管理用户和权限（KingbaseES 安全控制核心）
【金仓数据库】ksql 指南（七） —— 启动和管理事务（KingbaseES 数据一致性保障）

本文作为第一篇，先把你必须掌握的“备份体系”和“选型方法”讲清楚：RPO/RTO 是什么、逻辑/物理备份差异在哪、你该用哪一种、这套系列的统一演示环境怎么约定。

零、先做 3 个“必做核对”（保证后续步骤可执行）

这套系列的所有操作都建立在一个前提上：你能准确掌握“版本、路径、权限”

0.1 确认数据库版本（决定命令/参数形态）

用 ksql 执行：

SELECTversion();

确认：

• KingbaseES 版本号（例如 V008R006… / V9…）
• 操作系统版本（Windows 10/11/Server）
• 是否单机/主备/集群（本系列默认单机演示）

0.2 找到数据目录（物理备份与 PITR 都离不开）

在 ksql 执行：

SHOWdata_directory;

把输出路径记为：

• KB_DATA = <SHOW data_directory 输出>

比如我这里就是

KB_DATA = D:/Tools/Kingbase/ES/kes_instance_1

后面（四）（五）两篇会反复用到它。

0.3 确认客户端工具可用（sys_dump/sys_restore/ksql）

进入你安装目录的Server\bin（以你实际路径为准，这里我用我自己的路径做示例），然后查看帮助信息：

cd /d D:\Tools\Kingbase\ES\Server\bin sys_dump --help sys_restore --help ksql --help

下图是我的

这一点很关键：不同版本可能在参数细节上略有差异，以你本机--help输出为最终事实。后面文章所有命令都能按这个原则自证可行。

一、先把目标说清：备份的最终目的是什么？

备份不是“导出一个文件”这么简单，它的最终目标只有一个：

在可接受的时间内，把数据恢复到可接受的状态。

这句话里包含 2 个运维指标（后面所有方案都绕不开）：

1.1 RPO：你最多能丢多少数据？

RPO（Recovery Point Objective，恢复点目标）关注的是“数据回退的程度”。

举例：

• 你的 RPO = 24 小时：你每天凌晨做一次全量备份，那么最坏情况下可能丢掉“今天白天”的数据。
• 你的 RPO = 5 分钟：你需要更高频的日志/增量机制（如归档 WAL）来把丢失窗口压到 5 分钟以内。

1.2 RTO：你最多能停机多久？

RTO（Recovery Time Objective，恢复时间目标）关注的是“恢复需要多久”。

举例：

• 你的 RTO = 2 小时：可以接受较慢的导入恢复方式。
• 你的 RTO = 5 分钟：必须优先考虑“恢复速度”更快的方式（通常偏向物理备份）。

1.3 把 RPO/RTO 写成“人话版”结论

二、两条主线：逻辑备份 vs 物理备份

KingbaseES 的备份恢复从“结果形态”来看，最常见的是两类：

• 逻辑备份：导出为 SQL 脚本或归档文件（工具：sys_dump/sys_restore）
• 物理备份：备份数据目录文件（冷备拷贝或物理备份工具链）

2.1 逻辑备份（推荐新手先掌握）

逻辑备份的核心特点：

• 导出的是“对象定义 + 数据”的逻辑表达（SQL 脚本或归档格式）
• 恢复时本质是“重建对象 + 回放数据”，因此恢复时间往往更长
• 跨实例/跨平台迁移更友好（很多场景甚至可以当迁移手段）

这套系列会用sys_dump讲清楚三种你最常用的逻辑备份：

• 库级备份（全库）
• 表/模式级备份（局部救急）
• 归档格式备份 +sys_restore精准恢复（只恢复某张表）

2.2 物理备份（更偏运维、恢复更快）

物理备份的核心特点：

• 备份的是数据目录里的物理文件，恢复时通常是“替换/还原数据目录再拉起实例”
• 优点：恢复更快、更贴近生产的“灾备恢复”
• 缺点：对版本、目录、配置更敏感；处理不当容易出现“起不来/起起来但不一致”

在 Windows 单机环境里，你至少要掌握一种“可落地”的物理备份：

• 冷备（停库拷贝数据目录）：最通用、最直观，但需要停机窗口
• 部分版本/部署形态也会提供sys_rman/sys_backup.sh这类物理备份工具链（后续文章会给出“如果你的环境具备该工具链，该怎么做”的路径）

三、怎么选：一张表决定你该用哪种备份

结论（这套系列的路线）：

• 先用 2~3 篇把逻辑备份恢复写透（上手快、可复制）
• 再补齐物理备份 + PITR（时间点恢复）+ 自动化 + 演练验收（运维闭环）

四、本系列统一演示环境（Windows + ksql 为主）

为了让每篇文章的命令可以直接复用，这套系列统一做以下约定

4.1 软件与工具

• 操作系统：Windows 10/11 / Windows Server（均可）
• 数据库：KingbaseES（单机实例）
• 命令行工具：
  • ksql.exe（交互与验收）
  • sys_dump.exe/sys_restore.exe（逻辑备份恢复）
  • （可选）sys_ctl.exe或服务管理（启停实例）
  • （可选）sys_rman等物理备份工具链（若安装包提供）

4.1.1 权限与磁盘空间

备份恢复里最常见的“不可执行”，基本都能归结到两类：

• 没权限（Windows 服务账户、目录 ACL、数据库账号权限）
• 没空间（备份文件写不下、归档目录被占满）

最低要求：

• Windows 侧：执行备份/拷贝的账户对D:\KB_LAB\...有读写权限
• 数据库侧：用于备份/恢复的账号能连接数据库，并具备导出/创建对象所需权限（演示环境用的是管理员账号）
• 空间侧：逻辑备份至少预留“数据库大小 × 1.2”的空间；物理备份至少预留“数据目录大小 × 1.2”的空间

4.2 统一连接参数（示例）

为了和之前的《ksql 指南》保持一致，这里也用最常见的本地参数写法（以实际为准）：

• 主机：127.0.0.1（或localhost）
• 端口：54322（默认值是54321，我这里是换了）
• 管理员用户：system
• 示例数据库：后续统一用backup_lab

4.3 统一目录规划（强烈建议照做）

在 Windows 上，建议把“备份文件、归档日志、演练目录”集中放到一个位置，避免散落：

• D:\\KB_LAB\\backup\\logical：逻辑备份文件（SQL/归档）
• D:\\KB_LAB\\backup\\physical：物理备份目录（冷备副本）
• D:\\KB_LAB\\archive：归档日志目录（PITR 用）
• D:\\KB_LAB\\logs：备份脚本日志（自动化用）

你可以先手动创建目录（资源管理器即可），也可以用 PowerShell 一次性创建：

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

4.4 统一命名规范（让你后面自动化更省心）

建议按“时间 + 类型 + 实例/库名 + 格式”命名：

• 逻辑备份（SQL 脚本）：YYYYMMDD_HHMM_backup_lab_full.sql
• 归档格式（custom）：YYYYMMDD_HHMM_backup_lab_full.dump
• 物理冷备目录：YYYYMMDD_HHMM_kes_instance_full

五、实操预热：创建一套“可验证”的演示数据

后面每一篇都要“备份—破坏—恢复—验收”，所以必须有一套稳定的演示对象。

5.1 用 ksql 创建演示库与对象

1）连接数据库（先连一个你能连上的库，比如默认kingbase）：

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

2）创建演示数据库backup_lab：

CREATEDATABASEbackup_labWITHENCODING'UTF8';

3）切换到演示库并创建模式与表：

\c backup_labCREATESCHEMAbackup_demo;SETsearch_pathTObackup_demo,public;CREATETABLEt_account(idINTPRIMARYKEY,nameVARCHAR(50)NOTNULL,balanceNUMERIC(12,2)NOTNULLCHECK(balance>=0),update_timeTIMESTAMPDEFAULTCURRENT_TIMESTAMP);CREATETABLEt_order(order_idINTPRIMARYKEY,account_idINTNOTNULL,amountNUMERIC(12,2)NOTNULLCHECK(amount>0),create_timeTIMESTAMPDEFAULTCURRENT_TIMESTAMP,CONSTRAINTfk_order_accountFOREIGNKEY(account_id)REFERENCESt_account(id));

4）插入少量数据（后续会用它做校验）：

INSERTINTOt_account(id,name,balance)VALUES(1,'A账户',1000.00),(2,'B账户',2000.00);INSERTINTOt_order(order_id,account_id,amount)VALUES(1001,1,88.00),(1002,2,128.00);

5.2 给“验收”准备 3 类校验语句

后面每篇文章只要恢复完，跑下面三类校验即可（非常适合做成“验收清单”）：

1）对象是否齐全：

\dn \dt backup_demo.*

2）数据是否齐全：

SELECTCOUNT(*)ASaccount_cntFROMbackup_demo.t_account;SELECTCOUNT(*)ASorder_cntFROMbackup_demo.t_order;

3）关键数据是否正确（抽样 + 聚合）：

SELECTid,name,balanceFROMbackup_demo.t_accountORDERBYid;SELECTSUM(balance)AStotal_balanceFROMbackup_demo.t_account;

六、可视化：把“备份—恢复闭环”画成一张流程图

总结

本文把备份体系先“立住”：

• 备份的评价标准不是“文件有没有”，而是 RPO/RTO 是否达标、恢复验收是否通过
• 逻辑备份（sys_dump）更适合入门与迁移，物理备份更适合追求恢复速度
• 本系列统一以Windows + ksql为主线，并给出统一目录与命名规范，保证每篇命令可复用

下一篇开始进入真正的“可落地实操”：用sys_dump在 Windows 上完成库级逻辑备份，并恢复到一个全新的数据库里，最后用“验收 SQL”证明恢复成功。