大家都知道，在linux系統中是沒有回收站的概念的，一旦rm命令刪除某個文件之後，就找不回來。不過其實這時還是有救的，之前大概清楚個概念，知道有救，但如何救就沒怎麼詳細去了解了。那麼這次我們來實際操作下。
其實爲什麼說還有救呢？說這個之前需要對ext3文件系統有個大概的瞭解。
在ext3文件系統中我們創建一個文件時，它首先會在ext3文件系統的inode表申請個inode號，然後再將文件的信息以及數據寫入。那麼inode號又是什麼呢？
inode號裏面包括兩部分，一個是metadata，即是元數據，簡單理解就是這個文件的文件名，大小，權限，訪問時間等等，也就是除了這個文件的內容數據之外的信息。
如圖，創建了一個新文件“testfile”，我們可以用stat命令來查看它的信息；
另一個是一個 pointer 指針。該指針指向真正的數據存放的block數據區。所以通常在我們查看一個文件內容時，我們通過文件名找到對應的inode號，然後再通過這個inode號裏面的指針，再找到真正的數據。
而一個文件對應一個inode號，無論文件小到1，2K還是大到1，2GB都一樣。在我們創建文件系統時，就會自動創建inode表，我們的inode號也就屬於，來自於這個inode表。當然默認的inode表也是有大小的。達到了默認的上限值後，我們就無法創建文件咯。
我們可以通過“df -i”這個命令去查看，每個文件系統的inode的使用情況。通常按照默認的劃分都夠用了。當然如果你的服務器專門處理些小郵件，小文件的，你可以適當調整inode表的大小，讓它更大一些。
如圖，我們可以看到各文件系統的inode的總數量，以及使用了多少，剩餘多少，以及佔用的百分比；
那麼當我們執行命令，“rm -f testfile” 時，這時其實刪除的只是對應這個文件的文件名與其inode的關聯，數據其實還在，同時這個文件之前所佔用的inode號被標記爲可用狀態，所以這個使用就不要再創建新的文件了，也就是對這個文件系統不要做任何動作，我想這個大家也都清楚。因爲如果再創建新的文件，在ext3文件系統中，新的文件會複用之前被標記爲可用狀態的inode號，而這時你的數據也就岌岌可危了。
如上圖，test文件inode號爲98315，而刪除之後，再建立個新的文件，它的inode號使用了之前空餘出的相同的inode號。當然這個在不同文件系統是不同的，例如在redhat的GFS文件系統中，被刪的文件的inode號是會保留下來的，新的文件會用新的inode號。當然在GFS中也可以通過命令的形式去清空無效被刪的inode號，將其還原成可被用的狀態。
那麼我們現在知道數據還是存在的，那麼接着我們如何來恢復呢？
首先我們需要一個恢復數據的工具，所謂工欲善其事，必先利其器；
我們來下載，編譯下這個ext3grep軟件先吧，當然前提要安裝好gcc噢！
wget http://ext3grep.googlecode.com/files/ext3grep-0.10.1.tar.gz
tar -zxvf ext3grep-0.10.1.tar.gz
cd ext3grep-0.10.1
./configure
make
make install
安裝好後，我們就先在準備下環境，單獨掛載個文件系統，在刪除個文件。這時我們看到之前文件的inode號爲8052。在處理前，我們需要先卸載該文件系統。
但若因某進程，持續訪問該文件系統，無法卸載，可通過以下方式：
kill掉正在使用這個目錄的進程：
fuser -k /test
當然，這樣做如果你不好確保是否安全的話，可以先運行lsof這個命令，來查看所以連接到這個目錄的進程：
lsof +D /test
確認好了然後再kill掉。
我們首先執行“ext3grep /dev/sdb1 --ls --inode 2
/dev/sdb1 是我之前卸載的ext3文件系統
--inode 2 的意思是指定從/dev/sdb1的文件系統的root根來尋找
這時我們從上圖黃色標識的地方找到了web目錄的inode號，然後我們接着對web目錄的inode號來搜索，當然這裏還顯示了一個之前刪除的文件web.txt。
如上圖，我們可以看到webfile和它的inode號，8052。
然後指定相關路徑，以及被刪的文件。
當我們看到 Restoring web/webfile時，說明已經成功恢復了。
接着在執行命令的當前目錄下找到RESTORED_FILES目錄下的對應目錄的被刪文件，然後我們可以看到被刪文件的內容和之前一樣。
然後我們再將之前的/dev/sdb1掛載起來。
這時我們可以看到在該目錄的文件已經被恢復成功了。