备份这种事平时看起来毫无存在感真出事了才知道命都是它给的。前阵子给一个客户做国产化改造后的容灾方案评审发现他们对人大金仓Kingbase的单机部署特别不上心——每天用 tar 打包数据库目录备份文件就扔在同一台服务器的另一块磁盘上。我当场问了一句如果这台服务器整机故障你的备份在哪里对方答备份就在这台机器上啊。我说那备份也跟着一起没了。对方沉默了半天。这就是我写这篇内容的原因。Kingbase 单机部署在政企项目里非常普遍但“异机备份与恢复”这件事大量团队要么没做要么做得极其粗糙——备份没有离开源机器等于白做。这篇文章我会把方案选型、工具用法、完整操作流程和踩坑记录一次性讲清楚重点覆盖 sys_basebackup 物理备份、sys_dump 逻辑备份两种主流方式以及它们如何跨机器恢复。适合正在维护 Kingbase 单机环境的运维、DBA以及做国产化替代项目的实施工程师参考内容可以直接抄作业。1. 为什么单机数据库也要做异机备份1.1 单机部署最常见的三个备份误区先说结论单机数据库不等于不需要备份策略恰恰相反单机库因为没主从、没高可用数据只有一份备份几乎是唯一的保命手段。我在实际项目里见到的备份误区翻来覆去就是这三类。第一类备份文件和源数据在同一物理机上。很多人用 cp 或者 tar 把数据目录复制一份放在同一台机器的另一个目录里甚至放在同一块硬盘上。这种情况遇到系统盘损坏、整机掉电、勒索病毒加密备份会和源数据一起完蛋等于没有备份。第二类做了备份但从不做恢复验证。备份文件生成了大小看着也正常但从来没在别的机器上恢复过等到真出故障时才发现备份包损坏、版本不匹配、缺少归档日志根本恢复不了。第三类备份周期不合理。有些项目一个月才备份一次数据丢失窗口长达三十天业务上完全无法接受。异机备份解决的就是第一类问题把备份数据从生产机器“物理搬走”放到另一台独立的主机上。这样即使生产机整机故障备份数据仍然完好具备恢复条件。1.2 异机备份适用的典型场景异机备份并不是什么复杂的高端方案它适合绝大多数有“基本容灾诉求”的单机环境。我梳理了几个最常见的落地场景。生产环境单机部署公司要求基础容灾能力。这是最常见的情况预算有限、架构简单但老板要求“数据不能丢”这时候每天或者每周把备份传输到另一台机器是最务实的方案。数据库迁移或升级前后的安全网。做版本升级、服务器迁移之前先往异机做一份全量备份万一迁移失败可以在旧机器上继续跑也可以在新机器上快速回滚。测试环境与生产环境隔离。需要一套和生产库数据一致的测试库时直接从生产机异机恢复一份到测试机不干扰线上业务。灾备演练。定期把生产备份恢复到备用机器上确认恢复出来的数据完整、服务可用这本身就是最有效的备份体系体检。1.3 先理清 Kingbase 的备份体系Kingbase人大金仓和 PostgreSQL 有着密切的渊源备份工具体系和 PG 也很相似。单机部署下常用备份手段有三类。sys_basebackup物理备份工具对应 PG 的 pg_basebackup直接复制整个数据目录支持在线备份操作期间不要求停库。sys_dump逻辑备份工具对应 PG 的 pg_dump导出为 SQL 脚本或自定义格式文件粒度可以精细到表级别。系统级冷备份停掉数据库直接打包数据目录。简单粗暴但要求停机窗口适合能接受短暂停服的场景和早期版本。实际项目中我见过不少实施人员只用冷备份因为简单。但冷备份要求业务停机而且同样需要把备份文件搬到异机。对于 7×24 小时在线的系统学会 sys_basebackup 才是正路。下面我会把物理备份和逻辑备份异机恢复的完整流程分别展开再给出一个可以落地的自动化组合方案。2. 备份方案选型物理备份还是逻辑备份2.1 物理备份 sys_basebackup全量快照恢复最快先讲物理备份。sys_basebackup 的底层原理是在源库上发起一个基础备份请求数据库进入备份模式工具实时复制数据目录下的所有数据文件同时把备份期间产生的 WAL 日志一并收集最终得到一个与源库某一时刻一致的完整物理快照。这个方式最核心的优势是恢复速度。恢复时不需要逐条执行 SQL而是把整个数据目录直接摆好启动数据库即可对外服务。对一个几十 GB 的数据库物理恢复通常几十分钟内就能搞定效率远高于逻辑恢复。同时它的还原度最高所有表、索引、序列、权限、配置参数、事务状态全部原封不动地恢复。劣势也同样明显备份文件体积大与数据目录实际占用差不多传输到异机需要更大的带宽和存储空间。另外一个硬性要求是源端和目标端的 Kingbase 主版本必须一致跨大版本恢复会失败。2.2 逻辑备份 sys_dump粒度灵活跨版本友好逻辑备份走的是另一条路线。sys_dump 把数据库对象转换成 SQL 语句或者自定义二进制格式导出恢复时通过执行这些 SQL 来重建数据。它的优势在于灵活。你可以备份整个数据库也可以只备份某几张表、某个 schema导出的 SQL 文件可以查看、编辑甚至可以在不同版本之间恢复比如从 V8 导出恢复到 V9只要兼容性允许备份文件通常比物理备份小便于长期保存。但逻辑备份的恢复速度确实很感人。我做过一次测试一张 1.2 亿行的大表sys_dump 导出用了大概 18 分钟而 sys_restore 导入整整跑了一个多小时。如果数据库里有超大表逻辑恢复的时间窗口会非常难控制。另外逻辑备份恢复后需要重建部分数据库对象配置比如归属性、表空间路径等运维上要多注意。2.3 实际项目中的组合策略选型没有绝对的对错关键是匹配业务诉求。我给单机用户推荐的组合策略是这样的核心生产库每周做一次 sys_basebackup 物理备份传送到异机保留每天凌晨再做一次 sys_dump 逻辑备份保留最近 7 到 14 天。物理备份兜底逻辑备份补充中间窗口的数据。如果业务数据量小、压力不大那逻辑备份可以覆盖全部周期。如果业务要求分钟级恢复那就需要折腾归档日志和 PITR但这基本超出“单机异机备份”的范畴后文不做过多展开。还要强调一件事不管你选哪种备份方式备份文件一定要和源机器分离存储。哪怕是传到另一台机器上再配合定期异地拷贝也比留在本机强一百倍。3. 异机物理备份恢复实操sys_basebackup 全流程3.1 环境准备与关键信息确认异机恢复的第一步不是敲命令而是确认两边的环境一致。我一般按下面的清单检查。版本一致性在源库执行select version();确认数据库版本号。目标机安装的 Kingbase 服务器软件需要和源库主版本一致比如两边都是 V8。小版本有差异通常问题不大但主版本不同会导致恢复后无法启动或数据不兼容。目录规划确认源库数据目录路径、目标机新数据目录路径、备份中转目录路径。避免恢复时因为路径不对到处找文件。软件安装目标机需要预先安装好 Kingbase 服务端软件并且完成初始化通常安装程序会自动初始化一个数据目录后续我们只需要把备份数据替换进去。网络连通源库到目标机之间的端口要能正常通信尤其是 ssh 传输端口和数据库端口 54321V8 默认端口。一个非常容易踩的坑是目标机上的数据库服务忘记停。恢复备份之前目标机上的旧数据库进程必须完全停止否则新数据文件被覆盖时会出现锁冲突或者文件占用恢复必然失败。3.2 源库执行 sys_basebackup以常见的 V8 版本为例备份工具路径通常在/opt/Kingbase/ES/V8/Server/bin/sys_basebackup。登录源库所在服务器切换到 kingbase 用户执行/opt/Kingbase/ES/V8/Server/bin/sys_basebackup \ -h 192.168.10.11 \ -p 54321 \ -U system \ -D /data/kingbase_backup/full_backup_$(date %Y%m%d) \ -F tar \ -X stream \ -z \ -P参数含义拆解-h和-p源库 IP 和端口。实测中也可以不指定默认走本地 socket但既然要异机备份建议写清楚地址。-U system使用超级用户 system 执行备份。必须使用具备超级权限的账号普通用户没有权限做基础备份。-D备份输出目录这个目录会生成完整的物理备份数据。-F tar把备份打成一个 tar 包方便后续传输。如果不指定直接输出成独立文件目录。-X stream备份过程中产生的 WAL 日志以 stream 方式同步收集保证备份集是一个完整的、可恢复的时间点快照。-z压缩输出实测能减少 30% 到 50% 的传输体积。-P显示进度。备份几十 GB 数据时没有进度反馈那种感觉非常煎熬。执行完成后备份目录下会出现base.tar.gz、pg_wal.tar.gz或者wal.tar.gz这些文件。注意如果使用了-F tar不要直接拿这个 tar 包在目标机上解压到数据目录要按后面的步骤处理。3.3 备份包传输到异机这一步并不复杂但传输完整性很重要。我用得最多的方式是 rsync因为支持断点续传和校验。示例命令rsync -avzP \ /data/kingbase_backup/full_backup_$(date %Y%m%d)/ \ root192.168.10.22:/data/kingbase_backup/from_prod/如果两台机器之间网络带宽有限可以先用 tar 打包压缩再传cd /data/kingbase_backup tar czf kingbase_full_backup_20250105.tar.gz full_backup_20250105 scp kingbase_full_backup_20250105.tar.gz root192.168.10.22:/data/kingbase_backup/传输完成后在目标机上做一次文件大小核对对比源端备份目录的大小和目标端接收目录的大小。常见错误是传输中断导致备份文件缺失等到恢复时才暴露问题。3.4 目标机恢复物理备份假设目标机已经安装好 Kingbase 服务端软件默认数据目录是/opt/Kingbase/ES/V8/data。恢复步骤按顺序来停止目标机上的数据库服务systemctl stop kingbase8d如果安装方式不是 systemd 管理也可以切换 kingbase 用户执行su - kingbase /opt/Kingbase/ES/V8/Server/bin/sys_ctl -D /opt/Kingbase/ES/V8/data stop备份旧数据目录。不要直接删除先改名保留mv /opt/Kingbase/ES/V8/data /opt/Kingbase/ES/V8/data_old_bak mkdir -p /opt/Kingbase/ES/V8/data解压备份包。因为前面用了-F tar -z所以备份输出是base.tar.gz和pg_wal.tar.gz。把这两个包都放到目标机的数据目录下再解压cd /opt/Kingbase/ES/V8/data tar xzf /data/kingbase_backup/full_backup_20250105/base.tar.gz tar xzf /data/kingbase_backup/full_backup_20250105/pg_wal.tar.gz完整解压后数据目录下会看到base/、global/、pg_wal/、kingbase.conf、sys_hba.conf等文件和目录。调整目录属主。这一步极其关键几乎所有恢复启动失败都是因为属主不对chown -R kingbase:kingbase /opt/Kingbase/ES/V8/data chmod 700 /opt/Kingbase/ES/V8/data检查并调整kingbase.conf中的监听地址。备份恢复会把源库的配置文件也恢复过来如果源库配置了listen_addresses 192.168.10.11目标机 IP 是192.168.10.22那启动后数据库只会监听在旧 IP 上新机器上自然连不上。改成本机 IP 或者 0.0.0.0sed -i s/192.168.10.11/0.0.0.0/g /opt/Kingbase/ES/V8/data/kingbase.conf还要顺便看一眼sys_hba.conf确认客户端认证条目允许你的业务网络访问。启动数据库systemctl start kingbase8d或者su - kingbase /opt/Kingbase/ES/V8/Server/bin/sys_ctl -D /opt/Kingbase/ES/V8/data start验证恢复结果。这一步不能想当然要实际查询select * from information_schema.tables; -- 查看表数量是否与源库一致 select count(*) from 核心业务表; -- 抽取几张关键表对比行数3.5 物理恢复实际踩过的一个坑有次恢复后数据库能正常启动但应用连接时报“数据库无法获取序列值”排查发现序列的当前值比源库低了一大截。原因是物理备份带的是备份时刻的序列状态如果备份后源库还在持续写入那么恢复出来的序列值自然落后。对这种场景恢复后需要主动校准序列select setval(业务序列名, (select max(id) from 业务表)); select setval(业务序列名, (select max(id) from 业务表));这个细节文档里不常写但在生产环境特别重要建议在恢复核对清单里加上一条。4. 异机逻辑备份恢复实操sys_dump 与 sys_restore4.1 使用 sys_dump 导出备份文件逻辑备份的适用场景更垂直数据量不大、跨版本迁移、需要按表恢复。导出命令同样在工具目录下执行/opt/Kingbase/ES/V8/Server/bin/sys_dump \ -h 192.168.10.11 \ -p 54321 \ -U system \ -F c \ -f /data/kingbase_backup/appdb_$(date %Y%m%d).dmp \ appdb参数说明-F c自定义格式这个格式体积小、支持选择性恢复也比纯 SQL 脚本稳定。不要用-F p纯 SQL 格式除非你有文本编辑需求。-f输出文件名建议带日期后缀方便保留多份。appdb要备份的数据库名。如果想单独备份某几张表可以追加参数sys_dump ... -F c -f /data/backup/orders.dmp -t orders -t order_items appdb如果想压缩备份文件最常见的方式还是交给工具内部的自定义格式来处理-F c本身就有压缩效果实测同量级数据比纯 SQL 文件小很多。4.2 在异机执行 sys_restore 恢复sys_restore 是把.dmp文件恢复到目标数据库的工具。恢复前目标端必须已经创建好目标数据库注意sys_restore 默认不会自动创建数据库只会往已有数据库里灌数据。在目标机执行/opt/Kingbase/ES/V8/Server/bin/sys_restore \ -h 192.168.10.22 \ -p 54321 \ -U system \ -d appdb \ /data/kingbase_backup/appdb_20250105.dmp恢复的完整度取决于备份时的对象范围。如果导出的库包含建表、建索引等 DDL 语句恢复会自动重建如果只导出了数据就需要提前手工创建好表结构否则会报“表不存在”。恢复之前还可以用以下命令查看备份包里包含哪些对象提前心里有数/opt/Kingbase/ES/V8/Server/bin/sys_restore --list /data/kingbase_backup/appdb_20250105.dmp这个命令输出一个对象清单包括表、索引、约束、函数等非常实用。它能帮你确认备份文件没有损坏也能帮你在恢复前评估大概需要哪些前置条件。4.3 逻辑恢复过程中必须注意的四个坑第一个坑是目标数据库没建或者名字大小写不一致。Kingbase 对数据库名区分大小写非常严格appdb和AppDB是两个库恢复时务必写对名字。第二个坑是角色和属主不存在。如果备份文件里有CREATE TABLE ... OWNER TO这样的语句而目标机已有用户列表里没有这个角色恢复会报“角色不存在”。解决方法是恢复前在目标机创建同名角色或者恢复后统一处理属主。第三个坑是外键约束导致的导入顺序冲突。自定义格式下 sys_restore 会尽量按照依赖顺序导入但某些复杂场景下仍可能报外键找不到这时可以先用参数禁用约束后导入数据再单独重建外键。第四个坑是我最想强调的不要在生产高峰期做逻辑恢复。逻辑恢复过程中目标库会持续写入占用大量 I/O 和 CPU如果目标机还要承载业务很容易把整个机器拖垮。实际项目里我见过有人白天直接在业务库上跑恢复结果应用响应时间从 50ms 飙到 5 秒差点引发事故。逻辑恢复尽量安排在业务低峰期并且提前评估目标机的资源余量。5. 备份自动化脚本方案异地备份落地5.1 一个可直接使用的物理备份脚本异机备份不能靠人工敲命令必须脚本化。下面这个脚本我做成了通用模板你只需要改几个变量放到 crontab 里就能用#!/bin/bash export PATH/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin BACKUP_BASE/data/kingbase_backup TARGET_HOSTroot192.168.10.22 TARGET_DIR/data/kingbase_backup/from_prod KINGBASE_HOME/opt/Kingbase/ES/V8/Server/bin BACKUP_DIR${BACKUP_BASE}/full_$(date %Y%m%d_%H%M%S) BACKUP_FILE${BACKUP_BASE}/kingbase_full_$(date %Y%m%d).tar.gz mkdir -p ${BACKUP_DIR} ${KINGBASE_HOME}/sys_basebackup \ -h 127.0.0.1 \ -p 54321 \ -U system \ -D ${BACKUP_DIR} \ -F tar \ -X stream \ -z \ -P /var/log/kingbase_backup.log 21 if [ $? -eq 0 ]; then echo $(date %F %T) 备份成功开始传输到异机 /var/log/kingbase_backup.log rsync -avzP ${BACKUP_DIR}/ ${TARGET_HOST}:${TARGET_DIR}/ /var/log/kingbase_backup.log 21 else echo $(date %F %T) 备份失败请检查源库状态 /var/log/kingbase_backup.log exit 1 fi # 清理本地 7 天前的临时备份目录 find ${BACKUP_BASE} -name full_* -mtime 7 -exec rm -rf {} \; /var/log/kingbase_backup.log 21脚本里的几个细节说一下备份目录用日期区分每次都是独立目录方便后续定位某个时间点的备份备份成功后立刻 rsync 到异机这样远程机器始终保留最新数据本地临时目录只保留 7 天异机上的备份保留策略再单独定。5.2 定时调度与保留策略crontab 配置如下每天凌晨 2 点执行一次全量物理备份0 2 * * * /opt/scripts/kingbase_backup.sh /var/log/kingbase_backup.log 21如果你同时想要逻辑备份做补充可以早上 6 点再加一个 sys_dump 任务0 6 * * * /opt/scripts/kingbase_logic_backup.sh /var/log/kingbase_logic_backup.log 21保留策略我建议分两种维度来看。本地备份保留 7 天用于快速恢复异机备份保留 4 周甚至更久用于应对更长期的追溯和审计需求。如果机器空间允许每个月第一个周末的备份单独挪到一个归档目录谁也不动它以防“所有副本同时过期”的情况发生。5.3 定期恢复演练更重要备份脚本能跑通不代表恢复能力合格。我给客户做方案时反复强调一个原则至少每个季度做一次完整的异机恢复演练把备份恢复到一台备用机器上跑一遍关键业务查询再出一份恢复报告。演练过程就是验证备份文件完整性、工具可用性、配置正确性和团队操作熟练度的唯一途径。我见过一个真实案例某单位每周都做备份半年后需要恢复时发现备份文件因为磁盘静默损坏已经读不出来了。如果有做恢复演练这个问题在第三个月就会发现。演练很麻烦但总比真出事时抓瞎强。6. 恢复过程中的故障排查速查表6.1 启动失败类问题恢复后数据库启动不了是异机恢复最常遇到的状况。我整理了一张速查表按实际频率排了序。故障现象排查方向解决操作日志报数据目录权限无效目录属主变成 root 或 755 权限chown -R kingbase:kingbase数据目录设置属主权限 700启动报 bind 地址失败原配置文件里监听了旧 IP修改 kingbase.conf 的 listen_addresses 为 0.0.0.0 或目标机 IP启动报 invalid data directory备份包不完整或版本不匹配重新传输备份包确认源端目标端主版本一致连接时提示 no pg_hba.conf entrysys_hba.conf 没有放行业务地址编辑 sys_hba.conf 增加允许网段重启服务日志有 huge_pages 相关警告操作系统大页内存配置问题按要求关闭或调整系统 huge_pages不会影响启动但建议排查特别要留意启动日志的位置一般写在数据目录下的sys_log/或log/里。恢复失败时先看日志比瞎猜要快得多。6.2 数据校验类问题恢复完成不代表数据没问题尤其跨机器恢复后校验这一步不能省。我的经验是先做三层检查。第一层对象数量比对。在源库和目标机分别执行select count(*) from information_schema.tables where table_schema public;两边数字一致说明表结构基本到位。第二层关键表行数抽查。选 5 到 10 张核心业务表分别执行select count(*)逐一对数。第三层业务冒烟。让应用连一下恢复后的库跑几个核心接口看日志有没有报错。很多问题靠 SQL 检查发现不了必须让真实业务走到代码逻辑里去验证。6.3 备份文件安全与容量管理备份文件本身也是高价值资产同样需要纳入管理。我见过很多客户把备份文件直接放在没有任何权限控制的普通目录里任何能登录这台机器的人都能看到全部业务数据。建议备份目录至少做到独立分区挂载避免根目录空间打满影响系统权限收紧到仅备份账号可读写定期检查磁盘剩余空间物理备份如果连续做几次全量空间会很快耗尽。我的惯例是在备份机上写一个简单的空间预警脚本磁盘使用率超过 85% 就发告警防止备份还没做完磁盘先满了。另一个安全细节是备份文件的完整性校验。每次备份完成后记录一份 md5sum 或者 sha256 校验值连同备份文件一起存到异机。恢复前先跑一遍 checksum能直接识别出传输损坏的问题避免恢复到最后一步才发现文件坏了。6.4 备份机制本身的监控很多备份项目的问题不在技术而在“备份任务悄悄失败了但没人知道”。我给运维团队的建议是把备份日志集中收集至少做到每天看一次备份结果。如果系统里有监控平台就把备份脚本结束状态接入告警失败时立刻通知如果没有监控平台那就让备份脚本把执行结果写到数据库一张状态表里早上到办公室先刷一眼。这比依赖“三个月后才发现备份坏了”要稳妥得多。写在最后这几年做国产化数据库交付我最大的感受是备份方案本身的技术门槛并不高真正拉开差距的是执行细节和恢复能力。异机备份真正要解决的不是“把文件拷走”这个动作而是“在另一台机器上随时能把业务接回来”这种能力。而能力的验证只有靠一次一次真实的恢复演练。如果你现在负责维护一套 Kingbase 单机库我建议你别急着优化备份脚本先在下个维护窗口做一次完整的异机恢复演练在备用机上恢复一份最新备份跑一遍核心业务查询把所有卡住的环节记下来再回头改你的备份方案和脚本。等到真出事那天你会感谢那个提前演练过的自己。另外提醒一个容易忽略的操作习惯不要在业务高峰做恢复操作也不要在没有备份的情况下动数据目录。我见过太多“先动再备份”的翻车案例安全永远是第一位。希望这份实操记录能帮你少踩几个坑。