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

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

總結：

備份是王道。

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

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

遇事冷靜。

參考資源：

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

2，下廚房，2013，下廚房6月26日數(shù)據(jù)丟失事故總結；

贈圖1枚：

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