Skip to main content
search

為什麼恢復已刪除的Ext文件很困難

By 2018-09-194 4 月, 2019未分類

為什麼恢復已刪除的Ext3文件很困難

我們以前都做過。您不小心輸入了錯誤的rm參數或選擇了錯誤的文件進行刪除。當你按下Enter鍵時，你會注意到你的錯誤，你的胃就會下降。您可以到達系統備份並意識到沒有系統備份。

有許多用於FAT和NTFS文件系統的取消刪除工具，但Ext3很少，這是目前大多數Linux發行版的默認文件系統。這是因為Ext3文件被刪除的方式。存儲文件內容所在位置的關鍵信息在刪除過程中會被清除。

在本文中，我們將簡要介紹為什麼難以進行恢復，並研究一些有時有效的方法。我們將使用一些開源工具進行恢復，但這些技術並非完全自動化。
http://linux.sys-con.com/node/117909/mobile

什麼是文件？
在我們看到如何恢復文件之前，我們需要查看文件的存儲方式。通常，文件系統位於磁盤分區內。分區通常組織為512字節扇區。當分區格式化為Ext3時，連續扇區將被分組為塊，其大小範圍為1,024到4,096字節。這些塊被組合成塊組，塊的大小將是數万個塊。每個文件都有數據存儲在三個主要位置：塊，索引節點和目錄條目。文件內容存儲在塊中，這些塊被分配用於文件的專用。根據需要為文件分配多個塊。理想情況下，文件將被分配連續的塊，但這並不總是可行的。

該文件的元數據存儲在inode結構中，該結構位於塊組開頭的inode表中。存在有限數量的inode，每個inode都分配給一個塊組。文件元數據包括時間數據，例如上次修改，上次訪問，上次更改和刪除的時間。元數據還包括存儲文件內容的文件大小，用戶ID，組ID，權限和塊地址。

前12個塊的地址保存在inode中，其他地址存儲在外部的塊中，稱為間接塊。如果文件需要許多塊而並非所有地址都可以放入一個間接塊，則使用雙重間接塊，其地址在inode中給出。雙重間接塊包含單個間接塊的地址，其中包含具有文件內容的塊的地址。inode中還有一個三重間接地址，它增加了一層指針。

最後，文件的名稱存儲在目錄條目結構中，該結構位於分配給文件父目錄的塊中。Ext3目錄類似於文件，其塊包含目錄條目結構列表，每個目錄條目結構包含文件名和存儲文件元數據的inode地址。使用ls -i命令時，可以看到與每個文件名對應的inode地址。我們可以看到目錄條目，inode和圖1中的塊之間的關係。

創建新文件時，操作系統（OS）可以選擇為文件分配的塊和inode。Linux將嘗試在與其父目錄相同的塊組中分配塊和inode。這會導致同一目錄中的文件靠近在一起。稍後我們將使用此事實來限制我們搜索已刪除數據的位置。

Ext3文件系統具有一個日誌，用於在更新發生之前記錄文件系統元數據的更新。在系統崩潰的情況下，操作系統會讀取日誌，並將重新處理或回滾日誌中的事務，以便恢復速度更快，然後檢查每個元數據結構，這是舊的和緩慢的方式。示例元數據結構包括存儲文件名的目錄條目和存儲文件元數據的inode。日誌包含正在更新的完整塊，而不僅僅是要更改的值。創建新文件時，日誌應包含包含目錄條目和inode的塊的更新版本。

刪除過程
從Linux中刪除Ext3文件時會發生一些事情。請記住，操作系統可以準確選擇刪除文件時發生的情況，本文假定一般Linux系統。

操作系統必須至少將每個塊，inode和目錄條目標記為未分配，以便以後的文件可以使用它們。這種最小的方法是幾年前使用Ext2文件系統發生的。在這種情況下，恢復過程相對簡單，因為inode仍然包含文件內容的塊地址，而debugfs和e2undel等工具可以輕鬆地重新創建文件。只要塊沒有分配給新文件並且原始內容沒有被覆蓋，這就可以工作。

使用Ext3，還有一個額外的步驟使恢復變得更加困難。當塊未分配時，inode中的文件大小和塊地址被清除; 因此，我們無法再確定文件內容的位置。我們可以看到目錄條目，inode和圖2中未分配文件的塊之間的關係。

恢復方法
既然我們知道文件涉及的組件以及在刪除過程中清除了哪些組件，我們可以檢查兩種文件恢復方法（除了使用備份）。第一種方法使用已刪除文件的應用程序類型，第二種方法使用日誌中的數據。無論採用何種方法，您都應該停止使用文件系統，因為您可以創建一個覆蓋您嘗試恢復的數據的文件。您可以關閉系統電源並將驅動器作為從驅動器放入另一台Linux計算機或從Linux CD啟動。

這兩種技術的第一步是確定已刪除文件的inode地址。這可以通過debugfs或The Sleuth Kit（TSK）來確定。我將在這裡給出debugfs方法。debugfs附帶大多數Linux發行版，是一個文件系統調試器。要啟動debugfs，您需要知道包含已刪除文件的分區的設備名稱。在我的例子中，我從CD啟動，文件位於/ dev / hda5：

＃debugfs / dev / hda5 
debugfs 1。37（2005年3月21日）
debugfs：

然後我們可以使用cd命令切換到已刪除文件的目錄：

debugfs：cd / home / carrier /

ls -d命令將列出目錄中已分配和已刪除的文件。請記住，目錄條目結構存儲文件的名稱和inode，此列表將為我們提供兩個值，因為在刪除過程中都不會清除它們。刪除的文件的inode地址被“<”和“>”包圍：

debugfs：ls -d 
415848（12）。376097（12）.. 415864（16）.bashrc 
[…] 
<415926>（28）oops.dat

我們試圖恢復的文件是/home/carrier/oops.dat，我們可以看到它以前分配給inode 415,926。“（28）”向我們顯示目錄條目結構長度為28個字節，但我們並不關心。

文件雕刻恢復
第一種恢復技術稱為文件雕刻，它使用已刪除文件中的簽名。許多文件類型在文件頭的第一個字節中具有標準值，並且此恢復技術查找已刪除文件的標頭值以確定文件可能已啟動的位置。例如，JPEG文件以0xffd8開頭，以0xffd9結尾。要恢復已刪除的JPEG文件，我們將查看每個塊的前兩個字節，並在前兩個字節中查找一個帶有0xffd8的字節。當我們找到這樣一個塊時，我們會查找一個包含0xffd9的塊。其間的數據被假定為文件。遺憾的是，並非所有文件類型都具有標準頁腳簽名，因此難以確定結束位置。作為文件雕刻的開源工具的一個例子是最重要的，並且還有幾個商業選項。

我們可以在完整的文件系統上運行最重要的工具，但我們可能最終會得到太多文件，包括已分配的文件。因此，我們希望盡可能少地運行它。我們可以限制數據大小的第一種方法是僅檢查文件所在的塊組。請記住，如果有空間，文件的inode和塊將分配給同一個塊組。在我們的例子中，我們知道文件使用了哪個inode，因此我們只能檢查同一組中的塊。debugfs中的imap命令將告訴我們inode屬於哪個塊組：

debugfs：imap <415926> 
Inode 415926是塊組25的一部分，
    位於塊819426，偏移量0x0a80

TSK中fsstat命令的輸出也會告訴我們：

#fsstat / dev / hda5 
[…] 
組：25：
   Inode範圍：408801 – 425152 
   Block範圍：819200 – 851967

接下來我們需要確定已刪除文件的塊組中的塊。我們可以在之前的fsstat輸出中看到它們，但是如果我們使用debugfs，我們需要計算範圍。stats命令為我們提供了每組中的塊數：

debugfs：stats 
[…] 
每組塊數：32768 
[…]

由於我們正在查看塊組25，因此塊範圍從819,200（25 * 32,768）到851,967（26 * 32,768-1）。通過只關注這些塊，我們正在尋找128MB而不是完整的文件系統。雖然如果我們在這些塊中找不到文件，我們仍然需要搜索完整的文件系統。

減少我們分析的數據的下一步是從文件系統中提取未分配的塊，因為這是我們刪除的文件所在的位置。debugfs目前不允許我們僅從特定的塊組中提取未分配的空間，因此我們需要使用TSK中的dls工具。

#dls / dev / hda5 819200-851867> /mnt/unalloc.dat

上面的命令將塊組25中的未分配塊保存到名為/mnt/unalloc.dat的文件中。確保此文件位於其他文件系統上，否則您最終可能會覆蓋已刪除的文件。

現在我們可以在未分配的數據上運行最重要的工具。最重要的是只能恢復已配置的文件類型。如果最重要的是沒有已刪除文件類型的標頭簽名，則需要檢查一些類似的文件並自定義配置文件。我們可以按如下方式運行它：

#foremost -d -i /mnt/unalloc.dat -o / mnt / output /

-d選項將嘗試檢測哪些塊是間接塊，並且不會將它們包含在最終輸出文件中。/ mnt / output /目錄將包含可以恢復的文件。如果您的文件不在那裡，則可以將搜索範圍擴展到文件系統中的所有未分配的塊，而不是僅擴展到塊組中的塊。

基於日誌的恢復
嘗試恢復文件的第二種方法是使用日誌。我們已經看到inode更新首先記錄在日誌中，但這裡的重要概念是inode所在的整個塊都記錄在日誌中。因此，當更新一個inode時，日誌將包含存儲在同一塊中的其他inode的副本。我們刪除的文件的inode的先前版本可能存在於日誌中，因為在刪除之前更新了另一個文件。

查找inode以前版本的最簡單方法是在debugfs中使用logdump -i命令：

debugfs：logdump -i <415926> 
Inode 415926在組25，塊819426，偏移2688 
Journal在塊1開始，事務104588 
  FS塊819426記錄在序列104940，日誌塊2687 
   （inode塊為inode 415926）：
   Inode：415926類型：常規模式：0664標誌：0x0 
   用戶：500組：500大小：2048000 
   […] 
   塊：（0 + 12）：843274（IND）：843286 
[…]

在這種情況下，我們發現inode的前一個副本和文件內容塊列在最後一行。最後一行顯示文件的第一個塊是843,274，文件系統中接下來的12個塊是文件中接下來的12個塊。該文件很大並且需要間接塊，該塊位於塊843,286中。到目前為止，所有塊都是連續的，沒有碎片。塊843,286包含其餘的塊地址，因此我們應該嘗試查看以前的版本以了解文件的其餘部分所在的位置。我們可以使用logdump -b查看日誌中是否有副本：

debugfs：logdump -b 843286 -c

不幸的是，我們沒有找到包含原始塊指針列表的塊的副本，因此，如果我們想要恢復文件，我們需要假設剩餘的文件內容存儲在塊843,287及之後。更高級的方法還將考慮當前分配哪些塊並跳過這些塊。可以使用dd或Linux Disk Editor等工具提取數據。也可以使用TSK的jls和jcat工具搜索日誌。

結束語
使用Ext3進行文件恢復並不是一件小事，這強化了備份重要文件的概念。如果文件沒有碎片，那麼搜索其頭部簽名可能很有用，但工具需要知道忽略間接塊以及停止複制的位置（並非所有文件都有標準的頁腳簽名）。將搜索限制為本地塊組有助於節省時間。如果最近更新了已刪除文件附近的文件並且存在以前版本的inode，則該日誌可能很有用，但這並不總能得到保證，並且文件的間接塊可能不存在。

參考文獻和參考書目

Thx Chang

Author Thx Chang

More posts by Thx Chang
Close Menu
    /* 2024/5/10 */