被小伙伴們嚇哭了：可怕的命令

1. 殺手級命令：rm -rf
2. 2014-5-17-某軟件公司在生產環境誤刪數據庫文件
3. 悲劇一：
4. 妹子在生產服務器上本意刪除Oracle，但腳本中有一句：rm -rf $ORACLE_BASE/*
5. 不幸變量 ORACLE_BASE 未賦值
6. Tomcat/MySQL...全刪了
7. 事故發生后，沒有及時發現，造成部分數據寫入磁盤，加大了不可恢復的幾率
8. 悲劇二：
9. 找到脫機備份，發現備份文件只有1KB，里面只有幾行熟悉的 mysqldump 注釋。可用的、最接近的備份時間是2013年年底
10. 應對：
11. 把盤 umount，防止繼續有數據寫入
12. 把盤以只讀方式掛到另一臺服務器上進行操作
13. 用 ext3grep 工具恢復出了 MySQL 幾個 binlog 文件
14. 將 binlog 文件復制到測試服務器，運行 mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p 命令，執行 binlog 還原
15. 數據成功恢復
16. 2013-6-26-”下廚房“誤刪數據庫主節點分區
17. 悲劇一
18. 意圖重建備份節點，需要把原來的從節點刪除，重新安裝，所以先使用了 rm -f 方式刪除備份節點分區上的所有文件
19. 5分鐘后，發現剛才刪除的是數據庫主節點的分區
20. 悲劇二
21. 由于4月23日數據庫主節點遷移并升級到 MySQL 5.5，導致備份任務停止
22. 在長達兩個月的時間里，一直沒有將數據庫備份節點恢復工作提上日程
23. 只有主節點上開啟了 binlog
24. 應對
25. 把整個分區 dd 成鏡像，準備做將來硬盤恢復的備份
26. 把 memcache 里的數據 dump 出來，以備可能的恢復（鄭昀注：但只 dump 了一半，有人把服務重啟了）
27. 重新啟用原來的從數據庫，由于數據時間只到4月23日，需要調整近兩月表結構變更，讓最新的代碼可以跑起來
28. 聯系上沃趣科技和北亞數據恢復中心，到7月1日上午，北亞數據恢復中心提取到幾乎是完整的 ibdata1 文件，至7月2日凌晨4點，恢復了這次得到的所有數據
29. 7月2日下午4點，北亞提取到 ibdata1 剩下的文件碎片，得到了完整的 ibdata1 文件，MySQL 無報錯啟動，從而得到了6月26日凌晨事故前的完整數據庫
30. 鄭昀注1：對上述兩個事件，都是”在MySQL運行情況下通過rm -rfs刪除數據庫文件“，那么文件到底刪了嗎？請看下廚房的事后總結：
31. 『事后從沃趣科技的數據庫工程師那里得知，我們第一時間停止 MySQL 防止硬盤繼續寫入這個應急措施是錯誤的，即使分區完全沒有文件，MySQL 的進程繼續運行，只要保留這個現場，可以從內存中獲取更多的數據庫結構信息，對恢復數據非常有幫助。』
32. 鄭昀注2：有人認為第一時間應該停止 Web 服務，而不是停止 MySQL 實例
33. Redis的 shutdown 命令
34. 據傳，某東電商網站在某年雙十一前出過一次不小的事故，原因居然是程序中要斷開 Redis 的鏈接(命令應為：disconnect)，但代碼中寫的是 shutdown……——Fenng
35. rsync的源目錄和目標目錄寫反了
36. 悲劇的是，rsync 不僅同步很快，刪除文件速度也很快，你把一個空目錄當成源，那真正的源目錄的數據瞬間消失……

總結：

備份是王道。

備份的可恢復性檢查是王道中的王道。

保持清醒（嚴禁飲酒操作￥%#^）。

遇事冷靜。

參考資源：

1，老周，2014，一次心驚肉跳的服務器誤刪文件的恢復過程；

2，下廚房，2013，下廚房6月26日數據丟失事故總結；

贈圖1枚：

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com