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

原创
2014/05/22 19:19
阅读数 1K

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

 

  1. 杀手级命令:rm -rf

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

      • 悲剧一:

        • 妹子在生产服务器上本意删除Oracle,但脚本中有一句:rm -rf $ORACLE_BASE/*

        • 不幸变量 ORACLE_BASE 未赋值

        • Tomcat/MySQL...全删了

        • 事故发生后,没有及时发现,造成部分数据写入磁盘,加大了不可恢复的几率

      • 悲剧二:

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

      • 应对:

        • 把盘 umount,防止继续有数据写入

        • 把盘以只读方式挂到另一台服务器上进行操作

        • 用 ext3grep 工具恢复出了 MySQL 几个 binlog 文件

        • 将 binlog 文件复制到测试服务器,运行 mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p 命令,执行 binlog 还原

        • 数据成功恢复

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

      • 悲剧一

        • 意图重建备份节点,需要把原来的从节点删除,重新安装,所以先使用了 rm -f 方式删除备份节点分区上的所有文件

        • 5分钟后,发现刚才删除的是数据库主节点的分区

      • 悲剧二

        • 由于4月23日数据库主节点迁移并升级到 MySQL 5.5,导致备份任务停止

        • 在长达两个月的时间里,一直没有将数据库备份节点恢复工作提上日程

        • 只有主节点上开启了 binlog

      • 应对

        • 把整个分区 dd 成镜像,准备做将来硬盘恢复的备份

        • 把 memcache 里的数据 dump 出来,以备可能的恢复(郑昀注:但只 dump 了一半,有人把服务重启了)

        • 重新启用原来的从数据库,由于数据时间只到4月23日,需要调整近两月表结构变更,让最新的代码可以跑起来

        • 联系上沃趣科技和北亚数据恢复中心,到7月1日上午,北亚数据恢复中心提取到几乎是完整的 ibdata1 文件,至7月2日凌晨4点,恢复了这次得到的所有数据

        • 7月2日下午4点,北亚提取到 ibdata1 剩下的文件碎片,得到了完整的 ibdata1 文件,MySQL 无报错启动,从而得到了6月26日凌晨事故前的完整数据库

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

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

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

  2. Redis 的 shutdown 命令

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

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

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

  4.  

 

总结:

备份是王道。

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

保持清醒(严禁饮酒操作¥%#^)。

遇事冷静。

 

参考资源:

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

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


 

赠图1枚:

http://ww1.sinaimg.cn/bmiddle/6e485ac8jw1egcdie5s72j20c80bit96.jpg


展开阅读全文
打赏
0
36 收藏
分享
加载中
我要重新检查脚本里的rm,都没试运行直接上生产了
2014/05/22 22:20
回复
举报
教训啊!!!慎用rm
2014/05/22 21:49
回复
举报
我也不小心犯过错,把本地repo删除过,把一个两周的task重新写了一遍
2014/05/22 21:49
回复
举报
2014/05/22 21:01
回复
举报
更多评论
打赏
4 评论
36 收藏
0
分享
返回顶部
顶部