见过一次挺典型的事故：客户每天定时备份数据库，文件都在，硬盘也够。真出事要恢复，发现备份脚本两年前就失败了，因为改过一次密码，脚本里还是旧的。文件大小一直没变，没人看过。
一、备份不等于能恢复
备份和恢复是两件事，中间隔着一次验证。行业里有个说法叫没验证过的备份等于没有备份，我觉得挺准确。最低要求是定期把备份恢复到一台测试机上，跑一遍核心查询，看数据对不对、表全不全。这一步花不了多少时间。
二、只备数据不备结构，恢复就缺胳膊
有的方案只导数据，不导表结构和索引。恢复出来数据都在，但表是空的壳，或者索引没建，查询慢得没法用。正确的做法是用整库逻辑备份或者物理备份，结构和数据一起走，恢复时一步到位，不用再手工补建。
三、时间点和依赖，最容易翻车
备份频率要跟业务对得上。订单系统只做每天一次全备，中午出问题就要丢半天数据，通常不可接受，得配合增量或日志备份做到分钟级。保留策略也要定：留几天、留几份、异地存一份，写在文档里，出事时才不慌。
还有权限和依赖这两件事。恢复不只是数据库的事，还要有账号权限、要装对应版本的服务端、要有足够的磁盘空间。有客户恢复时才发现测试机磁盘不够，只能先扩盘。这些在演练时都会暴露，所以演练越早做越省事。
我们给客户的清单就六条：备份任务每天有成功回执；每周恢复一次到测试环境并核对关键表行数；备份文件异地存一份；恢复所需的账号、版本、磁盘空间记录在文档里；备份失败要有告警；每季度做一次完整演练并记录耗时。六条做到，事故率能降一个量级。
数据备份的常见疑问
备份多久做一次合适
看业务容忍度。订单类通常要能做到分钟级恢复，配合增量或日志备份；内部系统每天一次可接受。
怎么验证备份能用
定期恢复到测试环境，核对关键表的行数和几条具体记录，能查出来就说明可用。
备份要存几份
至少一份异地。同一块盘或同一个机房的两份，遇到硬件或机房故障会一起丢。
总结：没验证过的备份等于没有备份。定期恢复演练、结构数据一起备、异地留一份、失败有告警，六条做到事故率大降。