☰

使用 ddrescue 恢復損壞的驅動器。我可以在運行完成之前檢查進度嗎？

tag-icon • tag-icon hard-drive hard-drive-recovery ddrescue
使用 ddrescue 恢復損壞的驅動器。我可以在運行完成之前檢查進度嗎？

我目前正在ddrescue一個對我來說失敗的驅動器上運行。現在它已經運行了大約 16 小時，仍然處於分裂失敗塊階段，但已經以 0 B/s 運行了一段時間。我直接複製到另一個驅動器上，而不是製作圖像。

我可以檢查已經取得了什麼進展嗎？故障磁碟機上只有一個我真正需要的項目，我只想檢查這些檔案是否已複製。

我運行的命令是：

ddrescue -d -f -v /dev/sda5 /dev/sdc2 /media/username/USB/rescue.logfile

我在 Ubuntu 上運行，如果重要的話，舊驅動器作業系統是 Arch。

答案1

理論上，您可以終止 ( ctrl+ C)ddrescue並稍後使用相同的日誌檔案運行它，以使其繼續而不是重新開始。我看到一些帖子聲稱這種方法並不總是有效——在這些情況下，ddrescue忽略了以前的工作並出於未知的原因從頭開始。

嘗試以唯讀方式掛載目標分割區：

sudo mount -o ro /dev/sdc2 /mnt/foo

作為唯讀，它不應該幹擾ddrescue操作。存在對檔案系統至關重要的資料尚未恢復的風險，在這種情況下mount將會失敗。如果幸運的話，您可能能夠安裝，然後讀取您需要的文件，但即使您沒有從和mount(例如)中得到任何錯誤，文件也可能已損壞cp。檢查它們或它們的副本。ddrescue除非您確保文件有效且內部沒有未恢復/混亂的碎片，否則請勿終止。

如果出現任何問題，您可以等待ddrescue恢復更多資料（如果有）。我不會等待未損壞的檔案出現在掛載點下，因為系統可能會快取元資料或檔案本身umount等mount。

編輯：回答其他問題。

有沒有辦法告訴 ddrescue 指定特定資料夾？

不會。它對檔案系統和檔案一無所知。你的陳述「ddrescuelog 說我的文件的 99.73% 已被恢復」應該說「99.73% 的區塊」。

另外，是否有可能資料已經恢復，因為它說99.73%已獲救，但它損壞得太嚴重而無法被識別為檔案？如果是這種情況，是否有一些程式可以查看損壞的文件，也許我可以手動恢復其中一些。

可能的情況：文件內容已恢復，但相應的文件系統條目未恢復（注意：通常相反的情況也是可能的，但顯然不是您的情況）。你說整個資料夾都消失了。我認為某些文件可能會出現在lost+found之後fsck（或以類似的方式出現，這取決於您的文件系統 - 我不知道它是什麼）。

更多資訊請點這裡：Linux 和 Unix 中的lost+found 資料夾的用途是什麼？

該fsck操作不是唯讀的，不應該在ddrescue工作時執行。終止ddrescue、運作fsck和恢復ddrescue也是一件壞事。最好等待ddrescue完成。可能需要一些時間 - 閱讀這和這。

一般來說，您應該使用fsck（或任何其他非唯讀工具）來處理復原的資料的副本。不錯的方法，供以後參考：

  1. 寫入文件，而不是設備。使用檔案系統寫入時複製 (COW)特徵。
  2. 做一個乳牛複製與cp --reflink=always.您可以在ddrescue操作期間執行此操作。該副本就像目標檔案的快照。
  3. 使用副本上的任何工具，包括非唯讀工具。
  4. 如果發生故障，您仍然擁有原始目標檔案（如果ddrescue仍在運行，可能會恢復更多資料）以從另一個開始乳牛複製（也許使用不同的工具）。

您也可以嘗試搜尋已刪除的檔案並取消刪除。工具的選擇取決於檔案系統。

另一個提示：也許您的軟體正在檔案系統層次結構中的其他位置使用臨時檔案。查看/tmp/，/var/tmp/。

編輯，回答附加問題。

當 ddrescuelog 說 99.73% 的區塊已被拯救時，這到底意味著什麼？聽起來我應該期待一些結果而不是空的家庭驅動器。

注意：下面的範例並不意味著涵蓋所有檔案系統問題和場景，也不意味著區分磁碟區和檔案系統分配單元；它只是回答問題。

想像你的分區是一本書──一本百科全書，而不是一本有情節的小說。文件是其中的文章。磁碟塊（或磁區）就像書中的一頁。檔案系統是在頁面上放置文章的通用方法。有些頁麵包含目錄 (ToC)這是我們圖片中的檔案系統問題，可能看起來像這樣：

文章#289：第 2076、2077、2078、402、403 頁。

請注意，本文是碎片化的文件。在另一頁上，但仍在其中目錄我們有類似的資料夾結構：

…
people/： 看目錄
第
43
mathematicians/頁。目錄第 80 頁
famous Poles/：參見目錄第 82 頁
Adam and Eve。
…
（第 80 頁）
Euclid：請參閱文章#289。
Banach Stefan：參見文章#4380。
…
（第 82 頁）
Banach Stefan：請參閱文章 #4380。
Kościuszko Tadeusz：參見文章#2208。
……

此結構是硬連結檔案的範例。至少有兩條路徑指向一篇文章：./people/mathematicians/Banach Stefan和./people/famous Poles/Banach Stefan。這裡我在每個路徑的開頭放置了點，因為我的範例故意隱藏了資訊：people/節屬於哪個部分？ （也可以是/people/或/full articles/people/或/stubs/people/或/foo/bar/people/）。

這目錄可能還有一個部分說：

「空」頁：567、568、569、2070、2071…

給定頁面上有文字（即數據），即使它不屬於同時存在的任何文章。這是因為文章刪除過程僅影響目錄。這目錄是判斷給定頁面是否屬於某篇文章、哪篇文章或可以將其視為空並被覆蓋的唯一確定方法。另外：沒有辦法發現“空頁”目錄。對於百科全書來說，將空白頁作為文章的一部分感覺很奇怪，但充滿0s 或空格或其他任何內容的扇區可以作為文件的一部分。這全都是關於目錄。

您的某些頁面（區塊）尚未被拯救。其中任何一個都可能是包含文章資料的頁面或托克-元資料。可能性：

  • 缺少的區塊是資料區塊（例如，第 2078 頁）。您知道有關歐幾裡得的文章的路徑以及它所在的頁面，但其中一頁是空白的，而它不應該是空白的。文章無效。
  • 缺少的區塊是元資料塊。一些場景：
    • 您忘記了可用空間。
    • 您知道存在./people/mathematicians/Euclid路徑，但不知道該文章位於哪些頁面。除非您已經了解該文章，否則不可能找到該文章（例如，有關某人的條目中很可能包含“born”一詞；PDF 文件以“%PDF”開頭）。
    • 您知道某某頁面上有一篇文章，但沒有完整的路徑。在這種情況下，您可以將其放在下面lost+found即可fsck。在我們的圖片中存在以下可能性（除其他外）：
      • 缺少第 80 頁：您知道（從第 43 頁）有mathematicians一個部分（資料夾），但您不知道文章 #289 應該位於其中，名稱為「Euclid」。
      • 缺少第 43 頁：你不知道應該有關於亞當和夏娃的文章#14，也不知道數學家或著名波蘭人的部分；但您可以看到（第 80 頁）有一些部分包含有關 Euclid 和 Banach 的文章，還有一些其他部分（第 82 頁）包含有關 Banach 和 Kościuszko 的文章。這就是您的/home.文章（文件）在那裡並且可能有效。他們無法通過路徑到達，因為你沒有托克你的/home。
  • 如果有多個區塊未恢復，則可能會出現上述問題的任意組合。
  • 遺失的區塊可能被標記為空。在這種情況下，你什麼也不會失去。

相關內容