做数据库这行当的，谁还没个翻车经历呢？我见过最惨的一个哥们儿，熬夜三天搭了个电商系统，上线第二天老板让他改个字段类型，他手一抖把整个表给 DROP 了。当时那哥们儿脸都绿了，嘴里念叨着“我靠，我靠”，手指在键盘上抖得跟筛糠似的。后来怎么着？还好他上周刚做了个 mysqldump 备份，从备份文件恢复回去，前后花了不到十分钟。老板还不知道这事儿，他自己偷偷擦了把冷汗。这事儿让我明白一个道理：数据库备份不是看你技术好不好，而是看你有没有把备份当回事儿。备份就像买保险，永远不知道哪天会用上，但真出事那天，你会感谢提前做好备份的自己。
说到备份，很多人第一反应就是 mysqldump，这玩意儿确实好用，但得看怎么用。我见过有人每天凌晨三点跑全量备份，把整个库导成 SQL 文件，结果数据库几百 GB，导出一次要两个小时，磁盘空间蹭蹭往上涨。更离谱的是，他把备份文件和数据库放在同一台服务器上。你说这不是给自己挖坑吗？万一硬盘挂了，数据库没了，备份文件也跟着没了，那就真叫“陪葬”。正确的做法是先把备份文件压缩，再用 rsync 或 scp 传到另一台机器上，有条件的话再搞个异地存储。别嫌麻烦，真出事那天你就会觉得这些折腾都值得。
还有一种常见的备份方式是物理备份，即用工具直接复制数据库的数据文件。比如 MySQL 的 XtraBackup，或者 PostgreSQL 的 pgbasebackup。这种做法的好处是恢复速度快，不用一条条执行 SQL 语句，直接把文件拷贝回去就行。缺点也很明显：必须保证数据库版本和操作系统完全一致，否则文件格式不兼容，恢复后会报错。我有个朋友就吃过这个亏，他把一个 5.7 版本的 MySQL 数据文件拷到 8.0 版本上，结果启动数据库直接挂了，日志里一堆乱码。后来他老老实实重新装了 5.7，才把数据救回来。所以备份不能只图省事，得想清楚自己的实际需求。
备份做完了，关键还得会恢复。我见过太多人，备份做得比谁都勤快，却从未演练过恢复。结果真出事时，手忙脚乱地找备份文件，结果脚本写错，恢复出来的数据全是乱的。更离谱的是，有人备份时只勾选了表结构，没勾选数据，恢复后表都在，数据全是空的，简直绝望。我的建议是每个月至少做一次恢复演练，找个测试环境，把备份文件完整恢复一遍，检查数据是否正确、恢复时间是否可接受。别等到火烧眉毛才想起演练，那时候连哭都找不到地方。
说到恢复，还得提一嘴增量备份和差异备份。很多人觉得全量备份太费时间，就只做增量备份，每天只备份变化的数据。这招确实省空间省时间，但恢复时必须先恢复全量备份，再依次恢复每天的增量，顺序不能乱，少一个文件都不行。我见过一个运维小哥，做了整整三个月的增量备份，结果恢复时发现第二周的增量文件损坏，后面的全白费。只能恢复到第一周的状态，丢了两个月多的数据，老板差点把他开了。所以增量备份虽香，但一定要保证每个文件完整，并且定期做一次全量备份，哪怕一个月一次也行。
还有一个容易被忽略的点，就是备份文件的命名和归档。我见过有人备份文件叫 “backup.sql”、 “backup2.sql”、 “backup3.sql”，一个月后自己都不知道哪个是最新的。更惨的是，有人把备份文件随手扔进一个文件夹，不压缩也不清理旧的，结果硬盘满了，新备份写不进去，旧的又被自动删了，两头都落不着好。我习惯把备份文件按日期和类型命名，例如 “20231115full.sql.gz”、 “20231116_inc.sql.gz”，再建立目录结构，按月份分类，超过三个月的自动压缩归档，超过一年直接删除。这样既不乱，也不会占用太多空间。
说个扎心的事儿。我认识一个做电商的朋友，他们的数据库有几十 TB，每天流水上千万。老板觉得备份太费钱，只做了一个简单的全量备份，一周一次，放在同一台服务器上。结果有一天，服务器被勒索病毒攻击，所有文件都被加密，包括备份文件。他们想从备份恢复，却发现文件根本打不开，只能找数据恢复公司，花了十几万，也只恢复了一半的数据，损失了几百万。你说这事儿赖谁？赖病毒？赖备份策略？还是赖老板舍不得花钱？要我说，备份成本再高也比不上数据丢失的代价。可以在备份上省钱，但别在恢复上省钱，因为恢复时失去的不止是数据，还有客户的信任，甚至整个生意。
所以，不管你用的是 MySQL、PostgreSQL 还是 Oracle，不管是每天做全量备份还是增量备份，记住一件事：备份不是做完就完了，你得定期检查、定期演练、定期清理。别等到数据丢了才想起备份的重要性，那时候只能对着空荡荡的数据库发呆，后悔当初为什么没多做一次备份。
