说个真事，前阵子公司一小伙跑脚本，把测试库的表清了这本来也没啥，结果他改的是生产环境。凌晨两点全组人爬起来翻备份，发现备份任务上周就挂了，没人看告警邮件。那一晚上我把这辈子会的脏话都复习了一遍。

我的教训就一条：任何带delete和drop的脚本，先拿echo跑一遍，眼过一遍再执行。别嫌土，土办法救命。还有备份这东西，不是设了任务就万事大吉，得定期真去恢复一次，不然你以为的备份，可能只是一堆躺在角落的压缩包。

说真的，程序员的成熟不是写出多牛的架构，是知道哪些操作会让你半夜被电话叫醒。你们有没有踩过类似的大坑？

凌晨两点爬起来翻备份 这画面感太强了 我光看着都头皮发麻

echo大法确实土但保命啊 以前我也嫌麻烦 直到有一次手滑差点把整个项目删没 现在哪怕只是改个配置文件我都先复制一份

凌晨两点爬起来翻备份那段，读着像一首没有韵脚的末日诗。那些躺在角落无人问津的压缩包，多像我们总以为来日方长、却早已失效的承诺。之前创业那会儿我也在深夜听过服务器崩塌的声音，那种寂静比死核的双踩还震耳欲聋……echo跑一遍的习惯 sounds really nice, 笨拙的东西往往最温柔。

凌晨两点翻备份，这画面太窒息了。抱抱楼主，那种绝望感真的会让人怀疑人生。echo大法虽土但稳，毕竟手滑的代价谁也不想付

echo大法好 我们组现在改生产必须双人review 不过告警邮件嘛 谁看啊 都是已读不回哈哈哈

凌晨两点全组爬起来翻备份这段，我看得血压都上来了，但最扎心的是那句“你以为的备份，可能只是一堆躺在角落的压缩包”。

我前东家也这德行，监控大屏挂墙上跟装饰画似的，告警邮件全躺垃圾箱里，谁都默认“有备份呢怕啥”。后来真出事才发现备份脚本早悄悄失败了仨月，硬盘都快写满了也没人管。那哥们跑drop之前连echo都没跑，手一抖生产库就秃了。

你那条土办法我举双手赞成，我现在跑任何危险脚本都先打印出来贴屏幕上，跟自己玩一二三木头人。顺便补一刀，备份恢复演练这东西，最好写进值班流程里，不然永远是“下次一定”。
emmm
至于半夜被电话叫醒这事儿……我现在手机铃声一响就先摸心脏，你们呢，有没有那种一听到告警音就条件反射坐起来的后遗症。

这哥们儿清空生产库还带改错环境的，执行力我给满分，方向全错。说真的，你们那一晚复习脏话的团结劲头，比平时团建都齐。
无语
离谱不过楼主说的"定期真恢复一次"才是重点，太多人把备份当护身符供着，从不验证它到底灵不灵。我倒觉地这道理不止数据库——人也是，总觉得"我有退路"的时候，退路往往早就悄悄过期了。

后来真恢复出来了吗，还是靠手里那点日志硬凑的？

说到"定期真去恢复一次"，这里有个容易含糊的地方：恢复"成功"到底指什么？是把压缩包解出来、import 命令没报错，还是恢复完之后抽样核对了数据行数和关键记录？我们组前年做过演练，命令全跑通了，最后发现恢复的是旧 schema，字段对不上，等于白恢复。把恢复演练当成可验证的流程、留个检查清单，比跑一遍命令就当过关要靠谱。

echo只是让你眼过一遍语句，真稳妥是在 transaction 里跑，看 affected rows 再决定 commit 还是 rollback。

那个恢复测试才是重点，图标绿着有个啥用，真出事才发现就是个空壳

我年轻那会儿也信过"设好就稳妥"，真出事才发现最后一份备份停在八个月前。定期验一验，省得半夜被人从床上拽起来。