上周，我一个做电商的朋友打电话过来，声音都变了。他说公司运维不小心把线上数据库删了，整整两年的订单数据、用户信息、商品库存全没了。电话那头他反复念叨一句话：“完了，完了。”
我问他备份呢？他说有，但也是两个月前的，这两月的交易记录、客户资料、物流单号全得手动补。更麻烦的是，财务那边已经对不上账，有几笔大额退款根本找不到原始订单。他当时快哭了，担心处理不好公司会关门。
我知道很多人看到这里会笑：谁让你们不做好备份？但说实话，干过这行的都明白，数据库被删这事儿，光靠“做好备份”四个字是解决不了的。我见过太多公司，备份策略看起来很漂亮，却在恢复时出现备份文件损坏、恢复流程卡住、恢复数据与线上不匹配等问题。这行当里有句话：备份不等于恢复。备份做好，只是第一步。
数据库被删的常见原因我大致能列出十几种。最蠢的是手滑，比如在命令行里敲了 DROP TABLE，结果敲错了库名。还有程序 bug，比如某个 SQL 注入没处理好，或者定时任务出错，直接把整张表清空。再者是勒索病毒，近来特别多，很多公司连像样的防火墙都没有，数据库暴露在公网，黑客进来一键全删，留下勒索信。更离谱的情况还有机房断电导致磁盘损坏，或运维人员误操作把数据目录删掉。
每一种情况的恢复路径都不一样。手滑的话，如果数据库开启了 binlog（二进制日志），还能通过解析 binlog 把数据找回来，但前提是保留了从最近一次备份到误操作之间的所有 binlog。很多公司只保留最近几天的 binlog，结果一查发现需要的日志已经被自动清理。勒索病毒更麻烦，黑客通常先加密再删除，即使有备份，也得先确认备份是否同样被加密。曾有客户的备份文件和数据库在同一台服务器上，黑客进来连备份一起加密，恢复无望。
再说说备份这事儿。很多人觉得每天全量备份一次就万事大吉，但全量备份有致命缺点：恢复时间太长。假设数据库有 500 GB，全量备份恢复至少要两三个小时，再加上 binlog 的增量恢复，总时长可能超过四五个小时。对电商、金融等业务来说，停机四五个小时的损失可能上百万。而且全量备份只备份数据本身，不包括配置、权限、存储过程等元数据。数据恢复后，还得手动重建用户权限、重新设置 binlog 格式、重新配置主从复制，每一步都可能出错。
更实用的方案是“全量+增量”结合。比如每周做一次全量备份，每天做一次增量备份，每 6 小时做一次 binlog 备份。恢复时，先用全量备份恢复到某个时间点，再用增量备份和 binlog 追溯到误操作前的状态。但这里有个细节：必须记录好每个备份的时间戳和 binlog 的 position（位置），否则恢复时根本不知道从哪儿开始。我见过一个运维小哥，他把 binlog position 手动写在 Excel 里，结果 Excel 损坏，恢复只能靠猜。
还有一个容易被忽视的点：恢复测试。很多公司备份做了几年，却从未真正恢复过。等到出事时，才发现备份文件格式不对、恢复脚本有 bug，或者目标服务器磁盘空间不足。举个真实案例：某公司每天把备份上传到云存储，恢复时发现下载速度只有 10 MB/s， 500 GB 的备份文件耗时整整 14 小时。更离谱的是，下载完才发现备份是加密的，解密密钥在另一个部门的管理员手里，而该管理员正好在休假。所以备份恢复必须定期演练，就像消防演习一样，不演练永远不知道会卡在哪。
说到工具，市面上有很多选择。MySQL 的官方工具 mysqldump 和 xtrabackup 最常用，前者适合小数据量，后者适合大数据量。mysqldump 恢复时会锁表，生产环境要慎用。xtrabackup 支持热备份，不锁表，但恢复时需要先恢复到临时目录，再拷贝回数据目录，步骤稍微复杂。PostgreSQL 有 pgdump 和 pgbasebackup，前者恢复慢，后者更适合大库。还有商业工具，如 Oracle 的 RMAN，功能强大但价格不菲，小公司用不起。开源社区也有好东西，比如 Percona 的 PMM，能帮你监控备份状态，只是配置需要一定技术基础。
我的经验是，无论用什么工具，都要做好三件事：第一，备份文件和源数据要分开存储，最好一个放本地，一个放云端，再加一个异地。第二，备份文件命名要有规律，例如 “数据库名备份时间备份类型”，方便快速检索。第三，必须保留备份日志，记录每次备份是否成功、耗时、文件大小等信息。平时看似无用，关键时刻能救命。比如发现某次备份文件大小只有正常值的一半，就说明备份过程中出现了问题，必须立刻检查。
很多人以为数据库被删了就完了，其实还有一线生机。比如你有从库（Slave），从库上可能还保留着被删前的数据。或者你有快照（Snapshot），云服务商提供的磁盘快照可以直接回滚到某个时间点。还有一种冷门办法：如果数据库文件没有被覆盖，可以尝试用文件恢复工具扫描磁盘，成功率很低，而且数据库文件通常是大文件、碎片化严重，恢复出来的往往是乱码。最靠谱的仍然是备份，没有之一。
说到底，数据库恢复这事儿，技术占三成，管理占七成。很多公司出事，不是技术不行，而是没有备份策略、没有恢复流程、没有定期演练。老板觉得 IT 部门花钱不赚钱，压缩运维预算；运维觉得备份是苦活，能省则省；业务部门觉得数据丢了是 IT 的事，跟自己无关。结果大家都在赌：赌数据库不会出事。但数据库和人一样，迟早会出问题。赌赢了省了一笔备份费用，赌输了公司可能关门。
所以我的建议很简单：别赌。该花的钱就花，该做的备份就做，该演练的流程就演练。如果觉得备份太贵，就想想你的数据库值多少钱。一个电商公司的数据库可能价值几千万、甚至上亿元，花几万块做备份值得吗？如果觉得恢复太麻烦，就想想你的客户、财务、老板会怎么看你。数据库恢复不是技术问题，而是态度问题。你重视它，它就不会坑你；你忽视它，它迟早会给你上一课。
