<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          絕了!一個妹子 rm -rf 把公司整個數(shù)據(jù)庫刪沒了...

          共 1852字,需瀏覽 4分鐘

           ·

          2020-08-26 04:25

          來自:博客園 作者丨zhouyu

          原文鏈接(底部鏈接可直達(dá)):

          https://www.cnblogs.com/zhouyu629/p/3734494.html

          經(jīng)歷了兩天不懈努力,終于恢復(fù)了一次誤操作刪除的生產(chǎn)服務(wù)器數(shù)據(jù)。

          對本次事故過程和解決辦法記錄在此,警醒自己,也提示別人莫犯此錯。

          也希望遇到問題的朋友能找到一絲靈感解決問題。

          01

          事故背景

          安排一個妹子在一臺生產(chǎn)服務(wù)器上安裝 Oracle,妹子邊研究邊安裝,感覺裝的不對,準(zhǔn)備卸載重新安裝。

          從網(wǎng)上找到卸載方法,其中要執(zhí)行一行命令刪除 Oracle 的安裝目錄,命令如下:

          rm?-rf?$ORACLE_BASE/*??

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

          rm?-rf?/*??

          等等,妹子使用的可是 Root 賬戶啊。就這樣,把整個盤的文件全部刪除了,包括應(yīng)用 Tomcat、MySQL 數(shù)據(jù)庫 and so on……

          MySQL 數(shù)據(jù)庫不是在運行嗎?Linux 能刪除正在執(zhí)行的文件?反正是徹底刪除了,最后還剩一個 Tomcat 的 Log 文件,估計是文件過大,一時沒有刪除成功。


          看著妹子自責(zé)的眼神,又是因為這事是我安排她做的,也沒有跟她講清厲害關(guān)系,沒有任何培訓(xùn),責(zé)任只能一個人背了,況且怎么能讓美女背負(fù)這個責(zé)任呢?

          打電話到機房,將盤掛到另一臺服務(wù)器上,SSH 上去查看文件全部被清,這臺服務(wù)器運行的可是一個客戶的生產(chǎn)系統(tǒng)啊,已經(jīng)運行大半年了,得盡快恢復(fù)啊。


          于是找來脫機備份的數(shù)據(jù)庫,發(fā)現(xiàn)備份文件只有 1KB,里面只有幾行熟悉的 mysqldump 注釋(難道是 Crontab 執(zhí)行的備份腳本有問題),最接近的備份也是 2013 年 12 月份的了,真是屋漏偏逢連夜雨啊。


          想起來一位領(lǐng)導(dǎo)說過的案例:當(dāng)一個生產(chǎn)系統(tǒng)掛掉以后,發(fā)現(xiàn)所有備份都有問題,刻錄的光盤也有劃痕,磁帶機也壞了(一個業(yè)界前輩,估計以前還用光盤做備份了),沒想到今天真的應(yīng)驗到我的身上了,怎么辦?

          部門領(lǐng)導(dǎo)知道情況后,已經(jīng)做了最壞的 B 計劃:領(lǐng)導(dǎo)親自帶隊和產(chǎn)品 AA 周日趕到客戶所在的地市,星期一去領(lǐng)導(dǎo)層溝通;BB 和 CC 去客戶管理員那邊想辦法說服客戶……

          02

          救命稻草:ext3grep

          趕快到網(wǎng)上去查資料進(jìn)行誤刪數(shù)據(jù)恢復(fù),還真找到一款 ext3grep 能夠恢復(fù)通過 rm -rf 刪除的文件,我們磁盤也是 ext3 格式,且網(wǎng)上有不少的成功案例。

          于是燃起了一絲希望,趕快對盤 umount,防止重新寫入補刪文件扇區(qū)。下載 ext3grep,安裝(編譯安裝過程艱辛?xí)呵也槐恚?/p>

          先執(zhí)行掃描文件名命令:

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

          打印出了所有被刪除文件及路徑,心中狂喜,不用執(zhí)行 B 計劃了,文件都在呢。

          這款軟件不能按目錄恢復(fù)文件,只能執(zhí)行恢復(fù)全部命令:

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

          結(jié)果當(dāng)前盤空間不足,沒辦法只能恢復(fù)文件,嘗試了幾個文件,居然部分成功部分失?。?/p>

          ext3grep?/dev/vgdata/LogVol00?--restore-file?var/lib/mysql/aqsh/tb\_b\_attench.MYD??

          心里不禁一涼,難道是刪除磁盤上被寫過文件了?恢復(fù)機率不大了啊,能恢復(fù)幾個算幾個吧,說不定重要數(shù)據(jù)文件剛好在能恢復(fù)的 MYD 文件中。

          于是先將所有文件名重定向到一個文件文件中:

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

          過濾出來所有 MySQL 數(shù)據(jù)庫的文件名存成 mysqltbname.txt。

          編寫腳本恢復(fù)文件:

          while?read?LINE??
          do??
          ????echo?"begin?to?restore?file?"?$LINE??
          ????ext3grep?/dev/vgdata/LogVol00?--restore-file?$LINE??
          ????if?\[?$??!=?0?\]??
          ????then??
          ????????echo?"restore?failed,?exit"??
          ????fi??
          done?

          執(zhí)行,大概運行了 20 分鐘,恢復(fù)了 40 多個文件,但不夠啊,我們將近 100 張表,每張表 frm,myd,myi 三個文件,怎么說也有 300 多個左右??!

          將找回來的文件附到現(xiàn)有數(shù)據(jù)庫上,更要文件權(quán)限為 777 后,重啟 MySQL,也算是找回一部分?jǐn)?shù)據(jù)了,但客戶重要的考勤簽到數(shù)據(jù)、手機端上報數(shù)據(jù)(據(jù)說客戶按這些數(shù)據(jù)做員工績效的)還沒找回來啊。

          咋辦?中間又試了另一款工具 extundelete,跟 ext3grep 語法基本一致,原理應(yīng)該也一樣了,但是據(jù)說能按目錄恢復(fù)。

          好吧,試一試:

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


          果然不出所料,恢復(fù)不出來?。。。。。。?!那些文件已被破壞了。跟領(lǐng)導(dǎo)匯報,執(zhí)行 B 計劃吧……無奈之下下班回家。(周末了,回去休息一下,想想辦法吧)

          03

          靈機一動:Binlog

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

          依舊運行 ext3grep,extundelete,也就那幾招啊,把系統(tǒng)架到測試服務(wù)器上,看看數(shù)據(jù)能不能想辦法補一補吧。


          在測試服務(wù)器上進(jìn)行 mysqldump,恢復(fù)文件,覆蓋恢復(fù)回來的文件,給文件加權(quán)限,重啟 MySQL。

          Wait,Wait,不是有 Binlog 嗎?我們服務(wù)都要求開啟 Binlog,說不定能通過 Binlog 里恢復(fù)數(shù)據(jù)呢?


          于是從 Dump 出來的文件名里找到 Binlog 的文件,一共三個:

          • mysql-binlog0001

          • mysql-bin.000009

          • mysql-bin.000010

          恢復(fù)一下 0001:

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

          居然失敗了……再看另兩個文件,mysql-bin.000010 大概幾百 MB,應(yīng)該靠譜一點,執(zhí)行還原命令,居然成功了!

          趕快 SCP 到測試服務(wù)器。執(zhí)行 Binlog 還原:

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

          輸入密碼,卡住了(好現(xiàn)象),經(jīng)過漫長的等待,終于結(jié)束了。打開應(yīng)用,哦,感謝 CCTV,MTV,數(shù)據(jù)回來了!

          04

          后記

          也希望謹(jǐn)記此次事故,以后不再犯同樣的錯誤。事故反思如下:

          • 本次安排 MM 進(jìn)行服務(wù)器維護(hù)時沒有提前對她進(jìn)行說明厲害情況,自己也未重視,管理混亂,流程混亂。一個在線的生產(chǎn)系統(tǒng),任何一個改動一定要先謀而后動。

          • 自動備份出現(xiàn)問題,沒有任何人檢查。脫機備份人員每次從服務(wù)器上下載 1K 的文件卻從未重視。需要明確大家在工作崗位上的責(zé)任。

          • 事故發(fā)生后,沒有及時發(fā)現(xiàn),造成部分?jǐn)?shù)據(jù)寫入磁盤,造成不可恢復(fù)問題。需要編寫應(yīng)用監(jiān)控程序,服務(wù)一旦有異常,短信告警相關(guān)責(zé)任人。

          • 根據(jù)評論提醒,再加一條:不能使用 Root 用戶來操作。應(yīng)該在服務(wù)器上開設(shè)不同權(quán)限級別的用戶。


          通過本次事故

          分享下本文所用到的工具鏈接:

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

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

          功能跟 ext3grep 差不多,原理應(yīng)該也差不多。編譯安裝依賴包比較多,可以到網(wǎng)上搜索如何安裝。

          最后希望各位同行的小伙伴們能謹(jǐn)記本文事件,開心敲代碼,永遠(yuǎn)不出錯~



          推薦閱讀:


          喜歡我可以給我設(shè)為星標(biāo)哦

          好文章,我“在看”
          瀏覽 78
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          評論
          圖片
          表情
          推薦
          點贊
          評論
          收藏
          分享

          手機掃一掃分享

          分享
          舉報
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  se视频在线免费 | 国产三级毛片 | 日韩免费网址 | 精品蜜桃秘 一区二区三区毛茸茸 | 日韩精品淫秽视频 |