Linux Shell 從入門到刪除根目錄跑路指南
- 2019 年 10 月 25 日
- 筆記
shell 作為一門 linux 下使用廣泛的系統語言，語法簡單，上手容易，但是想要用好，少犯錯誤，也不是那麼容易的一件事，可謂雖是居家旅行之良藥，但也是殺人滅口之利器~
今天就來聊聊 linux 下一個常見的問題：如何避免誤刪目錄。下文會詳細的講述不同的場景下誤刪目錄，以及相應的解決方案。
1、變量為空導致誤刪文件
base_path=/usr/sbin
tmp_file=`cmd_invalid`
# rm -rf $base_path/$tmp_file
這種情況下如果 cmd 執行出錯或者返回為空，後果將是災難性的，那如何防範呢？
（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、路徑含有空格導致誤刪文件
史上最經典的要數下面這個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 操作系統資源，這樣至少不會刪除系統文件。
6、在登錄 shell 下使用友好的提示符
友好的命令提示符能時刻提醒操作者當前在哪個路徑下，避免錯誤的路徑下操作文件。
上文到此就結束了，列舉了一些常見的case和解決方案，希望能對大家有所啟發。
最後我們來說說刪庫跑路的事兒：
IT界的一個老梗，一次某論壇的數據庫管理員抱怨自己老闆一直虐待他，結果他一氣之下就刪庫跑路了……於是就有了從刪庫到跑路這個梗……
當刪庫成為
6月初，位於荷蘭海牙的一家雲主機商 verelox.com， 一名前任管理員刪光了該公司所有客戶的數據，並且擦除了大多數服務器上面的內容，帶來了巨大的損失。
2017-04-05，位於紐約的雲服務商 Digital Ocean 遭遇了一次長達4小時56分鐘的停機事故，事故的原因是主數據庫被刪除了（primary database had been deleted），由於配置錯誤，本應指向測試環境的任務被指向了生產環境，測試任務包含的環境初始化過程刪除了主生產數據庫。（不以規矩不成方圓：Digital Ocean也刪除了他們的數據庫）
2月11日，網絡剪報服務商 – Instapaper 遭受了超過31小時的服務中斷，聲明需要一個星期的數據庫恢復時間，然而經過10天的恢復，也僅僅恢復了6個星期的數據。（雲服務真的靠譜嗎？AWS 用戶中斷31小時僅恢復6周數據）
2月1日，除夕剛剛過完，荷蘭的一個DBA在數據庫複製過程中意外地刪除了一個錯誤的服務器上的目錄，刪除了一個包含300GB的實時生產數據的文件夾。300G的數據庫被刪成4.5G，由於沒有有效的備份，嘗試了所有5個恢復工具都沒有完成恢復。在丟失數據並恢復失敗後，服務器徹底崩潰。五重備份無一有效，還有哪些 rm -rf 和GitLab類似的憂傷？
1月20日，大約一定是受到川普上任的影響，突如其來的服務器故障影響了一大批爐石玩家，恢復時間長，由於意外斷電，導致數據庫損壞，不得不通過遊戲回檔恢複數據庫的使用。
而若操作者具有較高級別的權限，數據庫面臨的災難則是巨大的。Lucchese前IT主管，在離職的時候收集了IT部門所有職工的用戶名和密碼然後偽裝成一台辦公室打印機創建了一個密碼賬號，並在其辦公室內使用該賬號進行了一系列的違規操作，給企業帶來了嚴重的損失。Venzor後來被捕，並面臨最高達10年的監禁生活以及25萬美元的罰款。
在剛剛過去的7月，花旗銀行的前員工倫農·雷·布朗，通過非法執行命令，刪除了花旗銀行的內部網絡上10隻核心路由器上的配置文件。結果引起的故障導致全國110個分行無法正常使用網絡和電話系統，佔到花旗銀行所有分支機構總數的約90%。
手動刪庫簡直太low，我都是腳本自動刪
又不禁想起了Google曾經轟動一時的流水線刪庫事件，這可是團隊作案喲，這麼團結真的好嗎？（時移世易：遵從既往經驗致 1.5PB 數據刪除，Google SRE是如何應對的？）
一個 Google Music 用戶彙報某些之前播放正常的歌曲現在無法播放了。Google Music 的用戶支持團隊通知了工程師團隊，這個問題被歸類為流媒體播放問題進行調查。3 月 7 日，負責調查此事的工程師發現無法播放的歌曲的元數據中缺少了一個針對具體音頻數據文件的指針，於是他就修復了這個歌曲的問題。
但是，Google 工程師經常喜歡深究問題，也引以為豪，於是他就繼續在系統中查找可能存在的問題，當發現數據完整性損壞的真正原因時，他卻差點嚇出心臟病:這段數據是被某個保護隱私目的的數據刪除流水線所刪掉的。Google Music 的這個子系統的設計目標之一就是在儘可能短的時間內刪除海量音頻數據。
該流水線任務大概誤刪除了 60 萬條音頻文件，大概影響了 2.1 萬用戶.
