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

引言

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

这套《备份与恢复实战》系列沿用之前《ksql 指南》的文章逻辑和环境配置：Windows + ksql 为主线，辅以 KingbaseES 自带的备份恢复工具（如 sys_dump / sys_restore，以及部分版本提供的物理备份工具链），把“从备份到恢复再到验收”的闭环做成一套能直接照做的流程。

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

@[toc]

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

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

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

用 ksql 执行：

SELECT version();

确认：

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

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

在 ksql 执行：

SHOW data_directory;

把输出路径记为：

• KB_DATA = <SHOW data_directory 输出>

比如我这里就是

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

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

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

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

cd /d D:ToolsKingbaseESServerbin
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_LABbackuplogical | Out-Null
New-Item -ItemType Directory -Force -Path D:KB_LABbackupphysical | Out-Null
New-Item -ItemType Directory -Force -Path D:KB_LABarchive | Out-Null
New-Item -ItemType Directory -Force -Path D:KB_LABlogs | 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:ToolsKingbaseESServerbin
ksql -U system -d kingbase -h 127.0.0.1 -p 54322

2）创建演示数据库 backup_lab：

CREATE DATABASE backup_lab WITH ENCODING 'UTF8';

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

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)
);

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

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);

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

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

1）对象是否齐全：

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 id, name, balance FROM backup_demo.t_account ORDER BY id;
SELECT SUM(balance) AS total_balance FROM backup_demo.t_account;

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

flowchart LR
  A[准备数据/对象] --> B[执行备份]
  B --> C[制造事故/破坏数据]
  C --> D[执行恢复]
  D --> E[验收校验]
  E --> F{是否通过?}
  F -- 否 --> G[定位原因/重做恢复]
  F -- 是 --> H[形成演练记录/纳入自动化]

总结

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

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

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