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

倔强的石头_
0 阅读9分钟

引言

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

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

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

@[toc]

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

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

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

用 ksql 执行：

SELECT version();

8f5d85316669c4fe6094fdd29d76b1b8.png

确认：

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

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

在 ksql 执行：

SHOW data_directory;

image.png

把输出路径记为：

  • 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

下图是我的 f0b8f55e4556e593541707cf6f9fb166.jpg

这一点很关键：不同版本可能在参数细节上略有差异，以你本机 --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 写成“人话版”结论

业务类型典型例子RPO 参考RTO 参考备份重点
测试/开发测试库、个人环境1 天1 小时备份简单、恢复能用即可
一般业务OA/门户/报表1 小时~1 天30 分钟~2 小时自动化 + 演练
核心业务交易/账务/生产调度0~5 分钟5~30 分钟物理备份 + 归档日志 + 预案

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

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

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

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

逻辑备份的核心特点：

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

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

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

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

物理备份的核心特点：

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

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

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

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

维度逻辑备份（sys_dump）物理备份（冷备/物理工具）
典型目标可迁移、可选择性恢复快速恢复、灾难恢复
恢复速度中~慢快
恢复灵活性高（可选库/表/模式）中（更多是整库/整实例）
跨版本/跨平台更友好更敏感
新手上手难度低中~高
推荐场景开发/测试、日常备份、局部救急生产主库、对 RTO 要求高

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

  • 先用 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-Null
New-Item -ItemType Directory -Force -Path D:\KB_LAB\backup\physical | Out-Null
New-Item -ItemType Directory -Force -Path D:\KB_LAB\archive | Out-Null
New-Item -ItemType Directory -Force -Path D:\KB_LAB\logs | Out-Null

image.png

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：

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

image.png

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;

955cf71aaf9f6a03a7346b8e6dba6383.png

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

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”证明恢复成功。

avatar
文章
阅读
粉丝