第二大脑

主题

2026-08-24
912
3.4m

KingbaseES 备份方案（物理 sys_backup + 逻辑 suptools） ​

一句话机制：物理备份（sys_backup，基于 WAL 归档的 rman 仓库）保证"崩溃级"恢复；逻辑备份（suptools kb_backup，定时 dump）保证"业务级"数据导出；两者互补且物理备份必做——高可用防节点故障，备份防逻辑错误与介质损坏。

不变量（必须成立的约束） ​

  1. 物理备份（sys_backup）是底线，必做：sys_backup.conf 中 _target_db_style="single"（集群模式脚本会自行用 repmgr cluster show 推导其他节点）、_one_db_ip 填本机物理 IP、_repo_ip 与之一致、_repo_path=/data/kingbase/backup/rman。策略上全量 + 增量错峰：如保留 3 份全量、7 天 1 次全量（凌晨 2 点）+ 1 天 1 次增量（凌晨 4 点）。初始化顺序：./sys_backup.sh init（建 rman 仓库）→ ./sys_backup.sh start（写入 crontab）→ crontab -l 确认。
  2. 归档必须真实可用：archive_command 不能留空（现场文档初稿为空，会导致 WAL 归档持续失败、日志刷屏、主库压力下 WAL 堆积、备库 LSN_Lag 增大）；应配实际命令如 cp "%p" /data/kingbase/backup/archive/"%f"，归档目录提前建好并属 kingbase。
  3. 备机备份要先升主再配置：备节点要加备份策略时，须在业务窗口 repmgr standby switchover 升主 → 配置 sys_backup → 再切回；否则切换后新主没有备份策略，容灾与备份同时失效。
  4. 逻辑备份（suptools）针对业务：suptools.ini 的 [connect] 指向本机（HOST=127.0.0.1、PORT=15433、USER=system）、[backup] 里 DB_LIST 填在用的库、KEEP_TIME=7 保留 7 份；fast_deploy_backup8.sh 生成首次备份与定时任务。工具来自单机安装实例的 SupTools 目录——这正是集群部署要保留单机实例的原因。
  5. crontab 权限：逻辑/物理备份的定时任务都依赖 kingbase 用户 crontab；报无权限时 root 在 /etc/cron.allow 添加 kingbase 即可。

常见误解 ​

  • ❌ "逻辑备份够了" → 逻辑备份（dump）只能恢复到 dump 时刻，且不含完整的崩溃一致性；物理备份 + WAL 归档才能恢复到任意时间点（PITR）。
  • ❌ "集群高可用了，备机不用单独备份" → 一主一备下备机不配备份策略，一旦主故障切换，新主无备份可用；且高可用本身防不了误删。
  • ❌ "archive_command 留空没影响" → 空命令 = 归档任务每段 WAL 都失败重试，日志刷屏且 WAL 在 pg_wal 堆积，最终拖垮主库写入并放大备库延迟。
  • ❌ "备份脚本只在主节点跑一遍就行" → 逻辑备份按需在主或备执行即可；物理备份若要在备机生效，必须按不变量 3 的升主流程做，不能直接照抄主节点配置。

关键证据 / 例子 ​

  • 现场部署文档实测：sys_backup.conf 用 _target_db_style="single" + _one_db_ip 驱动集群物理备份；_crond_full_days=7 / _crond_incr_days=1 / _crond_full_hour=2 / _crond_incr_hour=4 / _repo_retention_full_count=3（保留 3 周）。
  • 逻辑备份产物落 /data/kingbase/backup/dump，物理仓库落 /data/kingbase/backup/rman，与数据目录 /data/kingbase/data 分开——备份与数据不同盘，避免介质故障一锅端。
  • 踩坑记录：创建 postgis 扩展报 libssl.so.10: not found 时，修复（补 so 并建软链）后需重启集群再重建扩展（详见手册 FAQ #3）。

关联 ​

最近更新