干了十几年数据库运维，见过太多人备份时不上心，恢复时哭都来不及。有次半夜三点接到电话，某电商平台数据库崩了，备份文件竟然因为磁盘满了根本没写进去。那哥们儿在电话那头声音都在抖，双十一的数据全在里面。这事儿让我一直惦记着，今天把这些年积累的备份恢复经验挑三招最管用的，跟大伙儿聊聊。
第一招，别只盯着全量备份。很多人觉得每天凌晨跑个全量备份就万事大吉，这想法太天真。全量备份就像把整栋楼拍照，一天一张，真要恢复时得从第一天开始一张张往回翻。更靠谱的做法是增量备份加差异备份的组合拳。增量备份只记录上次备份以来变化的数据，差异备份则记录上次全量备份以来的所有变化。打个比方，你每天写日记，全量备份就是复印整本日记，增量备份只记今天新写的那一页，差异备份则把从周一到今天的所有页数都复印一遍。这样组合下来，恢复速度能快上三四倍，关键是占用的存储空间也少得多。
第二招，恢复演练比备份本身更重要。我见过太多公司，备份脚本写得漂漂亮亮，真要恢复时才发现各种问题。数据库版本对不上、文件权限不对、恢复路径写错，这些坑我全踩过。最离谱的是有一次，某金融公司号称每天做全量备份，结果恢复时发现备份文件是加密的，而加密密钥早就过期了。所以每个月至少要做一次完整的恢复演练，找个测试环境，把备份文件真实地恢复一遍，然后跑几个核心业务查询，确认数据完整性和业务逻辑都没问题。这个流程走一遍，比看十遍文档都实用。
第三招，异地备份是救命稻草。本地备份遇到火灾、洪水、机房断电，照样白搭。我有个客户，公司服务器在同一个机房，主库和备库都在一台物理机上，结果硬盘坏了，两个库一起完蛋。异地备份不一定要搞高大上的异地机房，成本低的方案很多。比如用云存储的异地冗余功能，或者每周把备份文件用加密U盘带到另一个城市的办公室。关键是要保证两地的网络延迟和带宽能支撑恢复时间要求。金融行业通常要求 RPO（恢复点目标）在 15 分钟以内，RTO（恢复时间目标）在 1 小时以内，普通企业可以放宽到 4 小时。这个指标得根据业务重要性来定，别一刀切。
说到具体操作，MySQL 和 PostgreSQL 的备份恢复思路其实差不多。MySQL 用 mysqldump 做逻辑备份，搭配 binlog 做增量恢复；PostgreSQL 用 pg_dump 加 WAL 日志。但不管用哪个工具，有几个原则必须记住：备份文件要定期校验 MD5，防止传输过程中损坏；备份策略要跟业务团队对齐，确认哪些表是核心数据，哪些可以容忍丢失几小时；备份窗口要避开业务高峰期，别因为备份把数据库卡死。我见过最蠢的案例，某公司把全量备份定在中午十二点，结果每次备份都把数据库 CPU 打满，业务直接瘫痪半小时。
还有一个容易被忽略的细节：备份文件的命名和归档。很多人喜欢用 “backup-2024-01-01.sql” 这种名字，但真到恢复时，光文件名看不出是哪个库、哪个表、增量还是全量。我习惯用这种格式：“项目名-数据库类型-备份类型-日期-备份范围”。比如 “shop-mysql-full-2024-01-01-all.sql”，一目了然。归档策略也要想清楚：全量备份保留三个月，增量保留两周，关键业务数据保留一年以上。别舍不得删旧备份，存储成本也是钱，而且备份文件太多，恢复时找起来也费劲。
说说自动化监控。备份恢复这事儿，光靠人工盯着不现实。我一般会写个监控脚本，每天检查备份文件的大小、生成时间、MD5 值，如果有异常就自动发短信报警。恢复时也要有自动化脚本，把恢复步骤封装好，一键执行。这样真遇到灾难，不用翻文档找命令，直接跑脚本就行。记得有一次，某客户的数据库因为误操作被删了十几张表，我远程连上去，跑了恢复脚本，十五分钟就把数据全找回来了。客户在电话里说：“你们这效率也太高了。”我心里想，哪是什么效率高，不过是之前踩的坑多了，把能想到的问题都提前解决了。
备份恢复这事儿，说难不难，说简单也不简单。关键是要把流程跑通、跑熟，别等到出事了才想起翻文档。这三招看着简单，但能坚持做下来的团队真不多。下次真要遇到数据灾难，记住，备份不是目的，恢复才是。
