我需要從某些2 TB 大型硬碟中拯救數據，並且正在某些VM 中的某些Live-Linux 中執行此操作，其中有問題的硬碟使用USB 3 連接，並且VM 在本地提供所需大小的虛擬磁碟接收資料。然後我執行了以下調用，只是為了看看事情進展如何：
ddrescue -f /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
sdc是USB損壞的設備，sdb是接收資料的虛擬磁碟，sda1用於暫時存儲，使用Ext4格式化。
一切開始快速運轉，ddrescue能夠在幾分鐘內讀取約 45 GB 的數據，然後速度大幅減慢，連續幾天只能以每秒幾個位元組的速度讀取。因此，設備的這些部分顯然已損壞，我嘗試簡單地跳過那些使用不同的多次呼叫的部分--input-position=[...]GB。根據我跳到的位置，內容開始再次快速讀取，直到它們再次變慢，我使用另一個呼叫再次跳轉。需要注意的是，列印的輸入和輸出位置ddrescue始終是同步的！我也沒有手動更改所提供的地圖文件中的任何內容，也沒有刪除它或其他任何內容，它始終是同一個文件，並且僅由其ddrescue自身管理。
後來我稍微改變了方法，決定不再--input-position手動使用，而是使用以下方法：
ddrescue -f --min-read-rate=1MB --skip-size=1MB /dev/sdc /dev/sdb /mnt/sda1/ddrescue.map
因此，每當ddrescue識別出緩慢的部分時，它就會跳過合理的損壞資料塊並繼續讀取。同樣，輸入和輸出位置同步，並且讀取和救援資料的計數器一直增加。到目前為止，我們已經ddrescue完成並據說已經挽救了約 650 GB 的數據。
問題是，最終查看虛擬磁碟檔案本身後，似乎實際上只儲存了約 160 GB 的資料。此外，上次寫入時間戳已經太舊了幾天。因此，出於某種原因，ddrescue我認為它正在讀取大量數據，但似乎沒有將其正確寫入虛擬磁碟中從損壞磁碟讀取資料的位置。最後，根據我的理解，虛擬磁碟應該至少具有ddrescue與它所保存的資料量相關的大小。
我有一種感覺，ddrescue正確讀取了它所說的所有數據，但只是在後續調用中覆蓋了已經保存的數據。因此，雖然我猜測它可以識別--input-position讀取，但它似乎總是從目標位置 0 開始寫入。
顯然我沒有指定寫入資料的起始位置，但是根據文件這應該是沒有必要的，並且ddrescue無論如何列印的輸入和輸出位置總是相同的。
-o bytes
--output-position=bytes
Starting position of the image of the rescue domain in outfile, in bytes.
Defaults to '--input-position'. The bytes below bytes aren't touched if
they exist and truncation is not requested. Else they are set to 0.
當然，我沒有請求截斷，根據文檔，它默認情況下未啟用，甚至不適用於我指定的目標驅動器：
-t
--truncate
Truncate outfile to zero size before writing to it. Only works for regular
files, not for drives or partitions.
那麼，知道可能出了什麼問題嗎？我多次調用不同值的--input-position錯誤已經發生了嗎？它是否與讀取和寫入驅動器而不是分區或檔案有關？
也許寫入某些虛擬磁碟時出現問題？儘管我不明白為什麼這會產生任何影響，並且我需要寫入某些虛擬磁碟並且無法提供所需大小的原始設備儲存。
謝謝！
答案1
使用多個不同的 ddrescue 是否安全
--input-position？
似乎我之前錯過了這個例子，但這實際上是我所做的，它表明我的方法受到支持：
Example 5: While rescuing a partition in /dev/sda1 to the file hdimage, /dev/sda1 stops responding and begins returning read errors, causing ddrescue to mark the rest of the partition as non-scraped.
ddrescue -n /dev/sda1 hdimage mapfile <-- /dev/sda1 fails here
(restart /dev/sda or reboot computer)
ddrescue -n -A -i<pos> -O /dev/sda1 hdimage mapfile
(if /dev/sda1 fails again, restart /dev/sda or reboot computer and
then repeat the above command as many times as needed until it
succeeds. <pos> is the position where the drive stopped responding)
ddrescue -d -r3 /dev/sda1 hdimage mapfile
https://www.gnu.org/software/ddrescue/manual/ddrescue_manual.html#Examples
清楚地記錄了第二次呼叫以不同的位置重複。關於如何ddrescue使用其映射文件，這也是有道理的，因為它總是知道使用該文件哪些區塊已被讀取。
因此，我的情況下的問題很可能是不同的，特別是我認為我認識到的太舊的時間戳很奇怪。也許我只是錯過了ddrescue由於某種原因未寫入真實目標設備的訊息。 VM 本身也在另一個 USB 驅動器上，可能存在一些連接錯誤導致 Live-Linux 在運行時丟失設備等。dmesg -T由於記錄了所有讀取錯誤，我可能很容易錯過此類錯誤。
聽起來我需要重複整個過程...
答案2
我讀了ddrescue手冊，沒有任何地方提到多個input-position參數的可能性。
這個參數總是被稱為“a”或“the”，所以看起來它必須是唯一的。
您的問題的根源可能是手冊中的這句話：
請注意，您必須保留原始救援運行的「--input-position」和「--output-position」之間的原始偏移。
這似乎與以下其他段落一致：
當 Ddrescue 在輸入中發現壞扇區時，不會將零寫入輸出，並且如果沒有要求，也不會截斷輸出檔案。因此，每次在同一個輸出檔案上運行它時，它都會嘗試填補空白，而不會擦除已儲存的資料。
這意味著它ddrescue會記住第一次運行時的參數，因此您始終應該保留相同的參數，或者可能只是不在後續運行中指定它們（我不能說哪個是正確的）。完全有可能某些參數被記住，而您的新參數在接下來的運行中被忽略。
如果磁碟元表的某些部分損壞，您看到的資料可能比實際搶救的資料少，因為似乎沒有檔案包含這些部分。
無法挽救的資料ddrescue需要透過其他恢復產品來恢復。這可能需要很長時間，對於您所使用的產品來說甚至可能是不可能的。如果確實需要恢復數據，專業的恢復公司也許可以從原始磁碟上進行恢復，但這些服務的成本很高。
答案3
由於 的手冊頁很長，根據目標和使用者等級的不同，ddrescue其使用也有很大不同。ddrescue基本上，如果你使用Live Linux，你最好在物理機而不是虛擬機器上運行它，並且將磁碟連接到sATA，而不需要任何sATA/USB適配器。
其他功能ddrescue可以繞過核心磁碟驅動程式和緩衝區，因此可以減少對壞簇的無用重複讀取。映射檔案（以前稱為日誌檔案）保留有關所有未/成功讀取叢集的信息，這就是為什麼您可以簡單地重複崩潰的步驟。在開始作業之前查找ddrescue映射文件，創建它，如果不存在，則讀取它，如果可用，並開始在最後記錄的位置繼續救援作業。您無需在每次程式崩潰時手動移動起始位置！
您可以使用各種選項使救援過程更快、更安全。您也可以（並建議）分兩個或更多步驟進行救援流程：
第一步：快速讀取好的簇並立即跳過壞的簇。
第二步：處理上一步驟中未讀的簇，並使用特殊選項來欺騙磁碟功能（NCQ、預讀...），以便一次讀取一個磁區。足夠的命令（我使用）：
ddrescue -n -p -d -r1 /dev/sdd $IMGPATH/disk.img $IMGPATH/disk.log;
ddrescue -d -r3 -R /dev/sdd $IMGPATH/disk.img $IMGPATH/disk.log;
# | | | | |
# | | | | revers reading
# | | | retry read 1x (3x)
# | | direct access to disk (bypass the kernel)
# | preallocate diskspace
# nonscrap
如果您的磁碟過熱或不喜歡太多讀取操作/秒，您可以使用以下選項減慢讀取速度：--max-read-rate=50M
因此，這只是第一次接觸，但您可以在專門的俱樂部或論壇上找到許多與ddrescue.