兩天前，我開始恢復一個 1TB 故障硬碟，這是別人送給我的，希望我能以便宜的價格搶救大部分硬碟。
起初它表現得很不穩定，經常突然斷開連接並發出可怕的噪音，複製速度在每秒幾KB到每秒大約50MB之間變化（天氣很熱，我試圖用筆記型電腦散熱墊防止它過熱）下面和上面有一個冷卻塊，我大約每小時更換一次）。然後，在第一個晚上，它變得更加穩定，但平均複製速度顯著下降，降至 3-4MB/s 左右。現在，恢復了 250GB 後，平均速度下降到了 400KB/s 左右，速度慢得令人痛苦（至少看起來沒有進一步下降）。
所以我的問題是：
- 我正在對 NTFS 分區進行恢復，根據我在該過程的後期讀到的內容（在這本法文指南），不建議這樣做，因為它可能會大大減慢恢復速度。這（仍然）是真的嗎？
- 或者這已經成為過去，當時 Linux 的 NTFS 驅動程式還不夠成熟？ （我使用的是最新的 Knoppix live DVD，複製到記憶卡，因為它無法從 DVD-RW 成功啟動。）
- 在此階段是否值得將分割區轉換為原生 Linux 格式（如 Ext4）？我的意思是，它會顯著提高複製速度嗎？
- 或者，在大多數「健康」扇區已經恢復的第一遍之後，故障的驅動器出現如此緩慢的速度是否正常？ （SMART參數惡化，“整體健康自我評估測試結果”從“通過”變為“失敗”，重新分配的扇區數量從144個增加到1360個。）
- 我還可以採取其他措施來提高恢復率和/或恢復速度嗎？
- 有哪些選項
ddrescue我可以嘗試並獲得一些真正的好處？
我用這個命令進行了第一次運行：
ddrescue -n -N -a500000 -K1048576 -u /dev/sdc /media/sda1/Hitachi1TB /media/sda1/Hitachi1TB.log
（-n&-N開關據說繞過了抓取和修剪階段 - 儘管我不確定程式在過程中的哪個點嘗試這些操作，以及這是否確實有助於繞過它們。然後我指定了 500000 的最低複製速度每秒位元組數，「讀取錯誤時跳過的初始大小」值為1MB，嘗試盡快複製仍然正常或易於存取的區域，這-u是「單向」：在先前的恢復中。反向複製-R似乎可以改善問題，但使用這個硬碟似乎會造成嚴重破壞，並且使用該開關顯然更穩定。
現在，在完成一輪後，我刪除了大部分參數，只保留-u.我-d在某個時候嘗試過切換（“使用直接光碟存取”），但隨後沒有複製任何內容，“錯誤大小”增長得非常快。
答案1
完成我上面的評論（對於正式的不便/不一致表示抱歉）：我想說這是值得的，儘管我不太明白為什麼。第二次嘗試，恢復到 Ext4 分區，一開始的複製速率明顯更高（平均大約 90 MB/s，而我第一次嘗試恢復到 NTFS 分區時最多只有大約 50 MB/s） ，並且沒有錯誤，甚至沒有速度減慢。但是，在複製了大約165 GB 後（比以前更早），它變得非常不穩定，速度慢得像爬行一樣，再次發出咔噠聲和呼呼聲（這是一個非常熱的時期，這沒有幫助–我試著冷卻它）盡可能向下，使用下面的筆記型電腦冷卻墊和上面的冷凍包，大約每小時更換一次）；我一次又一次地嘗試（有時它會回到 120 MB/s 的速率幾秒鐘，然後又回到 0），但過了一段時間我不得不放棄它。
這是ddrescueview第一次恢復的地圖：
有一個有趣的模式，易於恢復的資料條帶與非常慢或不可讀的資料交替出現。[據我所知，這似乎表明磁頭與盤片接觸，損壞了表面並釋放出磁性灰塵，然後磁性灰塵在離心力的作用下擴散。由於伺服磁軌（包含啟動過程的基本資訊）位於硬碟（3.5 吋日立 1 TB）的外緣，因此一些灰塵可能已經到達它，使其難以訪問，這可以解釋啟動時頻繁發出的咔嗒聲。（如果我錯了，請糾正我。）=> [編輯20200501] 那是錯誤的，實際上這種模式通常表明驅動器的一個磁頭完全失效並且不再讀取任何內容，盤片上的數據可能仍然可讀取此時，需要更換磁頭堆疊組件，只有專門的資料復原實驗室才能安全地執行此操作。
這是ddrescueview第二次恢復的地圖：
所以硬碟變得非常不穩定，大約165 GB之後恢復變得越來越困難，但在此之前複製率一直很高，沒有跳過區域。我後來ddru_ntfsbitmap在最後一次嘗試中使用了該方法，因此未分配的空間大部分被跳過。
以下是ddrescueview使用 建立的日誌檔案的映射ddru_ntfsbitmap，其中以綠色顯示包含實際資料的硬碟區域，以灰色顯示可用空間：
幸運的是，大部分實際資料位於第一季並成功復原。現在我還沒有將這兩個圖像的好的部分結合起來，並提取實際的文件，可能是使用 R-Studio（我嘗試過的最好的數據恢復軟體）。
關於我最初的問題，我後來發現一件有趣且奇特的事情（我想我應該根據正式規則將其作為評論，但它太長了，我無法提供屏幕截圖） 。
我嘗試將 Ext4 分割區上的映像 2 的救援區域（映像 1 中缺失）複製到 NTFS 分割區{1}上的映像 1 ，這應該以非常高的速率完成（輸入和輸出（在健康的2 TB HDD 上），但我得到的平均速度僅為660 KB/s，因此非常接近後期初始恢復的速度，當時我非常關心並首先提出這個問題。
使用的命令（圖像 2 的日誌檔案用作域日誌檔案）：
ddrescue -m [image2.log] [image2] [image1] [image1.log]
螢幕截圖:
所以我停下來做了相反的事情：我將圖像 1 (NTFS) 中在圖像 2 (Ext4) 中丟失的救援區域複製到圖像 2 - 現在複製速率約為 43000 KB/s 或 43 MB/s平均而言（可能比在同一HDD 上進行副本的預期稍慢，對於最大寫入速度接近200 MB/s 的Seagate 2 TB，因此應該能夠達到大約100 MB/s）從一個分區複製到另一個分區，但還是比第一次嘗試好近100 倍）。如此巨大的差異該如何解釋呢？
使用的命令（圖像 1 的日誌檔案用作域日誌檔案）：
ddrescue -m [image1.log] [image1] [image2] [image2.log]
螢幕截圖:
我注意到兩個分割區上的映像檔都有一個「磁碟大小」 {2}，與實際寫入的資料量相對應，與總大小（1 TB 或 931.5 GB）相去甚遠，儘管我沒有這樣做t 使用-S開關（「對輸出檔案使用稀疏寫入」）。映像 2（使用映像 1 中的額外救援區域完成後）的「磁碟大小」為 308.5 GB，而映像 1 的「磁碟大小」為 259.8 GB。如果 Linux NTFS 驅動程式在處理稀疏寫入時遇到困難，這是否與複製速度慢有關？考慮到我沒有使用該開關，為什麼在寫入最後的扇區後，整個大小沒有被分配-S？
我嘗試-p在過程的一開始就使用開關（“預先分配”），認為這樣會“更乾淨”、更直接、更容易處理，以防出現問題（如果需要恢復的話）。不要停下來，因為它太長了，我想盡快開始（顯然它實際上寫入了空數據，而不是簡單地分配所需的扇區）。然後我發現，透過-R暫時使用開關（“反向”），它會將最後一個磁區寫入輸出文件，從而按照我的預期分配完整大小；它確實導致輸出檔案的大小增加到931.5 GB，但「磁碟上的大小」實際上要小得多（後來我在Windows 上存取用於該復原的HDD 時注意到這一點，並看到異常高的可用空間量）空間）。
________________
{1} 我仍然不明白第二次恢復嘗試如何能夠為前 100 GB 左右產生更好的結果，儘管 HDD 的健康狀況在此期間已經下降。 [EDIT 20200501] => 可能是因為a500000最初使用的參數，跳過了讀取速度低於 500KB/s 閾值的區域。如果沒有這個選項，第二次，它會立即讀取速度較慢的區域。事實上，那些速度較慢的區域與一個較弱的頭部有關，因此，儘管這個失效的頭部已經顯示出故障的跡象，但它在第二次仍能獲得同樣多的數據仍然令人費解。我還在學習...
{2}順便說一下，在 Windows 和 Linux 系統上都應該替換“磁碟”一詞，因為有些資料儲存單元不是“磁碟”...
答案2
您可能需要先複製磁碟映像DD命令
sudo dd bs=[block_size] count=[NofBlocks] if=[in_file] of=[out_file]
在哪裡
[in_file] - 可能是損壞的磁碟，例如 /dev/sdd2
[out_file] - 輸出影像檔案的位置。
- 安裝映像並嘗試恢復它。