KES 数据保护体系构建：备份策略设计、恢复流程优化与时间点恢复实践
前言
数据备份恢复是数据库运维的核心工作，很多DBA最担心的就是数据丢失或者恢复失败。毕竟，业务系统中的数据是核心资产，一旦丢失，不仅影响业务，还要承担不小的责任。
去年完成的一个数据恢复项目，让我对KingbaseES的备份恢复能力有了全新的认识。整个恢复过程中，从三天前的备份恢复到误操作之前的数据，只用了2个小时，数据完整性100%。物理备份、逻辑备份、PITR等核心功能，KES都提供了完整的支持。
这篇文章，我想把自己在备份恢复项目中使用KES的经验分享给大家，重点讲解KES如何通过物理备份、逻辑备份、PITR等功能，实现数据的安全保障。希望能给正在做备份策略或者数据恢复的朋友一些参考。
一、物理备份详解
物理备份是KES备份恢复的基础，能完整备份数据库文件，恢复速度快。KES提供了多种物理备份工具，满足不同场景需求。
基础备份实现
sys_basebackup是KES最常用的物理备份工具，能进行全量备份和增量备份。
# 使用sys_basebackup进行全量备份
sys_basebackup -D /backup/kessdata -h 127.0.0.1 -p 54321 -U system -F t -z -Xs -P
# 参数说明：
# -D：备份目录
# -h：数据库主机
# -p：数据库端口
# -U：数据库用户
# -F：备份格式（t=tar）
# -z：压缩备份
# -X：WAL日志处理方式（s=流式）
# -P：显示进度
# 备份完成后的文件结构
# /backup/kessdata/
# ├── base.tar.gz # 数据文件
# └── pg_wal.tar.gz # WAL日志
# 备份大小和压缩率
ls -lh /backup/kessdata/
# base.tar.gz: 50GB (压缩前100GB，压缩率50%)
# pg_wal.tar.gz: 2GB
增量备份实现
增量备份只备份自上次备份以来变化的数据，能节省存储空间和备份时间。
# 启用WAL归档
echo "archive_mode = on" >> $KESDATA/kingbase.conf
echo "archive_command = 'test ! -f /backup/wal_archive/%f && cp %p /backup/wal_archive/%f'" >> $KESDATA/kingbase.conf
sys_ctl restart -D $KESDATA
# 全量备份（基础备份）
sys_basebackup -D /backup/base_20260101 -h 127.0.0.1 -p 54321 -U system -F t -z -Xs -P
# 增量备份（每天执行）
# 增量备份只需要备份WAL日志
tar -czf /backup/incremental_20260102.tar.gz /backup/wal_archive/
# 备份策略
# 周日：全量备份
# 周一到周六：增量备份
# 保留最近7天的备份
二、逻辑备份详解
逻辑备份是KES备份恢复的重要补充，能导出SQL语句，便于迁移和恢复。KES提供了sys_dump和sys_dumpall两个逻辑备份工具。
sys_dump工具
sys_dump是KES最常用的逻辑备份工具，能导出表结构、数据、视图等。
# 导出整个数据库
sys_dump -h 127.0.0.1 -p 54321 -U system -d dbname -F c -f /backup/dbname_backup.dump
# 参数说明：
# -h：数据库主机
# -p：数据库端口
# -U：数据库用户
# -d：数据库名
# -F：备份格式（c=custom）
# -f：备份文件
# 导出指定表
sys_dump -h 127.0.0.1 -p 54321 -U system -d dbname -t orders -t users -F c -f /backup/tables_backup.dump
# 导出表结构（不含数据）
sys_dump -h 127.0.0.1 -p 54321 -U system -d dbname --schema-only -f /backup/schema_backup.sql
# 导出数据（不含表结构）
sys_dump -h 127.0.0.1 -p 54321 -U system -d dbname --data-only -F c -f /backup/data_backup.dump
sys_dumpall工具
sys_dumpall能导出所有数据库，包括全局对象（角色、表空间等）。
# 导出所有数据库
sys_dumpall -h 127.0.0.1 -p 54321 -U system -f /backup/all_databases_backup.sql
# 只导出全局对象（角色、表空间）
sys_dumpall -h 127.0.0.1 -p 54321 -U system --globals-only -f /backup/globals_backup.sql
# 只导出角色
sys_dumpall -h 127.0.0.1 -p 54321 -U system --roles-only -f /backup/roles_backup.sql
# 只导出表空间
sys_dumpall -h 127.0.0.1 -p 54321 -U system --tablespaces-only -f /backup/tablespaces_backup.sql
三、恢复策略
恢复是备份的最终目的，掌握恢复策略能让数据安全有保障。KES支持物理恢复和逻辑恢复两种方式。
物理恢复
物理恢复是使用物理备份文件恢复数据库，恢复速度快，适合大数据量场景。
# 停止数据库
sys_ctl stop -D $KESDATA
# 备份当前数据目录（可选）
mv $KESDATA $KESDATA_old
# 解压备份文件
mkdir $KESDATA
tar -xzf /backup/kessdata/base.tar.gz -C $KESDATA
tar -xzf /backup/kessdata/pg_wal.tar.gz -C $KESDATA/pg_wal
# 恢复WAL日志（如果需要）
cp -r /backup/wal_archive/* $KESDATA/pg_wal/
# 创建恢复配置文件
cat > $KESDATA/recovery.signal << EOF
restore_command = 'cp /backup/wal_archive/%f %p'
recovery_target_time = '2026-01-01 12:00:00'
EOF
# 启动数据库
sys_ctl start -D $KESDATA
# 验证恢复结果
psql -h 127.0.0.1 -p 54321 -U system -d dbname -c "SELECT COUNT(*) FROM orders;"
逻辑恢复
逻辑恢复是使用逻辑备份文件恢复数据库，恢复灵活，适合部分数据恢复。
# 创建数据库（如果需要）
createdb -h 127.0.0.1 -p 54321 -U system dbname
# 恢复整个数据库
sys_restore -h 127.0.0.1 -p 54321 -U system -d dbname /backup/dbname_backup.dump
# 恢复指定表
sys_restore -h 127.0.0.1 -p 54321 -U system -d dbname -t orders -t users /backup/tables_backup.dump
# 只恢复表结构
sys_restore -h 127.0.0.1 -p 54321 -U system -d dbname --schema-only /backup/dbname_backup.dump
# 只恢复数据
sys_restore -h 127.0.0.1 -p 54321 -U system -d dbname --data-only /backup/dbname_backup.dump
# 验证恢复结果
psql -h 127.0.0.1 -p 54321 -U system -d dbname -c "SELECT COUNT(*) FROM orders;"
四、PITR（Point-In-Time Recovery）
PITR是KES的高级恢复功能，能将数据库恢复到任意时间点。掌握PITR，能让数据安全更有保障。
PITR配置
PITR需要启用WAL归档，并配置恢复目标时间点。
# 启用WAL归档
echo "archive_mode = on" >> $KESDATA/kingbase.conf
echo "archive_command = 'test ! -f /backup/wal_archive/%f && cp %p /backup/wal_archive/%f'" >> $KESDATA/kingbase.conf
sys_ctl restart -D $KESDATA
# 验证WAL归档
ls /backup/wal_archive/
# 应该能看到WAL日志文件
# 配置恢复目标
cat > $KESDATA/recovery.signal << EOF
restore_command = 'cp /backup/wal_archive/%f %p'
recovery_target_time = '2026-01-01 12:00:00'
recovery_target_inclusive = true
EOF
PITR恢复
PITR恢复能将数据库恢复到任意时间点，适合误操作恢复。
# 停止数据库
sys_ctl stop -D $KESDATA
# 备份当前数据目录（可选）
mv $KESDATA $KESDATA_old
# 解压基础备份
mkdir $KESDATA
tar -xzf /backup/base_20260101/base.tar.gz -C $KESDATA
# 配置恢复目标（恢复到误操作之前）
cat > $KESDATA/recovery.signal << EOF
restore_command = 'cp /backup/wal_archive/%f %p'
recovery_target_time = '2026-01-01 09:59:00'
recovery_target_inclusive = true
EOF
# 启动数据库（自动恢复）
sys_ctl start -D $KESDATA
# 验证恢复结果
psql -h 127.0.0.1 -p 54321 -U system -d dbname -c "SELECT COUNT(*) FROM orders;"
# 完成恢复后，删除恢复配置文件
rm $KESDATA/recovery.signal
五、实战案例
去年完成的一个数据恢复项目，很好地验证了KES备份恢复能力的价值。
项目背景
一个电商平台的订单系统，数据量5000万+。用户反馈误删了订单数据，需要恢复。
恢复过程
使用KES的PITR功能，将数据库恢复到误操作之前。整个过程只用了2个小时，数据完整性100%。
# 恢复项目数据
# 数据量：5000万+
# 误操作时间：2026-01-01 10:00
# 恢复目标时间：2026-01-01 09:59
# 恢复时间：2小时
# 数据完整性：100%
# 用户满意度：显著提升
恢复效果
恢复后，订单数据成功恢复，业务正常。客户反馈，KES的备份恢复能力让他们对数据安全有了更强的信心。
总结与展望
通过实际项目的应用，KES在备份恢复方面确实有自己的优势。物理备份、逻辑备份、PITR，这些功能都很实用。特别是对于数据安全要求高的场景，备份恢复后的数据完整性非常明显。
对于正在做备份恢复的企业来说，KES是一个值得考虑的选择。它能够提供完整的备份恢复方案，帮助DBA快速定位和解决数据问题。
当然，每个项目的具体情况都不一样，恢复方案也要结合实际情况来制定。但从实际经验来看，KES的备份恢复能力是比较可靠的，值得信任。
如果你也在做备份恢复，欢迎交流讨论，分享经验。
