shell 作為一門 linux 下使用廣泛的系統(tǒng)語言，語法簡單，上手容易，但是想要用好，少犯錯誤，也不是那么容易的一件事，可謂雖是居家旅行之良藥，但也是殺人滅口之利器~

今天就來聊聊 linux 下一個常見的問題：如何避免誤刪目錄。下文會詳細的講述不同的場景下誤刪目錄，以及相應的解決方案。

1、變量為空導致誤刪文件

base_path=/usr/sbin

tmp_file=`cmd_invalid`

# rm -rf $base_path/$tmp_file

這種情況下如果 cmd 執(zhí)行出錯或者返回為空，后果將是災難性的，那如何防范呢？

（1）利用 shell 的變量擴展功能，如果變量為空賦給默認值或者拋出異常退出腳本：

echo ${base_path:?var is empty}/${tmp_file:?var is empty}

-bash: tmp_file: var is empty

（2）人肉判斷變量是否為空：

[[ ${tmp_file} == "" ]] && echo 1

1[[ -z ${tmp_file} ]] && echo 1

1

（3）如果變量未定義還可以開啟 set 選項：

# cat a.sh

set -u

b=

echo $b

echo $a

echo 1

# bash a.sh

a.sh: line 4: a: unbound variable

2、路徑含有空格導致誤刪文件

史上最經典的要數(shù)下面這個bumblebee項目了，這個項目本來不出名，不過，程序在其安裝腳本install.sh里的一個bug讓這個項目一下子成了全世界最矚目的項目。

那我們該如何防范這種問題呢？

（1）良好的編程習慣：變量加引號防止擴展

path="/usr/local /sbin"

# rm -rf $path

rm -rf "$path"

（2）對變量進行語義檢查

比如檢測是否含有空格等特殊字符，不通用，不推薦這么做

3、目錄或文件含有特殊字符導致誤刪文件

ll

總用量 8

drwxrwxr-x 2 work work 4096 11月 24 18:57 '~'

-rw-rw-r-- 1 work work 34 11月 24 19:49 a.sh

# rm -rf ~

那我們該如何防范這種問題呢？

（1）良好的編程習慣：變量加引號防止擴展

rm -rf "~"

（2）如果不確定，刪除之前 echo或 find一下，看變量被擴展成啥了

echo rm -rf "~"

rm -rf ~

echo rm -rf ~

rm -rf /home/work

4、cd 切換目錄失敗，導致文件被誤刪

cd ooxx_path_not_exsit

rm -rf *.exe

恭喜這種情況下你的當前目錄下匹配文件都會被誤刪，那我們該如何防范這種問題呢？

（1）使用邏輯短路操作

cd path && rm -rf *.exe

（2）檢測 path 是否存在

[[ -d ~ ]] && echo 1

1

5、終極解決方案

不要使用 root 操作系統(tǒng)資源，這樣至少不會刪除系統(tǒng)文件。

6、在登錄 shell 下使用友好的提示符

友好的命令提示符能時刻提醒操作者當前在哪個路徑下，避免錯誤的路徑下操作文件。

上文到此就結束了，列舉了一些常見的case和解決方案，希望能對大家有所啟發(fā)。

最后我們來說說刪庫跑路的事兒：

IT界的一個老梗，一次某論壇的數(shù)據(jù)庫管理員抱怨自己老板一直虐待他，結果他一氣之下就刪庫跑路了……于是就有了從刪庫到跑路這個梗......

當刪庫成為一種時尚

6月初，位于荷蘭海牙的一家云主機商verelox.com，一名前任管理員刪光了該公司所有客戶的數(shù)據(jù)，并且擦除了大多數(shù)服務器上面的內容，帶來了巨大的損失。

2017-04-05，位于紐約的云服務商 Digital Ocean 遭遇了一次長達4小時56分鐘的停機事故，事故的原因是主數(shù)據(jù)庫被刪除了（primary database had been deleted），由于配置錯誤，本應指向測試環(huán)境的任務被指向了生產環(huán)境，測試任務包含的環(huán)境初始化過程刪除了主生產數(shù)據(jù)庫。（不以規(guī)矩不成方圓：Digital Ocean也刪除了他們的數(shù)據(jù)庫）

2月11日，網絡剪報服務商 -Instapaper 遭受了超過31小時的服務中斷，聲明需要一個星期的數(shù)據(jù)庫恢復時間，然而經過10天的恢復，也僅僅恢復了6個星期的數(shù)據(jù)。（云服務真的靠譜嗎？ AWS 用戶中斷31小時僅恢復6周數(shù)據(jù)）

2月1日，除夕剛剛過完，荷蘭的一個DBA在數(shù)據(jù)庫復制過程中意外地刪除了一個錯誤的服務器上的目錄，刪除了一個包含300GB的實時生產數(shù)據(jù)的文件夾。300G的數(shù)據(jù)庫被刪成4.5G，由于沒有有效的備份，嘗試了所有5個恢復工具都沒有完成恢復。在丟失數(shù)據(jù)并恢復失敗后，服務器徹底崩潰。五重備份無一有效，還有哪些 rm -rf 和GitLab類似的憂傷？

1月20日，大約一定是受到川普上任的影響，突如其來的服務器故障影響了一大批爐石玩家，恢復時間長，由于意外斷電，導致數(shù)據(jù)庫損壞，不得不通過游戲回檔恢復數(shù)據(jù)庫的使用。

而若操作者具有較高級別的權限，數(shù)據(jù)庫面臨的災難則是巨大的。Lucchese前IT主管，在離職的時候收集了IT部門所有職工的用戶名和密碼然后偽裝成一臺辦公室打印機創(chuàng)建了一個密碼賬號，并在其辦公室內使用該賬號進行了一系列的違規(guī)操作，給企業(yè)帶來了嚴重的損失。Venzor后來被捕，并面臨最高達10年的監(jiān)禁生活以及25萬美元的罰款。

在剛剛過去的7月，花旗銀行的前員工倫農·雷·布朗，通過非法執(zhí)行命令，刪除了花旗銀行的內部網絡上10只核心路由器上的配置文件。結果引起的故障導致全國110個分行無法正常使用網絡和電話系統(tǒng)，占到花旗銀行所有分支機構總數(shù)的約90%。

手動刪庫簡直太low，我都是腳本自動刪

又不禁想起了Google曾經轟動一時的流水線刪庫事件，這可是團隊作案喲，這么團結真的好嗎？（時移世易：遵從既往經驗致 1.5PB 數(shù)據(jù)刪除，Google SRE是如何應對的？）

一個 Google Music 用戶匯報某些之前播放正常的歌曲現(xiàn)在無法播放了。Google Music 的用戶支持團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。3 月 7 日，負責調查此事的工程師發(fā)現(xiàn)無法播放的歌曲的元數(shù)據(jù)中缺少了一個針對具體音頻數(shù)據(jù)文件的指針，于是他就修復了這個歌曲的問題。

但是，Google 工程師經常喜歡深究問題，也引以為豪，于是他就繼續(xù)在系統(tǒng)中查找可能存在的問題，當發(fā)現(xiàn)數(shù)據(jù)完整性損壞的真正原因時，他卻差點嚇出心臟病:這段數(shù)據(jù)是被某個保護隱私目的的數(shù)據(jù)刪除流水線所刪掉的。Google Music 的這個子系統(tǒng)的設計目標之一就是在盡可能短的時間內刪除海量音頻數(shù)據(jù)。

該流水線任務大概誤刪除了 60 萬條音頻文件，大概影響了 2.1 萬用戶.

沒有刪過庫的Linux管理員，不是好的Linux運維工程師！