一次真实的事故：某知识库系统运行两个月后，数据库文件损坏，四十多条用户提问正文永久丢失。备份其实想过，只是一直排在「等稳定了再加」后面，而稳定从来不会主动到来。
一、每日备份，用对方法
SQLite 这类文件数据库不能直接复制文件，数据库正在写时拷出来的文件可能是坏的。要用数据库自己的备份接口，或者先做一致性快照。备份文件名带日期，保留 30 天；备份脚本自己也要有失败告警，否则备份静默失败和没备份是一回事。
二、行数哨兵
备份只能救「丢了」，救不了「悄悄变少」。哨兵每天数一遍关键表的行数，和上一次比：腰斩就报警，慢性下降也报警。表不见了不算「跳过」，算最高级别告警，丢得越彻底越不能安静。
三、异地副本
备份和生产在同一台机器上，机器没了就一起没了。每天把最新备份推到另一台服务器或对象存储，多花几分钱，换的是「服务器被删了也能恢复到昨天」。
顺手配齐的
- 报警要能到人：企业微信或飞书群，@ 负责人，不是写进日志里等人看。
- 脚本报错必须退出非零，否则定时任务永远显示「成功」。
- 上线后一周内，真的从备份恢复一次，恢复不出来的备份等于没有。
这些加起来不到半天工作量，但它决定了系统出事时是「恢复到昨天」还是「从头再来」。