extundelete

DR 合理的推測，自己這輩子應該根除不了刪檔案快、狠、卻不太準的惡習……

今天動用到了 extundelete 這支針對 ext3/ext4 檔案系統的反刪除工具，雖然最後沒能把檔案救回，但還是在這邊做一點記錄。話說 DR 要在某部伺服器上做一支監控程式，於是就直接 SSH 遠端登入後用 Vim 編輯器來寫。DR 在這支程式裡設計了建立 *.pid 檔的機制，目的是要避免動作的重複執行，而悲劇就發生在當 DR 想要手動 rm 掉 *.pid 時，竟然手誤把 *.py 給 rm 掉了……

雖然損失的不是整支程式，因為另一部伺服器上的 Git 系統還有上週五所提交的備份，卻還是損失了今天早上一、兩個小時下來腦力激盪的成果，所以 DR 的第一個反應就是想把檔案救回來。然而在開始思考對策之後才意識到這部伺服器的配置可說是讓資料救援越顯困難，因為：

1. 刪除的檔案是在 /home 裡，然而 /home 和根目錄使用相同的分割區，所以無法在本機上只卸載 /home，然後進行救援作業。從這個案例來看，不把 /home 分出來顯然是大錯……
2. 這部伺服器其實是 VMware ESXi 虛擬化主機上的其中一部虛擬機，不能動輒用拆硬碟的動作來處理，若考慮更進階的方案，在時效性上還不如直接重寫。

總而言之，DR 還是硬著頭皮直接下載最新的 extundelete 0.2.4 版，想說硬跑看看有沒有機會救回來。在 CentOS 6.4 上編譯時需要先安裝 e2fsprogs-devel 套件，不過 DR 在執行 make 時還是碰到一個很奇怪的錯誤：「configure.ac:10: error: AC_INIT should be called with package and version arguments」，網路上搜了幾篇教學文章以及郵件列表都沒有反應類似的錯誤。由於那些文章多半用的是 0.2.0 版，所以 DR 拿 0.2.4 和 0.2.0 的 configure.ac 兩相對照之下，索性把：

AC_INIT(extundelete, EU_VERSION, extundelete.sourceforge.net)

改成：

AC_INIT(extundelete, 0.2.4, extundelete.sourceforge.net)

再重新執行 configure 和 make 就可以順利編譯完畢，接著在無卸載的情況下直接執行 extundelete，已經找不到被誤刪的檔案。不過既然是在沒有卸載、沒有避免磁碟持續寫入的情況下，這樣的結果是可想而知的。

接下來怎麼辦呢？就是回頭繼續寫程式了，後來 DR 做的第一項改動就是把 *.py 跟 *.pid 的目錄分開……