数据库时点恢复(PITR)：用日志链救回误删的那一行
导语：全量+增量能回到"昨天"，时点恢复能回到"下午两点零三分"。
一、为什么要关注（背景与痛点）
本系列前文讲过的数据库三种备份方式。但真实灾难常是"下午两点有人误删了一张表的一批行"，全量只能回到昨晚，增量最多到今早，中间几小时的数据全丢。要救回那一行，靠的是日志链上的任意时间点恢复（PITR）。
二、核心原理 / 关键概念
- PITR（Point-in-Time Recovery）：基于"全量基底+连续事务日志"，把库前滚到指定秒。
- 日志链（Log Chain）：日志必须连续，中间断一段，链后全部失效。
- 恢复目标时间（RTI）：选定事故前最后一刻，跳过故障事务。
- 一致性基底：PITR起点是全量或差异，日志负责补齐后续。
- 价值：RPO从"天/小时"压到"分钟/秒"，误删、错改、逻辑坏数据都可回退。
三、落地做法 / 操作步骤
- 开启数据库归档/日志模式，保证日志连续落盘。
- 定期全量作基底，日志按RPO频度备份（如每15分钟）。
- 恢复时先还原基底，再指定目标时间前滚日志。 示例（通用逻辑）：
restore full.bak
restore log recent.log with stopat '2026-08-14 14:02:00'
- 演练：故意误删一行，用PITR精确救回。 检查清单：
- 日志模式已开且连续
- 基底+日志恢复链已验证
- 目标时间点选取规则已定
- 误删场景PITR已演练
四、与群晖NAS / 信创云盘的对应能力
群晖NAS的Active Backup for Business可按应用一致性备份数据库，Hyper Backup把全量与日志传输到本地/异地并保留多版本；信创云盘可集中收口日志归档。关键在于保证"日志链连续+基底可恢复"，行业通用数据库备份工具均支持PITR，落地时核对"日志备份频率是否满足RPO、链是否可连续前滚"。
五、常见误区 / 避坑提醒
- 误区一：只备全量不备日志，RPO回到一天。
- 误区二：日志链断点未发现，恢复时才知无效。
- 误区三：PITR前滚过界，把故障事务一起应用。
六、小结与行动建议
全量打底、日志续命、PITR精准。行动：为生产库开启连续日志备份，本月做一次"误删一行→PITR救回"的演练。