金仓数据库指定表备份：sys_dump命令、自动脚本与恢复验证

前阵子有个做运维的朋友问我金仓数据库能不能像 MySQL 那样只备份某几张指定的表他说他负责的那套 KingbaseES 库全量备份文件已经涨到 70 多 G每天凌晨跑一次要四十多分钟可真正做恢复演练的时候最常用的也就是那四五张配置表。我听完就笑了——金仓当然支持指定表备份而且这事儿我在生产环境用脚本跑了挺久今天干脆把完整方案从命令到脚本再从调度到恢复验证一次讲透。如果你也在用金仓面对的情况是“库很大、只想备份核心表”或者“想给某几张关键表加一个高频率备份任务”这篇就是给你写的。1. 为什么我要放弃“天天全库备份”改成只备份关键表1.1 全库备份的负担到底在哪里很多刚接触国产数据库的朋友最容易沿用的习惯就是“每天夜里全库备份一把”。这个思路本身没错但库一旦上了规模问题就非常现实磁盘占用一个 70 G 的备份文件如果保留 7 天就是近 500 G 空间还不算归档日志。备份时长40 分钟的全量导出对生产库意味着长时间的磁盘 IO 压力业务高峰期根本不敢跑。恢复时间全库恢复通常比备份更慢如果只是某人误删了一张订单表你却要花一两个小时把整个库倒回去业务等不起。最小恢复粒度数据库备份的价值不是“能备份”而是“能快速恢复到需要的位置”。指定表备份解决的就是这个粒度问题。所以我的原则很简单全量备份继续保留但改成低频比如每周一次高频备份交给指定表脚本专盯业务上“丢不起”的那几张表。1.2 什么场景最适合用指定表备份根据我实际接触过的项目以下四类场景用指定表备份最合适配置类、字典类表频繁变更比如权限表、菜单表、系统参数表白天改一下、晚上就要能回到改之前的状态。这类表数据量不大却直接影响整个系统行为。核心业务表单独加强保护订单表、用户表、账户流水表哪怕库很大这几张表也值得单独高频备份。数据迁移与同步从生产环境导出基础表到测试环境或者做数据脱敏前的准备工作。全库导出太多噪音按表导出干净利落。规避大对象表和日志表附件表、日志表动辄几十 G导出慢、恢复也慢。做指定表备份时把它们排除在外效率能翻好几倍。1.3 白名单和黑名单我为什么偏向白名单sys_dump 同时支持-t指定表和-T排除表两种方式。有人喜欢用黑名单先备份全库再排除日志表。但我个人在自动化脚本里推荐白名单模式理由很简单黑名单需要你时刻知道库里新增了哪些不该备的表一旦有 DBA 建了一张大表又没更新排除列表备份任务就会莫名其妙变慢而白名单是“清单里没有的我一律不备”行为完全可控。选表的时候我会把有主外键关联的表尽量放进同一批清单里。比如订单表和订单明细表如果只备订单表恢复后明细表关联不上这套备份就失去了意义。2. sys_dump 的指定表参数命令本身比脚本更值得搞懂2.1 先认准你环境里的工具名金仓 KingbaseES 不同版本、不同兼容模式的工具命名有差异。我手上这套 V8R6 环境逻辑备份命令叫sys_dump早期兼容 Oracle 的版本命令名可能是kdb_dump。你不确定的话直接看目录ls $KINGBASE_HOME/bin | grep -i dump正常情况下你能看到sys_dump、sys_restore这类命令。金仓默认端口通常是 54321默认超级用户常见的是system生产环境一般会改掉这个要结合自己的部署确认。2.2 一条最基本的单表备份命令假设我要备份testdb库里的public.sys_config和public.sys_user两张表命令长这样sys_dump -h 127.0.0.1 -p 54321 -U system -d testdb \ -t public.sys_config \ -t public.sys_user \ --no-owner --no-privileges \ -F plain -f /tmp/tables.sql执行完之后/tmp/tables.sql里就是这两张表的建表语句和数据插入语句。整个命令的核心就是-t它和 PostgreSQL 的pg_dump -t行为基本一致可以重复使用多次每指定一次就多备份一张表。2.3 表名匹配是最容易翻车的地方这一步我踩过好几次坑重点说说第一大小写敏感。金仓在不加引号建表时表名在元数据里默认是小写存储所以-t SysConfig是匹配不到的必须写public.sys_config。如果建表时用了双引号比如UserMain那表名里的字母大小写是真实保留的清单里要写成public.UserMain命令里同样要带双引号。第二schema 前缀。表不在publicschema 下时必须写schema.table否则 sys_dump 会提示找不到匹配的表。跨 schema 备份时这个前缀几乎是必写的。第三通配符要小心。-t public.log_*会匹配所有以log_开头的表有时候是好事但脚本化之后很容易因为一个通配符把不想备的表带进来。我在表清单里全部写全名杜绝意外。参数这块我整理了下面这个速查表平时写脚本对照着用就行参数作用备注-t/--table指定要备份的表可多次使用推荐白名单-T/--exclude-table排除指定表黑名单思路适合大库排除日志表--schema-only只备份表结构迁移结构时好用--data-only只备份数据数据同步时常用-F plain输出普通 SQL 文本默认格式可用 psql 恢复可压缩-F custom输出自定义格式恢复时用 sys_restore支持并行恢复-F directory输出目录格式适合大表配合-j并行--no-owner不导出对象属主避免恢复环境用户名不一致时报错--no-privileges不导出权限同上恢复时更省事3. 可运行的备份脚本表清单外置、日志独立、自动清理3.1 为什么要把表清单放到脚本外面很多人写备份脚本习惯把表名直接写在脚本里。这在只有四五张表的时候问题不大但一旦表数量多了、业务调整频繁了你会发现每次加表都要改脚本改完还得小心别把逻辑改坏。我的做法是把表清单单独放在一个文本文件里脚本只负责读文件、组装命令、执行备份、写日志。这样运维或 DBA 要增删表只需要编辑一个纯文本清单不需要碰脚本本身。一行一个表名支持#注释干净直观。表清单table_list.txt示例# 核心配置表 public.sys_config public.sys_menu public.sys_role public.sys_user # 订单相关 public.t_order public.t_order_item3.2 完整脚本正文下面这个脚本是我在用的版本简化而来兼顾了配置灵活性、日志完整性和保留策略直接保存成backup_tables.sh就能用#!/bin/bash # 金仓 KingbaseES 指定表逻辑备份脚本 # 适用V8R6 环境sys_dump如你的环境命令是 kdb_dump替换对应命令名即可 set -euo pipefail export KINGBASE_HOME${KINGBASE_HOME:-/opt/Kingbase/ES/V8} export PATH$KINGBASE_HOME/bin:$PATH export LD_LIBRARY_PATH$KINGBASE_HOME/lib:${LD_LIBRARY_PATH:-} # 可配置区 DB_HOST${DB_HOST:-127.0.0.1} DB_PORT${DB_PORT:-54321} DB_USER${DB_USER:-system} DB_PASSWORD${DB_PASSWORD:-} DB_NAME${DB_NAME:-testdb} BACKUP_DIR${BACKUP_DIR:-/data/kingbase_backup} TABLE_LIST_FILE${TABLE_LIST_FILE:-/data/kingbase_backup/table_list.txt} RETENTION_DAYS${RETENTION_DAYS:-7} DUMP_FORMAT${DUMP_FORMAT:-plain} # plain / custom # if [ -n $DB_PASSWORD ]; then export PGPASSWORD$DB_PASSWORD fi RUN_TIME$(date %Y%m%d_%H%M%S) LOG_DIR$BACKUP_DIR/logs LOG_FILE$LOG_DIR/backup_${RUN_TIME}.log mkdir -p $BACKUP_DIR $LOG_DIR # 所有输出统一写入日志方便定时任务排查 exec $LOG_FILE 21 log() { echo [$(date %Y-%m-%d %H:%M:%S)] $* } log 指定表备份任务开始 log 备份数据库: $DB_NAME备份目录: $BACKUP_DIR if [ ! -f $TABLE_LIST_FILE ]; then log [错误] 表清单文件不存在: $TABLE_LIST_FILE exit 1 fi # 过滤空行和注释行读取表清单 mapfile -t TABLES (grep -vE ^[[:space:]]*(#|$) $TABLE_LIST_FILE | sed s/[[:space:]]*$//) if [ ${#TABLES[]} -eq 0 ]; then log [错误] 表清单为空请检查 $TABLE_LIST_FILE exit 1 fi log 将备份 ${#TABLES[]} 张表 for t in ${TABLES[]}; do log - $t done DUMP_FILE$BACKUP_DIR/${DB_NAME}_${RUN_TIME} DUMP_ARGS(-h $DB_HOST -p $DB_PORT -U $DB_USER -d $DB_NAME) for t in ${TABLES[]}; do DUMP_ARGS(-t $t) done # 不带属主和权限避免恢复到其他环境时因为用户名不一致报错 DUMP_ARGS(--no-owner --no-privileges) if [ $DUMP_FORMAT custom ]; then DUMP_ARGS(-F custom -f ${DUMP_FILE}.dump) FINAL_FILE${DUMP_FILE}.dump else DUMP_ARGS(-F plain -f ${DUMP_FILE}.sql) gzip_temp1 fi if sys_dump ${DUMP_ARGS[]}; then log sys_dump 执行成功 else log [错误] sys_dump 退出码非 0备份失败请检查上方输出 exit 1 fi if [ ${gzip_temp:-0} 1 ]; then gzip ${DUMP_FILE}.sql FINAL_FILE${DUMP_FILE}.sql.gz fi log 备份文件: $FINAL_FILE log 文件大小: $(du -h $FINAL_FILE | awk {print $1}) # 清理过期备份文件 find $BACKUP_DIR -maxdepth 1 -type f \( -name *.sql.gz -o -name *.dump \) -mtime ${RETENTION_DAYS} -delete log 已清理 ${RETENTION_DAYS} 天前的备份文件 log 指定表备份任务结束 3.3 脚本里的几个关键设计点先说set -euo pipefail。这行很多人不重视但备份脚本里必须加。-e保证脚本遇到任何错误就退出不会让你看到“备份已完成”的假象-u避免变量没赋值导致命令变得不可预测pipefail保证管道中任何一段失败整个管道返回失败。虽然我手动写了 if 判断 sys_dump 的执行结果但基础开关能让整个脚本更稳健。再说环境变量。定时任务里最容易丢的就是KINGBASE_HOME和LD_LIBRARY_PATH。crontab 默认环境 PATH 只有/usr/bin:/bin金仓的 bin 目录默认在/opt/Kingbase/ES/V8/bin不显式 export 的话脚本里调用 sys_dump 会直接报 command not found。而LD_LIBRARY_PATH更隐蔽动态库加载失败时 sys_dump 可能直接闪退报错还特别难懂。密码这里我再强调一下。脚本里虽然支持 DB_PASSWORD 环境变量但明文密码放在脚本里本身有泄露风险。更推荐的做法是用.pgpass文件echo 127.0.0.1:54321:testdb:system:你的密码 ~/.pgpass chmod 600 ~/.pgpass然后在脚本里不设置 DB_PASSWORD让libpq自动去读~/.pgpass。如果脚本是被 cron 调用最好在脚本开头显式指定export PGPASSFILE${PGPASSFILE:-$HOME/.pgpass}3.4 保留策略和日志清理备份目录如果不做清理磁盘迟早会被拖垮。脚本里的find ... -mtime N -delete就是负责干这个的保留天数用RETENTION_DAYS控制我生产环境通常设 7 天。注意 maxdepth 1 是为了只清理当前层的备份文件不误删 logs 目录里的日志或其他子目录内容。logs 目录本身也会越来越大这个脚本我没有做日志轮转但不代表可以不管。我会在服务器上另配一个 crontab 规则比如每天清理 30 天前的脚本日志30 3 * * * find /data/kingbase_backup/logs -type f -name *.log -mtime 30 -delete这属于运维基础卫生做过一次就再也不想手动删日志了。4. 定时执行与首次实测crontab 环境里的三个暗坑4.1 crontab 配置与首次运行脚本写好后先手动跑一遍chmod x /data/kingbase_backup/backup_tables.sh /data/kingbase_backup/backup_tables.sh手动跑没问题后再加定时任务。我习惯用crontab -e配置每天凌晨 2 点 30 分执行30 2 * * * /bin/bash /data/kingbase_backup/backup_tables.sh这里用/bin/bash显式调用是为了避免脚本执行权限或 shebang 解析出问题。如果你的系统 bash 路径不同用which bash确认一下。4.2 cron 环境里最容易踩的三个坑第一个坑是 PATH 不完整。前面说了cron 的 PATH 极简金仓 bin 目录根本不在里面。所以脚本里必须自己 export PATH。这个脚本已经在开头做了但如果是你自己写的简化版本很容易漏。第二个坑是 LD_LIBRARY_PATH 丢失。很多金仓命令依赖安装目录下的动态库没有 LD_LIBRARY_PATHsys_dump 可能运行到一半报“libkci.so: cannot open shared object file”之类的错误。这也是为什么我在脚本开头就 export。第三个坑是 HOME 环境变量不确定。cron 执行脚本时HOME 可能不是你登录用户的 HOME这会导致.pgpass找错位置。解决办法是在脚本里显式 export PGPASSFILE或者干脆在可配置区把DB_PASSWORD写上如果安全要求没那么高内网环境这个方案最简单直接。4.3 一次真实运行的日志长什么样我截取一段实际跑完后的日志片段格式做了脱敏处理方便你对输出有个预期[2026-06-11 02:30:00] 指定表备份任务开始 [2026-06-11 02:30:00] 备份数据库: testdb备份目录: /data/kingbase_backup [2026-06-11 02:30:00] 将备份 6 张表 [2026-06-11 02:30:00] - public.sys_config [2026-06-11 02:30:00] - public.sys_menu [2026-06-11 02:30:00] - public.sys_role [2026-06-11 02:30:00] - public.sys_user [2026-06-11 02:30:00] - public.t_order [2026-06-11 02:30:00] - public.t_order_item [2026-06-11 02:30:08] sys_dump 执行成功 [2026-06-11 02:30:09] 备份文件: /data/kingbase_backup/testdb_20260611_023000.sql.gz [2026-06-11 02:30:09] 文件大小: 18M [2026-06-11 02:30:09] 已清理 7 天前的备份文件 [2026-06-11 02:30:09] 指定表备份任务结束 对比刚才说的全库备份 70 多 G、40 分钟指定表备份 18 M、9 秒差距就是这么大。当然这个数据量不算大但即使核心表再多几倍速度优势也是数量级的。4.4 备份文件的正确验证姿势备份完不等于万事大吉我每两周会做一次恢复演练方法是找一个临时库把备份文件恢复进去再对比关键表的行数。简单的命令如下# 准备临时库在目标实例上创建 createdb -h 127.0.0.1 -p 54321 -U system restore_test # 恢复备份文件 gunzip -c /data/kingbase_backup/testdb_20260611_023000.sql.gz \ | psql -h 127.0.0.1 -p 54321 -U system -d restore_test # 对比行数 psql -h 127.0.0.1 -p 54321 -U system -d restore_test \ -c select count(*) from public.sys_config;行数一致这份备份才算真正有效。如果只是备份不去验证遇到序列值丢失、权限缺失、外键依赖这些问题到真需要恢复时才暴露那时候已经晚了。5. 从备份到恢复指定表恢复的实操和踩坑记录5.1 三种格式对应的恢复方式plain 纯文本格式最通用直接交给 psql 执行即可gunzip -c backup_file.sql.gz | psql -h 127.0.0.1 -p 54321 -U system -d targetdbcustom 格式要用 sys_restore 恢复而且可以并行加速sys_restore -h 127.0.0.1 -p 54321 -U system -d targetdb -j 4 backup_file.dump如果目标库里的表已经存在恢复前通常要先清理掉或者恢复时加--clean --if-exists。不过纯文本格式不支持这两个参数我更倾向于在 psql 脚本里手动DROP TABLE IF EXISTS ... CASCADE;然后再导入。5.2 恢复时最常踩的四个坑第一个坑外键依赖的表不在备份清单里。你只备份了t_order但t_order_item上有外键引用它恢复时 sys_dump 可能报找不到引用表。解决办法就是在选表阶段把有关联的表一起放进来或者接受恢复后缺外键的状态后续手工维护。第二个坑schema 不存在。如果表在financeschema 下恢复库如果没创建过这个 schema就会出现schema finance does not exist。我习惯在恢复脚本里预先执行CREATE SCHEMA IF NOT EXISTS finance;或者在源库导出时确认 sys_dump 是否自动带了 schema 定义。第三个坑序列值没有跟着走。备份了用户表但用户表主键用的序列没备恢复之后插入新数据主键可能从头开始直接撞上已有记录。这个坑很隐蔽我一直到一次真实的恢复演练才暴露出来。解决办法是把相关序列也加进表清单比如public.seq_user_id public.seq_order_id第四个坑管理员权限和属主问题。导出时如果没加--no-owner --no-privileges恢复环境的数据库用户和导出环境的用户一旦不一致恢复过程就会试图创建原属户或分配权限大概率报错。这也是脚本里我坚持写这两个参数的真正原因。5.3 我个人坚持的几个习惯最后分享几个纯粹是实践经验沉淀下来的习惯不保证每个人都认同但在我自己维护的系统里确实避免了不少麻烦。第一个习惯是备份文件命名一定带库名和时间戳。没有时间戳的备份文件等你攒了一周之后根本分不清哪份是哪天的。文件名里的库名也很重要一个实例上挂了多个库的时候能避免恢复时拿错文件。第二个习惯是脚本输出必须留全文日志。备份任务的排查绝大多数发生在第二天早上你不可能守着终端看输出日志文件是唯一的线索。所以我坚持把所有 stdout 和 stderr 都重定向到日志文件而不是只记录“备份成功”四个字。第三个习惯是定期做恢复演练而不是只在出大事的时候才想起来恢复。我见过太多团队备份脚本写得漂漂亮亮真到恢复时连备份文件都没法用。指定表备份脚本因为涉及的表数量少、范围明确其实是做恢复演练成本最低的一类备份顺手就把这份功课补上了。第四个习惯是表清单变化时要重新走一遍恢复验证。每次往 table_list.txt 里加新表我都会跑一次临时库恢复确认新增的表能正常恢复、没有外键依赖缺失。这套流程跑熟了以后整个备份体系基本可以做到“改了清单不慌、出了事故能扛”。