摘要：在数据库运维领域，很多团队存在一个普遍误区：部署三副本集群实现高可用，就不需要做数据库备份。多副本解决硬件故障，却无法抵御人为误删、程序 BUG 带来的逻辑损坏。本文以国产数据库 KaiwuDB 为例，拆解 WAL 容灾机制与 BACKUP 备份体系，区分时序、关系数据备份差异，提供企业生产可用的备份恢复方案。

一、副本≠备份，分清两套防护逻辑

高可用集群多副本，作用是节点宕机、硬件损坏的时候自动切换，保障业务持续运行。但是，当运维误执行 DROP TABLE，或者业务程序写入脏数据，这条变更会同步传播到集群所有副本，副本越多，数据销毁速度越快。

• 高可用：解决机器故障，关注 RPO/RTO业务连续性；
• 备份：解决逻辑错误、灾难事故，关注可以恢复到哪一个历史时间点。

行业广泛使用 3-2-1 备份原则：3 份数据副本，2 种不同存储介质，至少 1 份副本异地存放。集群内部副本只是第一份，异地独立备份是抵御火灾、机房断电等重大事故的最后防线。

基础概念普及：1. 全量备份：拷贝完整数据，恢复简单，占用存储、时间开销大；2. 增量备份：仅备份变更数据，资源开销小，恢复依赖备份链；3. PITR 时间点恢复：回退到故障发生前任意时间点，会带来额外存储成本。

二、KaiwuDB 双层数据保护体系

KaiwuDB 将数据保护分为容灾层、备份层，两套机制互补，不可替代。

容灾层：WAL 预写日志

WAL 预写日志是数据库经典的崩溃恢复机制：所有数据修改操作，先写日志到磁盘，再修改业务数据。当进程崩溃、服务器断电重启后，系统重放 WAL 日志，保证数据一致性。

KaiwuDB 针对时序数据，在 VGroup 虚拟组维度完成日志管理，后台定期执行 Checkpoint 检查点，把内存数据刷入磁盘。WAL 文件采用双文件轮转策略，执行检查点过程业务写入不会中断。

运维人员可以调整 WAL 持久化级别、检查点时间间隔，平衡数据安全性与性能。

⚠️ 风险提示：WAL 文件保存在本机数据目录，如果磁盘损坏、目录被误删除，WAL 直接丢失，WAL 只做单机崩溃恢复， 不能充当备份。

备份层：BACKUP & RESTORE

备份层才是真正意义的数据备份，应对人为误删、版本回退、灾难恢复、环境迁移。

关键能力差异：关系数据支持 PITR 时间点备份还原，备份时需要增加 WITH revision_history 参数；时序数据暂不支持时间点恢复。

时序、关系数据增量备份语法上存在明显差异：时序增量备份仅需要填写上一次备份路径；关系数据增量备份，必须完整列出全量以及所有历史备份路径，否则增量链断裂。关系数据增量还原不支持单表约束；执行还原之前，必须先删除目标数据表，表已存在会报错。

重要重点注意的功能限制

1. 备份还原不支持跨版本还原，同一个大版本内部小版本互相兼容；
2. 暂停备份或者还原任务，恢复执行前需要手动清理目标目录文件；
3. 备份不会包含权限、系统表、序列对象；
4. 时序增量备份无法捕获备份启动之后新写入的历史时间戳数据。

三、企业生产备份策略建议

结语

WAL 守护单机崩溃故障，多副本守护节点硬件故障，备份守护逻辑错误与重大灾难，三层防护缺一不可。KaiwuDB 的序号与关系存储备份能力存在区别，更多详情可前往官方文档-容灾及备份：
https://www.kaiwudb.com/docs/#/db-operation/backup-and-restore.html

企业版和开源版均支持备份还原能力，欢迎获取安装包体验： https://www.kaiwudb.com/download?tab=1