不小心敲了 rm -rf / 後反應是怎樣的？

12-30

比如不小心敲rm -rf /tmp時敲成了rm -rf / tmp，大家敲下的時候都是什麼場景？什麼反應？又是怎麼熬過去的？
＝＝＝＝＝＝
更新
原意不一定是rm -rf / 也可以是rm -rf *之類，大家不要在意細節

某通信公司，HK某運營商項目，某中間件產品，實時系統，三期割接上線。

因為一期二期已經上線，現網系統已經承載C網200w用戶。

連續兩晚通宵，終於成功割接，系統運行正常。

一覺醒來，下午四點，業務高峰，登錄系統檢查狀態，運行正常，但發現系統後台目錄下有11個昨晚操作留下臨時文件，一共都不到1M的樣子。完美主義者+強迫症患者。沒經客戶允許，打算直接刪除。好了，事情來了。

業務操作員，應用後台home目錄下，rm -rf ./*XXXX* 不知道怎麼敲成了rm -rf ./* XXXX* 。多了個空格。

rm 3秒沒完成，第一反應，麻蛋，不對勁，貌似這次刪除時間有點長。

隨即系統立即報出rm: cannot remove directory `./mdsfiles": Device or resource busy，

X，TMD，這可是生產環境啊，完了，出事了，趕緊一頓 Ctrl+C，12個^C，rm操作取消。ls查看文件，不用細看就知道明顯少了好多文件。

下圖就是SecureCRT記錄的當時的操作日誌。(16:15:08的操作是Tab，不是回車，16:15:11的操作才是真正的rm操作)

其實之前身邊已經有人因為rm文件出過事故，自己也曾多次腦補過這個場景，也因為好奇使用root用戶在測試鏡像下搞過rm -rf /。

但第一時間還是懵了。也許是HK的空調太低，並沒有驚出一身汗，只是手有點抖。

趕緊登錄Web前台監控系統狀態，發現監控進程自己都已經掛掉了，業務進程狀態無法查詢。不行，要Hold不住。

通知身邊同事，和PM彙報上升問題，看看能不能讓客戶上游請求系統先暫時自己緩存請求，給我們半小時時間恢復之後再下發。後來據說當時PM正在和客戶開會，和客戶說了我們系統出了問題，客戶臉都白了，本想聯繫他主管，但又覺得不夠，直接打了電話給主管的主管，說趕緊下發緊急告警，啟動應急預案。

同時我這邊Web前台查詢請求狀態，發現還在處理業務請求。資料庫查詢請求數量，發現並無明顯積壓。感覺主進程應該暫時還在，我們應該還可以自己Hold一會。趕緊讓同事和PM說讓客戶先不要操作，我們自己再壓一會兒。PM和正在給領導打電話的客戶謊稱是我們自己看錯了。客戶又在電話里大喊告警解除。有種電影里發射核彈的感覺，很遺憾當時沒在場。如果啟動應急預案，估計可以去客戶官網看公告了。

憑直覺直接腳本拉起監控進程，命令敲完一半，Tab聯想不出來，才發現啟動腳本都已經刪沒了，Fxxx。因為生產環境為雙機，本來可以切換到備機，但雙機管理軟體因為這次上線已經凍結，現在恢復管理未必成功，如果中間出現問題無法完全啟動將會更加麻煩，而且切換過程中必定存在業務中斷，現在是業務高峰，所以不到萬不得已，絕對不能切！

全量下載備機環境，並和主機比對，批量上傳缺失文件，更新許可權777。腳本拉起監控進程，啟動正常。重新登錄web前台，已經可以查看系統狀態，發現兩個主進程的確還在。

初步Hold住，趕緊聯繫機關RD，手機熱點，遠程共享桌面，逐一反饋修復之後後台目錄下文件信息，確認主要文件都在，並評估部分缺失文件及本次操作影響。

目前系統狀態基本正常，CPU佔用率較高，原因還需定位，預計後續可能會出現報錯，但應該不至於影響業務。再次和PM彙報情況，但PM已經氣得不接我電話了...

誤刪文件之後，系統依舊堅挺，這應該是這次不幸中的萬幸，一直被我們抱怨不靠譜的新系統，這次終於靠譜了一把，也救了我一命。也幸好內部消化，否則飯碗肯定不保了。

現在監控系統狀態中，感覺應該趁加班寫個腳本，以後更安全的調用rm。

2016.07.20 更新：

因為當時是業務高峰，且並沒有有效定位思路，所以雖然CPU已經飆到300+%，但依舊決定進一步監控看下。當天夜裡CPU使用率居高不下，但一切正常。第二天凌晨兩點，爬起來監控，發現Web前台監控進程又掛了。深深呼了一口氣，冷靜。VPN遠程登錄伺服器，看了下日誌，有磁碟空間不足的報錯。df一下，果然磁碟空間不足。du一下發現，是系統日誌目錄過大，後台一晚上打了幾百G的日誌。

拉一個下來，同時刪除其餘日誌文件。再次手動拉起監控進程，系統監控頁面恢復，日誌仍在迅速增長。

看了下拉下來的日誌，發現全是x個文件請求監控線程的報錯，請求路徑不存在。登上伺服器看了下，發現文件請求目錄的確不存在。下午恢復的時候，只恢復了主路徑，並未恢復子路徑(子路徑為系統啟動時自動創建，備機環境並無子路徑)。mkdir手動創建目錄。ll日誌不再迅速增長，tail一下可以看到正常請求日誌。感覺CPU使用率居高不下的原因肯定也是因為這個，登錄Web前台，發現果然已經降到80%左右。

夜深人靜，一個人偷偷摸摸擦屁股的感覺真不好。

睡覺。

第二天早上起來，VPN監控，系統狀態正常，請求處理正常。七點，背著筆記本去見異地的女友。中午登錄系統檢查狀態的時候發現，進程一切正常，CPU使用率在30%左右，的確不高，但是這低得也有點誇張啊。緊接著查詢了下請求狀態。妹的，從早上八點50之後就再也沒有新請求過來。這他妹的少說也丟了幾十萬條的請求了。完了，飯碗又不保了。

正打算聯繫客戶，客戶的WhatsApp就過來了。很奇怪的是，客戶語焉不詳，感覺似乎是早上很快就發現了，只是一直不確定是不是他們自己請求系統(客戶自己開發，和我們同時上線)的問題，所以直到下午才找到我們，這幫孫子...現在要拉上我們一起聯合定位，定位個鬼，趕緊力薦客戶重啟。反正現在環境文件已經完全恢復，只要重啟，昨天下午刪除操作的一切可能的隱患都可以規避掉。

結果是重啟之後果然就好了。後續定位這次的工單丟失4個小時是因為客戶自己請求系統的Bug導致的，和那次誤刪沒關係。但是兩件事碰巧先後發生，真的是不得不讓人緊張。

突然想到了我「岳父」的一段話：有時候，「虛驚一場」這四個字是人世間最美好的成語，比起什麼興高采烈，五彩繽紛，一帆風順都要美好百倍。你可懂什麼叫失去。這些時間來，更覺如此。願悲傷恐懼能夠過去，事外之人更懂珍惜。

終：後來在不久之後的一次和客戶申請的正式升級操作過程中已將系統全部重新部署，現在已經穩定運行。我也於2016年7月結束14個月的HK項目交付工作，外人看來的「功成身退」，只有我自己知道這段日子有多難熬。

2017.02.03更新

不知道是不是因為這兩天的gitlab rm -rf事故讓大家對這個問題產生了興趣，但兩天500+的點贊量著實讓我有點受寵若驚。

其實這次經歷很大一部分原因在於我自己的手殘，而且處理的方式也並無什麼值得借鑒之處，所以這麼高的點贊量讓我更加慚愧。

於心有愧，所以我覺得應該和大家分享自己的一些思考...

1.工作的時候盡量保持清醒，進行高危操作的時候一定要保持清醒

2.建議每次執行rm操作前，核對一遍之後再敲回車(雖然這個動作可能已經成為很多程序員神經迴路的一部分)。如有必要，可對rm命令設置alias，設置別名為mv到指定目錄，crontab定時清理

3.做好用戶許可權控制，root不公開，使用低許可權業務用戶進行日常操作。需要高許可權使用密碼sudo (當時使用的業務用戶，操作的是應用後台根目錄，誤刪文件的數量，用途和影響至少都大致了解，風險可控)

4.操作窗口之外，不要亂動生產，我現在覺得最好登都不要登

2017.12.23更新

@vczh 輪子哥竟然點贊了，有點受寵若驚。

最近工作一直比較忙，評論內容稍後回復。 -- 1514022249000

我們是不允許用rm命令的，要刪除文件，需要mv文件到指定目錄/delete/，會有一個定時任務，每周清空/delete/下文件。

倒不是 rm -rf，只是 rm，但是也夠嚇人的。

我之前寫作業的文件名都是 .tex，比如量子力學第四次作業就是 quant4.tex

當時在學數理統計，統計這個學科的簡稱的話，有人用 stats 有人用 stat，於是我寫作業的時候就有的時候用 stat4 有時候用 stats4

當時是第四次作業，至今記得很清楚，當時學 Cramér–Rao lower bound，不太了解的可以去 wikipedia 看看那公式有多長，裡面還包含了各種 log，導數，以及 expected value。再加上統計作業向來都是數學中最為又臭又長的作業，那次作業真是噩夢。

我第一天建了一個 stat4.tex 寫了一點，過兩天完全忘了這事了，於是新建了一個 stats4.tex，把作業寫完了。

然後 ll 的時候發現有一個 stat4.tex 和一個 stats4.tex，然後想到了之前寫了一點。。。

然後就隨手：

rm stats4.tex

之後

pdflatex stat4.tex

start stat4.pdf

發現只有一點點，當時還以為是 drawboard 或者 pdflatex 緩存了啥，於是把 aux 什麼的全清了，重新跑一遍，在 start 發現還是一點。。。

我就有點慌了，打開源碼，發現我刪掉的居然是寫完的！！！！

第一反應就是去翻回收站，別問我為啥 rm 了還去翻回收站，當時腦子都是空的，你跟我說請個巫師來跳跳舞能恢復文件我都要試一下。

回收站沒有之後想到我的整個 document 文件夾都是掛在 onedrive 上的，就希望還沒同步上去，馬上關了 onedrive 然後去網頁版上看，發現已經同步好了，畢竟學校網速快，一個 tex 文件估計要不了幾秒就沒了。。。

然後我整個人就沉浸在悲痛之中了，下午本來還要出去玩。。。我就把吭哧了一晚上一早上的作業刪了。。。

之後的事情我都不記得了，

下一個記憶就是幾個人在門口等一個同學一起出去，我突然想到我用的 vim latex live preview 的機制是把 buffer 保存在 temp 裡面然後不斷編譯。

我當時就直接沖回宿舍，用 everything 找到了緩存的 buffer 弄出來之後發現是幾乎完整的作業，保存編譯好之後才放下心來。。。

這個故事告訴我們

vim 宇宙最強，emacs 就是垃圾

跑 npm install 看看誰更快！（因為有一個笑話說 node_modules 是對 rm 誤操作最好的防禦，給你足夠多的時間去反應。）

我曾經為了做這個實驗，故意在我的Mac上嘗試過。

打開一個Terminal，飛快的敲下sudo rm -rf /，然後輸入密碼。就等著電腦開始狂轉，然後過了十五分鐘跑完了。

跑後的結果是，有一些原本就有的系統文件還是刪不掉的，sudo了也不行，其他的所有東西全部一乾二淨。

sudoers文件也不見了，也就是說這之後就再也無法使用sudo了。

已經運行著的程序都還保持著正常的運行，有的因為被刪了某些配置文件讀不到而出錯。

然後

我就用Time Machine給全盤恢復回來了。。。

終極解決方案: mv 文件(夾) /tmp

(/tmp 下的文件在每次關機後都會被清理乾淨)

rm -rf 這個沒有做過，

給你們分享一個刪錯東西的經歷吧，剛開始做運維的時候，一次弄公司資料庫，drop了4張很很很關鍵的主表(公司搞公安案件偵破系統的，這幾張主表都是存放的案件信息和證據筆錄之類的)，因為很多個庫(測試，中間，正式)都在操作，按下F8後發現正處於正式庫，感覺腦海裡面瞬間處於真空狀態然後就是一道閃電照亮夜空的感覺，接下來的一兩秒鐘後背衣服全部被汗沁濕了。還好老師傅給我從備份裡面恢復了，要不我現在估計還在局子裡面。

Chinese input method on my phone is not working

1. I often do not use -f when rm

2. Sometimes it is annoying when some files are mistakenly removed by rm, even without -f

3. If you are a manager of a cluster, and the cluster is physically accessible. You can backup the whole system excluding the /home and data does to an external disk for recovery.

4. Use rsync --delete with include and exclude if precision is required.

5. Keep a cat. Then you could claim it is not you who removes the files, but, unfortunately, the cat was getting some exercises.

趁著自己的賤手還放在鍵盤上，趕緊Ctrl-C啊！

嚇的我趕緊使用了以下命令：brew install safe-rm

echo "alias rm=/usr/local/safe-rm" &>&> ~/.profile

不過不是root應該還是刪不掉/的吧，反正我沒試過。

1、強制關機

2、從Hyper-V還原點還原

3、開機

4、爽

後果挺嚴重的

rm -rf *

桃花過後，寸草不生。

之前手賤過一次，有個目錄下全是不需要的日誌文件，想著全部刪除來著。。

執行了大概快有十秒我才發現不對勁，然後立馬連續按了五六個ctrl+c，趕緊ll一下看看當前目錄下有文件沒。。。一首涼涼在耳邊響起。。。

要問我怎麼解決的，我連重啟一下都開不了機了。。。。不幸中的萬幸是這是我個人的伺服器，恢復了前一個快照，雖然很多東西需要重新部署了，不過也無大礙。

如果是公司生產環境，那就。。。反正樓層也挺高的，窗戶走出去以死謝罪了只能。

此後，每次敲rm命令都要多看兩眼才敢敲回車，凡是帶梅花的命令更是要慎之又慎。

梅花過後，寸草不留

嚇得我差點手抖敲了一下……

上次遇到這種情況，刪到一些諸如/sys之類的地方，刷出了大量Permission denied，延緩了刪除速度，給了我按^C的時間。雖然系統廢了，但沒有碰到/home。

一般會停下來看看，估計有過那麼兩次感慨我擦幸虧還沒敲回車。

前段時間，在自個兒的 VPS 上，正準備刪掉

/var/lib/docker/volumes/balabala

（某個 docker 數據卷，不想要了，準備刪掉）

然後……由於 SSH 延遲較高而我手速太快，還沒有 cd 到 balabala 的時候，一個rm -rf 就敲出去了，一瞬間，所有的 volume 都化為浮雲

損失慘重，幸好還有一份一個月前的磁碟快照。靠 Google cache 的網頁恢復了丟掉的幾篇博客，又把本地的 git repo 一個一個推上去，搞了一晚上從此乖乖開著一個月一刀的自動備份（vultr）

常見的linux（CentOS/Ubuntu）上的rm如果被執行到/的話肯定會要求帶--no-preserve-root啊。不帶這個參數的rm -rf /是不會執行的。

想到我男票還沒跟我在一起時對他仰慕已久的我去找他修電腦當時偷懶把所有的實驗數據全部放在桌面一個data 的文件夾里男票在我面前大秀命令行可能是太激動不小心在desktop下敲了rm -rf.... 看到他的臉都嚇綠了可能是太抱歉了最後只能以身相許....lol