干运维这行十年，我见过太多人栽在备份上。平时系统跑得好好的，没人记得备份这回事，真到数据库崩了、硬盘坏了、机房着火了，才手忙脚乱去翻备份策略，结果发现要么没配、要么配了没验证、要么验证了但恢复不了。说白了，备份不是买保险，是给自己留后路，但这后路得实打实能走通才行。
先聊备份方式，别一听全量备份就觉得万事大吉。全量备份是底子，但光有底子不够，你得搭配增量备份和差异备份。全量是把整个数据库打包，占用空间大、耗时久，不可能天天做。增量备份只存上次备份以来变化的数据，快，但恢复时要按顺序从全量到最近一个增量依次叠加，少一个文件就前功尽弃。差异备份折中，它存的是上次全量备份以来的所有变化，恢复时只要全量加一次差异就行，省事但文件会越滚越大。选哪种组合，得看你的数据量、业务容忍度和恢复时间目标，没有万能答案。
接着说备份频率，这是最容易拍脑袋定的地方。有人一周做一次全量，觉得够了，结果周三中午数据丢了，一恢复回到周一凌晨，两天的工作白干。有人干脆每小时跑一次增量，数据安全是安全了，但备份对生产库的IO压力也是实打实的，高峰期跑备份能把业务拖垮。我的建议是，先跟业务方谈清楚两个数字：RPO和RTO。RPO是你能容忍丢多少数据，RTO是你能容忍停多久服务。这俩数字定了，备份频率和策略自然就出来了，别自己闷头拍板。
再往下是备份存储，很多人忽略这个环节。备份文件跟数据库放在同一台机器上，等于把鸡蛋全放一个篮子，磁盘坏了全完蛋。备份要遵循3-2-1原则：三份副本，两种不同存储介质，一份异地存放。本地磁盘放一份，方便快速恢复；对象存储或磁带库放一份，防物理损坏；异地机房或云上放一份，防火灾地震。而且备份文件要加密，尤其涉及用户隐私数据，明文备份文件泄露出去比数据库被黑还可怕。
备份这块还有个隐形坑，就是没人定期验证备份文件能不能用。我见过最离谱的案例，某公司每天自动备份，备份日志全是成功，结果真到恢复那天，发现备份文件因为权限问题根本读不出来，或者数据库版本升级后旧备份文件不兼容。所以备份完一定要做恢复演练，至少每个季度抽一次，找个测试环境把备份恢复一遍，确认数据完整、服务能起来。别嫌麻烦，恢复不通的备份等于没有备份。
说到恢复，这里头的门道比备份还多。恢复不是简单把备份文件导回去，你得先想清楚恢复粒度。是整库恢复，还是表级别恢复，还是按时间点恢复到某个事务之前？整库恢复最简单，但耗时长，业务停摆久。表级别恢复快，但要求备份时用了表空间或逻辑备份工具。按时间点恢复最精细，适合误删数据的情况，但需要在做全量备份时开启归档日志或binlog，还得保证日志连续不断。这些细节，平时不研究，真出事时手忙脚乱。
再讲一个实战中容易翻车的点：恢复的顺序和依赖关系。如果你有主从复制，恢复主库之后，从库不能直接挂上去，得先把从库的binlog位置和主库对齐，否则数据一同步就乱套。如果业务涉及多张表的外键约束，恢复时得先恢复主表再恢复从表，顺序反了直接报错。还有字符集、时区、存储引擎这些参数，备份时的环境跟恢复时不一致，数据导进去就变成乱码或时间错位。所以恢复操作前，先看备份时的配置文件，把环境对齐再说。
一个关键步骤，是建立完整的备份和恢复文档。这听起来像废话，但真到了灾难现场，人都是慌的，脑子一片空白，全靠文档兜底。文档里要写清楚：备份脚本放在哪，怎么手动触发，备份文件命名规则，恢复步骤分几步，每一步该执行什么命令，常见报错怎么处理。这份文档要放在团队共享的地方，别存在某个人电脑里，万一这个人离职了或联系不上，整个团队就抓瞎了。
数据库备份和恢复这件事，说到底是反人性的。平时它不产生价值，看不出效果，还占存储、占带宽、占人力，所以很容易被边缘化。但一旦出事，它就是你的救命稻草。别等数据丢了才想起来验证备份，别等业务停了才去翻恢复文档。从今天开始，检查一下你的备份策略，跑一次恢复演练，把文档补全，这比写多少代码都值钱。备份是手段，恢复才是目的，能把数据完整找回来，这套流程才算真正闭环。
