技能介绍

你要解决的问题

数据库备份听起来简单——写个 crontab 定时 pg_dump 或 mongodump 就行。但当数据库规模增长到几十 GB 甚至 TB 级别，需要考虑的远不止"定时导出"：全量备份耗时太长、增量备份恢复链路容易出错、保留策略不合理导致存储爆炸、备份完从没验证过能否真正恢复……等到出事才发现备份文件是空的，代价往往无法挽回。

这个技能要解决的，就是把这些散落的决策点串成一套可执行的备份方案。

核心能力与关键步骤

技能支持 PostgreSQL、MySQL、MongoDB 三种主流数据库，覆盖全量、增量、差异和基于 WAL/oplog 的时间点恢复（PITR）四种备份类型。工作流程分为六个阶段：

评估需求：确认数据库类型、可接受的 RPO（恢复点目标）和 RTO（恢复时间目标），判断是否需要应用级锁定或快照来保证一致性。
选择策略：根据 RPO 要求选择备份类型。PITR 能把数据恢复到任意时刻，RPO 接近零，但依赖 WAL 归档或 oplog 的持续记录。
生成脚本：产出带压缩（gzip、lz4、zstd）、可选加密（GPG、AES-256）、时间戳命名和错误处理的 Shell 脚本，输出日志便于监控。
调度与保留：通过 cron 或 systemd timer 自动化执行，定义保留策略（如 7 份日备、4 份周备、12 份月备）并清理过期文件。
验证完整性：检查备份文件非空、校验和有效，定期在 staging 环境做恢复演练。
文档与监控：记录备份计划、存储位置和恢复步骤，对备份失败或缺失设置告警。

适用边界与注意点

超大数据库本地磁盘不够时，可以直接流式写入对象存储，例如 pg_dump | gzip | aws s3 cp - s3://bucket/backup.gz，避免本地磁盘被撑爆。
备份期间有活跃写入时，PostgreSQL 可用 --snapshot，MongoDB 可用 --oplog 获取一致性快照；MySQL 的 InnoDB 热备建议用 Percona XtraBackup，避免锁表。
如果数据库启用了 TDE（透明数据加密），密钥必须单独备份，否则恢复时无法解密。
从副本备份前要确认复制延迟接近零，否则备份出来的可能是过期数据。
凭据不要硬编码在脚本里，建议放在 Vault 或云厂商的 Secrets Manager 中，并支持轮换。

最后一点：备份的价值不在于"备份过"，而在于"恢复成功过"。这个技能把恢复验证纳入了工作流，但真正的信心来自定期的恢复演练。