鄭昀 創建於2014/5/19
最后更新於2014/5/22
友情贈送一篇：被小伙伴們蠢哭了的那些事兒：找回密碼篇 (2014-01-13)
- 殺手級命令：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 實例
- Redis 的 shutdown 命令
- 據傳，某東電商網站在某年雙十一前出過一次不小的事故，原因居然是程序中要斷開 Redis 的鏈接(命令應為：disconnect)，但代碼中寫的是 shutdown……——Fenng
- rsync 的源目錄和目標目錄寫反了
- 悲劇的是，rsync 不僅同步很快，刪除文件速度也很快，你把一個空目錄當成源，那真正的源目錄的數據瞬間消失……
總結：
備份是王道。
備份的可恢復性檢查是王道中的王道。
保持清醒（嚴禁飲酒操作￥%#^）。
遇事冷靜。
參考資源：
1，老周，2014，一次心驚肉跳的服務器誤刪文件的恢復過程；
2，下廚房，2013，下廚房6月26日數據丟失事故總結；
贈圖1枚：
