刚接手一个系统的时候，我最先问的不是业务逻辑，而是备份策略。原因很简单，数据这玩意儿，平时安安静静躺在硬盘里，一旦出事，就是天塌下来那种事。SQL数据库的备份和恢复，听起来像是DBA的活儿，但凡是碰过数据库的开发者、运维，甚至产品经理，都该心里有数——备份不是“要不要做”的问题，而是“怎么做才不会在恢复时抓瞎”的问题。今天不聊高深的原理，就说说那些容易被忽略、但真到关键时刻能救命的步骤。
先说备份类型。很多人以为备份就是“咔”一下把数据库文件复制走，其实分两种：物理备份和逻辑备份。物理备份直接拷贝数据文件、日志文件，速度快，恢复也快，但要求数据库版本、文件路径完全一致，跨平台迁移时容易出幺蛾子。逻辑备份则是用工具导出SQL语句或特定格式的数据，比如MySQL的mysqldump、SQL Server的BCP，好处是灵活，能在不同版本间迁移，但数据量大时导出慢、恢复更慢。我见过有人图省事只用逻辑备份，结果数据库几个TB，恢复一次要一整天，业务早就崩了。所以成熟的做法是两者搭配：物理备份保底，逻辑备份做灵活性补充。
接下来是备份频率和保留策略。这问题看着简单，实际操作里全是坑。有人设置每天凌晨全量备份，觉得万事大吉，结果某天中午数据库被误删了，恢复出来是昨晚的数据，丢了整整半天的业务记录。增量备份和差异备份这时候就该上场了。简单说，全量备份是完整快照，增量备份只保存从上一次备份以来的变化，差异备份保存从上一次全量备份以来的变化。恢复时，全量加增量或差异的组合，能把数据损失窗口缩到分钟级。但别贪多，备份文件太多，存储成本上去了，恢复时找哪个文件也费劲。我的习惯是：全量每周一次，增量每天一次，保留最近四周的全量和对应增量，再留一份每月的归档，这样既不浪费空间，又能应对绝大多数场景。
备份文件存哪儿，也是个容易被轻视的环节。有人把备份和数据库放在同一台机器的同一块硬盘上，美其名曰“方便管理”。真出了硬盘故障，或者机房断电导致磁盘损坏，备份和主数据一起完蛋，那才是叫天天不应。正确做法是至少存两份，一份本地，一份异地，或者丢到对象存储上。本地放一份，是为了恢复快；异地或者云上放一份，是为了防自然灾害、机房级故障。我见过一个真实案例，某公司数据库所在服务器被勒索病毒加密，备份文件因为是挂载在同一台机器上的网络硬盘，也被一并加密了，只能交赎金。要是当初把备份丢到对象存储，设个版本管理，哪至于这么被动。
备份做完，很多人以为就完事了，其实验证备份才是真正的大头。我接触过的团队里，十个有八个没做过恢复演练，觉得“反正备份在那呢”。可备份文件能不能用、恢复流程对不对，不演练永远不知道。有一回，我帮一个客户排查问题，他们信誓旦旦说每天晚上都做备份，结果一检查，备份任务早就因为权限变更悄悄失败了，日志里堆满了错误，但没人看。更离谱的是，有次他们真出了故障去恢复，发现备份文件是好的，但恢复工具版本不对，硬是折腾了十几个小时。所以，每个月至少做一次恢复测试，选一个测试库，把最新备份恢复到一台干净环境里，确认数据完整、业务能跑通，这才叫真正的“备份可用”。别嫌麻烦，这比任何监控告警都实在。
恢复流程里，有个细节特别容易翻车：日志备份和时点恢复。很多人以为有了全量和增量就能恢复到任意时刻，其实不然。SQL Server的日志备份能实现秒级恢复，但前提是你得在两次备份之间频繁做日志备份，否则只能恢复到最近一次备份的时间点。MySQL的binlog也是同理，不开启binlog，就算有全量备份，也只能恢复到备份时刻，中间的数据全丢。我见过一个电商项目，数据库在晚上10点被批量误删，他们只有凌晨2点的全量备份，结果恢复出来是凌晨的数据，白天一整天的订单全没了，只能靠业务日志手工补录，累得够呛。所以，如果你对数据实时性要求高，日志备份这个环节千万不能省。
恢复操作本身也有讲究。最忌讳的是在生产库上直接恢复，万一恢复脚本有问题，把原有数据搞乱了，那就是二次事故。正确的姿势是：先找一台独立机器或实例，把备份恢复到那里，验证无误后，再考虑是否切流或者合并。另外，恢复前要确认目标库的磁盘空间、字符集、排序规则是否匹配，不然恢复失败还好说，恢复成功但数据乱码，那才是欲哭无泪。我还遇到过有人恢复时忘了改恢复模式，结果数据库变成只读，业务直接停摆。这些细节，说多了都是泪，但都是实打实的教训。
还有一点，备份和恢复的文档化。别笑，真的很多人不做。DBA可能心里有数，但换个人来操作，或者DBA休假了，出事儿时大家对着屏幕发呆，就尴尬了。文档里至少要有：备份脚本或工具命令、备份存放位置和命名规则、恢复步骤的详细清单、验证数据完整性的方法、负责人和联系方式。这份文档不是写给领导看的，是写给深夜被电话叫醒的倒霉蛋看的。我见过一份写得好的恢复手册，连“恢复后要执行哪些SQL检查关键表”都列得清清楚楚，照着操作，半小时就能搞定。相比之下，那些“备份在服务器上，自己找”的文档，简直是在害人。
说一句掏心窝子的。备份恢复这件事，做得好，没人夸你，因为系统没出事；做不好，出了事，你就是那个被追责的人。但反过来想，真到了救命时刻，你手里有一套靠谱的备份和清晰的恢复流程，那种笃定感，是任何技术大牛的虚名都比不上的。SQL数据库的备份与恢复，不复杂，但每一步都不能省，不能赌。数据在，业务就在；数据没了，一切归零。所以，别等出了事才想起这些关键步骤，现在就去检查一下你的备份任务、存储位置、恢复脚本，趁一切还来得及。
