最近遇到的有系統(tǒng)被全盤（ext4）刪除的案例，拿到了被刪除的系統(tǒng)鏡像，該文件系統(tǒng)受損程度是很大的，正好把Linux大部分的數(shù)據(jù)恢復(fù)工具都測評一遍，看看極端場景下的各類數(shù)據(jù)恢復(fù)工具的表現(xiàn)情況。

Linux 數(shù)據(jù)恢復(fù)工具集

• debugfs
• testdisk
• extundelete
• R-Studio
• DiskGenius
• X-ways Forensics

恢復(fù)前準(zhǔn)備

我們拿到的是Linux的系統(tǒng)盤鏡像，根據(jù)不同的恢復(fù)場景分別進(jìn)行不同操作。

進(jìn)入救援模式

如果是采用Linux下的數(shù)據(jù)恢復(fù)工具，就用鏡像生成實例后直接進(jìn)入救援模式。

系統(tǒng)盤拷貝，重新掛載到Windows實例下

如果要用Windows的數(shù)據(jù)恢復(fù)工具，就會相對麻煩一些。

由于云上不支持將系統(tǒng)盤作為數(shù)據(jù)盤掛載，所以需要先將系統(tǒng)盤拷貝在數(shù)據(jù)盤上（這個功能還沒正式開放，需提工單申請），再重新掛載到Windows的實例上。

debugfs

這里用的并不是系統(tǒng)自帶的debugfs，而是我在debugfs 1.42.7源碼基礎(chǔ)上做了大量修改后專門用于應(yīng)急取證的版本。

根據(jù)文件內(nèi)容特征恢復(fù)文件

例如 ~/.bash_history 文件是帶有時間戳的特征，因此可以把時間戳作為關(guān)鍵詞進(jìn)行搜索。

./debugfs /dev/vda1 -R 'dump_unused -k '#169' -v ' | tee history-recover.log

對于ssh日志包含2023-09-01這類時間的文件，也很容易恢復(fù)。

./debugfs /dev/vda1 -R 'dump_unused -k '2023-08-31 ' -v' | tee 2023-08-31.log

注意：用debugfs恢復(fù)出來的并不是一個完整的文件，而是包含文件內(nèi)容特征的碎片！僅適用于溯源取證的場景。

testdisk

只能列出根目錄，完全無法恢復(fù)文件或者數(shù)據(jù)。

extundelete

和testdisk一樣，都能識別到根目錄但是都無法恢復(fù)文件。

inode 為2表示為Linux下的根目錄。

嘗試對磁盤文件全部文件恢復(fù)。

直接報錯，還是無法恢復(fù)文件。

R-Studio

R-Studio的表現(xiàn)相對出色，雖然部分目錄文件未能識別到，但是對于已識別的文件目錄也會顯示哪些文件可恢復(fù)以及恢復(fù)的概率。

然后會顯示可恢復(fù)的目錄文件。

雖然大部分文件依舊顯示empty（無法恢復(fù)），但是相比上面的兩個工具完全無法恢復(fù)已經(jīng)好很多了。

DiskGenius

雖然DiskGenius可以按照從磁盤的中掃描出來的文件類型進(jìn)行分類并且可以預(yù)覽，但是對應(yīng)已經(jīng)丟失的目錄還是無法識別到，感覺用處不大。

X-ways Forensics

x-ways掃描完成后可以識別到完整的根目錄，但是無法成功恢復(fù)文件，也有可能是我使用的方式不對。

總結(jié)

由于文件系統(tǒng)受損嚴(yán)重，大部分的數(shù)據(jù)恢復(fù)工具表現(xiàn)都不佳。從結(jié)果來看，最簡單好用且恢復(fù)文件最多的還是R-Studio，后續(xù)可以考慮作為數(shù)據(jù)恢復(fù)的優(yōu)先選擇工具。