被小伙伴们吓哭了：可怕的命令

郑昀 创建于2014/5/19
最后更新于2014/5/22
友情赠送一篇：被小伙伴们蠢哭了的那些事儿：找回密码篇 (2014-01-13)

 

1. 杀手级命令：rm -rf

• 2014-5-17-某软件公司在生产环境误删数据库文件
• 悲剧一：

1. 妹子在生产服务器上本意删除Oracle，但脚本中有一句：rm -rf $ORACLE_BASE/*
2. 不幸变量 ORACLE_BASE 未赋值
3. Tomcat/MySQL...全删了
4. 事故发生后，没有及时发现，造成部分数据写入磁盘，加大了不可恢复的几率

悲剧二：

1. 找到脱机备份，发现备份文件只有1KB，里面只有几行熟悉的 mysqldump 注释。可用的、最接近的备份时间是2013年年底

应对：

1. 把盘 umount，防止继续有数据写入
2. 把盘以只读方式挂到另一台服务器上进行操作
3. 用 ext3grep 工具恢复出了 MySQL 几个 binlog 文件
4. 将 binlog 文件复制到测试服务器，运行 mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p 命令，执行 binlog 还原
5. 数据成功恢复

2013-6-26-”下厨房“误删数据库主节点分区

• 悲剧一

1. 意图重建备份节点，需要把原来的从节点删除，重新安装，所以先使用了 rm -f 方式删除备份节点分区上的所有文件
2. 5分钟后，发现刚才删除的是数据库主节点的分区

悲剧二

1. 由于4月23日数据库主节点迁移并升级到 MySQL 5.5，导致备份任务停止
2. 在长达两个月的时间里，一直没有将数据库备份节点恢复工作提上日程
3. 只有主节点上开启了 binlog

应对

1. 把整个分区 dd 成镜像，准备做将来硬盘恢复的备份
2. 把 memcache 里的数据 dump 出来，以备可能的恢复（郑昀注：但只 dump 了一半，有人把服务重启了）
3. 重新启用原来的从数据库，由于数据时间只到4月23日，需要调整近两月表结构变更，让最新的代码可以跑起来
4. 联系上沃趣科技和北亚数据恢复中心，到7月1日上午，北亚数据恢复中心提取到几乎是完整的 ibdata1 文件，至7月2日凌晨4点，恢复了这次得到的所有数据
5. 7月2日下午4点，北亚提取到 ibdata1 剩下的文件碎片，得到了完整的 ibdata1 文件，MySQL 无报错启动，从而得到了6月26日凌晨事故前的完整数据库

郑昀注1：对上述两个事件，都是”在MySQL运行情况下通过rm -rfs删除数据库文件“，那么文件到底删了吗？请看下厨房的事后总结：

• 『事后从沃趣科技的数据库工程师那里得知，我们第一时间停止 MySQL 防止硬盘继续写入这个应急措施是错误的，即使分区完全没有文件，MySQL 的进程继续运行，只要保留这个现场，可以从内存中获取更多的数据库结构信息，对恢复数据非常有帮助。』

郑昀注2：有人认为第一时间应该停止 Web 服务，而不是停止 MySQL 实例

Redis 的 shutdown 命令

• 据传，某东电商网站在某年双十一前出过一次不小的事故，原因居然是程序中要断开 Redis 的链接(命令应为：disconnect)，但代码中写的是 shutdown……——Fenng

rsync 的源目录和目标目录写反了

• 悲剧的是，rsync 不仅同步很快，删除文件速度也很快，你把一个空目录当成源，那真正的源目录的数据瞬间消失……

 

总结：

备份是王道。

备份的可恢复性检查是王道中的王道。

保持清醒（严禁饮酒操作￥%#^）。

遇事冷静。

 

参考资源：

1，老周，2014，一次心惊肉跳的服务器误删文件的恢复过程；

2，下厨房，2013，下厨房6月26日数据丢失事故总结；

 

赠图1枚：

 

评论

3 楼 xiaoZ5919 2014-05-26  

关于下厨房的这个事儿，只有close了所有指向该文件的文件描述符，文件名->inode,inode->磁盘扇区，才会真正删除磁盘上的文件，redis的rewrite aof，也是利用这个特性，在rename的时候采用异步close原文件描述符做到不阻塞主进程

2 楼 xiaoZ5919 2014-05-26  

确实太刺激了！我也干过其中的一些

1 楼 white_crucifix 2014-05-26  

卧槽太刺激了。。