“慎用rm -rf命令，除非你知道此命令帶來的后果。”這是一條Linux用戶守則，雖然大多數用戶都明白這條語句的含義，但是我覺得還需要完善一下，為這條語句加上一個使用前提：在你確認自己擁有清醒頭腦，並且輸入沒有誤差的時候可以使用rm -rf命令。這次驚心動魄的起因就是我將rm –rf log* 命令錯誤的輸成了rm –rf log *，造成了當前目錄下的所有項目文件全部被誤刪除。
ls了兩回，確定自己不是眼花后開始尋找解決辦法，昔日在Windows下有很多次數據恢復經歷，但在Linux下這還是第一次，在網上發現了神器extundelete，事后也證明它確實是神器，於是馬上准備下載安裝，但是問題來了，數據恢復成功的鐵律就是舊數據不被覆蓋，開發用的Linux安裝在VMware中，使用默認磁盤分區結構，只單獨掛載了/boot和/，用戶數據在/home/user，無法單獨umount這個目錄啊，這也說明了安裝時為什么最好將/home單獨mount為一個設備，找了一些資料后發現更不能輕易變更分區結構了，於是干脆就死馬當活馬醫，准備直接安裝extundelete，不直接修改/home/user的內容，也許文件還有救。
安裝extundelete：
extundelete需要依賴e2fsprogs和e2fslibs，真慶幸當初我把RHEL配置了CentOS的yum，不然又要為了依賴包耗費腦細胞了。。。
yum install e2fsprogs* yum install e2fslibs*
安裝完成后解壓extundelete-0.2.4.tar.bz2，用三步走方法安裝extundelete：
./configure make make install
恢復誤刪的文件：
先用df看一眼/掛載到哪里了，然后直接輸入要恢復文件的目錄：
[edward@www 桌面]$ df -Th
文件系統 類型 容量 已用 可用 已用%% 掛載點
/dev/mapper/VolGroup-lv_root
ext4 18G 6.8G 9.7G 42% /
tmpfs tmpfs 504M 420K 504M 1% /dev/shm
/dev/sda1 ext4 485M 43M 417M 10% /boot
.host:/ vmhgfs 386G 334G 53G 87% /mnt/hgfs
[root@www ~]# extundelete /dev/mapper/VolGroup-lv_root --restore-directory '/home/edward/WtvSKTrans'
extundelete會自動掃描指定目錄下所有已刪除的文件，這里因為我沒有umount根目錄，有一些文件已經被覆蓋\破壞而無法恢復了，慶幸的是都不是什么重要的文件，項目的主要源文件都恢復了，這是最讓我感到欣慰的。
恢復后的文件保存在當前目錄下的RECOVERED_FILES目錄中，不知神馬原因恢復后的文件名凌亂了，具體應該說是文件名錯位了，不過這已經是最好的結果了，真心感謝extundelete的作者。
事后思考：
用rm -rf時必須保持清醒的頭腦，這個前面已經說過了，不然后果就是心驚肉跳，如果再因為數據恢復不了出了業務事故而丟了工作，那可太得不償失了。從防范的角度，不如把rm -rf這個命令換成mv .trash，google找到了一些用腳本改寫rm的方法，但是實際嘗試后發現不盡人意，於是找到了trash-cli命令行回收站，trash-cli能將rm與圖形界面回收站結合，既直觀又安全，使用方法請參考我的這篇博文。
參考資料（感謝原作者分享）：