一次心驚肉跳的伺服器誤刪檔案的恢複過程

來源:互聯網
上載者:User

   經曆了兩天不懈努力,終於恢複了一次誤操作刪除的生產伺服器資料。對本次事故過程和解決辦法記錄在此,警醒自己,也提示別人莫犯此錯。也希望遇到問題的朋友能找到一絲靈感解決問題。

  事故背景

  安排一個妹子在一台生產伺服器上安裝Oracle,妹子邊研究邊安裝,感覺裝的不對,準備卸載重新安裝。從網上找到卸載方法,其中要執行一行命令刪除Oracle的安裝目錄,命令如下:

  rm -rf $ORACLE_BASE/*

  如果ORACLE_BASE這個變數沒有賦值,那命令就變成了

  rm -rf /*

  ==||,妹子使用的可是root賬戶啊。就這樣,把整個盤的檔案全部刪除了,包括應用Tomcat、MySQL資料庫 and so on。

  (mysql資料庫不是在運行嗎?linux能刪除正在執行的檔案?反正是徹底刪除了,最後還剩一個tomcat的log檔案,估計是檔案過大,一時沒有刪除成功)

  看著妹子自責的眼神,又是因為這事是我安排她做的,也沒有跟她講清厲害關係,沒有任何培訓,責任只能一個人背了,況且怎麼能讓美女背負這個責任呢?

  打電話到機房,將盤掛到另一台伺服器上,ssh上去查看檔案全部被清,這台伺服器啟動並執行可是一個客戶的生產系統啊,已經運行大半年了,得儘快恢複啊。於是找來離線備份的資料庫,發現備份檔案只有1kb,裡面只有幾行熟悉的mysqldump注釋(難道是crontab執行的備份指令碼有問題),最接盡的備份也是2013年12月份的了,真是屋漏偏逢連夜雨啊。

  想起來一位領導說過的案例:當一個生產系統掛掉以後,發現所有備份都有問題,燒錄的光碟片也有劃痕,磁帶機也壞了(一個業界前輩,估計以前還用光碟片做備份了),沒想到今天真的應驗到我的身上了,怎麼辦??

  部門領導知道情況後,已經做了最壞的B計劃:領導親內建隊和產品AA周日趕到客戶所在的地市,星期一去領導層溝通;BB和CC去客戶管理員那邊想辦法說服客戶。

  救命稻草--ext3grep

  趕快到網上去查資料進行誤刪資料恢複,還真找到一款ext3grep能夠恢複通過rm -rf刪除的檔案,我們磁碟也是ext3格式,且網上有不少的成功案例。於是燃起了一絲希望,趕快對盤umount,防止重新寫入補刪檔案扇區。下載ext3grep,安裝(編譯安裝過程艱辛暫且不表)。

  先執行掃描檔案名稱命令:

  ext3grep /dev/vgdata/LogVol00 --dump-names

  列印出了所有被刪除檔案及路徑,心中狂喜,不用執行B計划了,檔案都在呢。

  這款軟體不能按目錄恢複檔案,只能執行恢複全部命令:

  ext3grep /dev/vgdata/LogVol00 --restore-all

  結果當前盤空間不足,沒辦法只能恢複檔案,嘗試了幾個檔案,居然部分成功部分失敗

  ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/aqsh/tb_b_attench.MYD

  心裡不禁一涼,難道是刪除磁碟上被寫過檔案了?恢複機率不大了啊,能恢複幾個算幾個吧,說不定重要資料檔案剛好在能恢複的MYD檔案中。於是先將所有檔案名稱重新導向到一個檔案檔案中

  ext3grep /dev/vgdata/LogVol00 --dump-names >/usr/allnames.txt

  過濾出來所有mysql資料庫的檔案名稱存成,mysqltbname.txt

  編寫指令碼恢複檔案:

  while read LINE

  do

  echo "begin to restore file " $LINE

  ext3grep /dev/vgdata/LogVol00 --restore-file $LINE

  if [ $? != 0 ]

  then

  echo "restore failed, exit"

  # exit 1

  fi

  done < ./mysqltbname.txt

  執行,大概運行了20分鐘,恢複了40多個檔案,但不夠啊,我們將近100張表,每張表frm,myd,myi三個檔案,怎麼說也有300多個左右啊!!將找回來的檔案附到現有資料庫上,更要檔案許可權為777後,重啟mysql,也算是找回一部分資料了,但客戶重要的考勤簽到資料、手機端上報資料(據說客戶按這些資料做員工績效的)還沒找回來啊。

  咋辦?中間又試了另一款工具extundelete,跟ext3grep文法基本一致,原理應該也一樣了,但是據說能按目錄恢複,好吧試一試。

  extundelete /dev/vgdata/LogVol00 --restore-directory var/lib/mysql/aqsh

  果然不出所料,恢複不出來!!!!!!!!那些檔案已被破壞了。跟領導彙報,執行B計劃吧。。。無奈之下下班回家(周末了,回去休息一下,想想辦法吧)

  靈機一動:binlog

  第二天早晨一早就醒了(心裡有事啊),背上電腦,去公司(這個周末算是報銷了,不挨批,通報,罰款,開除就不錯了,還過什麼周末啊)。

  依舊運行ext3grep,extundelete,也就那幾招啊,把系統架到測試伺服器上,看看資料能不能想辦法補一補吧。在測試伺服器上進行mysqldump,恢複檔案,覆蓋恢複回來的檔案,給檔案加許可權,重啟mysql。

  wait,wait,不是有binlog嗎?我們服務都要求開啟binlog,說不定能通過binlog裡恢複資料呢?

  於是從dump出來的檔案名稱裡找到binlog的檔案,一共三個,mysql-binlog0001,mysql-bin.000009,mysql-bin.000010,恢複一下0001

  ext3grep /dev/vgdata/LogVol00 --restore-file var/lib/mysql/mysql-bin.000001

  居然失敗了……

  再看另兩個檔案,mysql-bin.000010大概幾百MB,應該靠譜一點,執行還原命令,居然成功了!

  趕快scp到測試伺服器。執行binlog還原。

  mysqlbinlog /usr/mysql-bin.000010 | mysql -uroot -p

  輸入密碼,卡住了(好現象),經過漫長的等待,終於結束了。開啟應用,哦,感謝cctv,mtv,資料回來了!

  後記

  經過此次事故,雖然資料很幸運能找回來了,但是過程卻是驚心動迫。也為自己的錯誤所帶來的後果,給同事和領導帶來的連帶責任而後怕。也希望謹記此次事故,以後不再犯同樣的錯誤。事故反思如下:

  1.本次安排MM進行伺服器維護時沒有提前對她進行說明厲害情況,自己也未重視,管理混亂,流程混亂。一個線上的生產系統,任何一個改動一定要先謀而後動。

  2.自動備份出現問題,沒有任何人檢查。離線備份人員每次從伺服器上下載1k的檔案卻從未重視。需要明確大家在工作崗位上的責任。

  3.事故發生後,沒有及時發現,造成部分資料寫入磁碟,造成不可恢複問題。需要編寫應用監控程式,服務一旦有異常,簡訊警示相關責任人。

  根據評論提醒,再加一條:

  4.不能使用root使用者來操作。應該在伺服器上開設不同權限等級的使用者。

  通過本次事故,幾位跟這個項目和事故沒有任何關係的同事,主動前來幫忙,查資料,幫測試,有一位同事還幫忙到晚上1點多鐘進行資料恢複測試。同時產品經理在想到面向客戶的巨大壓力的情況下,沒有慌亂而責怪開發人員和具體操作人,而讓大家能靜下心來想解決方案。部門領導也積極主動的幫忙想辦法,陪我們加班測試,即時跟蹤事情進程。

  通過大家的共同努力,終於事情相對圓滿結束,接下來,周一上午進行集體反思,總結經驗教訓,這類事故一定盡量大努力進行避免。

  本文所用到的工具鏈接:

  1.ext3grep:https://code.google.com/p/ext3grep/

  編譯安裝依賴包比較多,可以到網上搜尋如何安裝。可惜的是作者給出的howto被牆了,我FQ將how to 的pdf文檔下載下來了,讀完後你將會對linux的檔案系統有進一步的認識。下載howto。

  這個工具有一個bug,出錯後不會向下執行ext3grep: init_directories.cc:534: void init_directories(): Assertion `lost_plus_found_directory_iter != all_directories.end()' failed.,從而造成恢複失敗,作者放出了一個補丁,下載地址:補丁下載。不明白為什麼作者新版沒有把這個補丁加進去。

  2.extundelete:http://extundelete.sourceforge.net/

  功能跟ext3grep差不多,原理應該也差不多。只是號稱可以還原目錄,我這裡沒有實驗成功。

相關文章

Cloud Intelligence Leading the Digital Future

Alibaba Cloud ACtivate Online Conference, Nov. 20th & 21st, 2019 (UTC+08)

Register Now >

11.11 Big Sale for Cloud

Get Unbeatable Offers with up to 90% Off,Oct.24-Nov.13 (UTC+8)

Get It Now >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。