☰

如何找出透過 ddrescue 復原嘗試遺失了哪些檔案？

tag-icon • tag-icon hard-disk data-recovery ddrescue
如何找出透過 ddrescue 復原嘗試遺失了哪些檔案？

我正在從 1 TB 故障硬碟中搶救資料（在更換硬碟的步驟？）。我已經ddrescue從系統救援 USB 中完成了，結果錯誤大小為 557568 B，有 191 個錯誤，可能全部都在/home（我假設所謂的「錯誤」不是壞扇區，而是壞扇區的連續序列）。

現在，我看到的幾個指南建議e2fsck在新磁碟上執行此操作，我希望這會以某種方式發現某些文件已被分配“空白扇區/區塊”，以便至少知道哪些文件無法保存所有的。但根本沒有發現任何錯誤（我運行它沒有-y確保我沒有錯過任何東西）。現在我用 再次運行它-c，但到目前為止 95% 沒有發現錯誤；我想我有一個新驅動器，裡面有一些看起來正常的文件，裡面有歸零或隨機的片段，直到有一天我用相應的軟體打開它們，或者 Linux Mint 需要它們時，才檢測到它們。

我可以對舊/新磁碟機執行任何操作以獲得可能損壞的檔案清單嗎？我不知道有多少個，因為 191 個可以跨文件，但至少總大小不大；我最關心的是一大堆舊的家庭照片和影片（每張 1+ MB），其餘的可能不相關或最近備份過。

更新：e2fsck 的新通道確實提供了一些我一無所知的新內容：

Block bitmap differences:  +231216947 +(231216964--231216965) +231216970 +231217707 +231217852 +(231217870--231217871) +231218486
Fix<y>? yes
Free blocks count wrong for group #7056 (497, counted=488).                    
Fix<y>? yes
Free blocks count wrong (44259598, counted=44259589).
Fix<y>? yes

答案1

您將需要所有遇到的壞塊的塊號（ddrescue應該給您一個列表，我希望您保存它），然後您需要找出哪些文件使用這些塊（參見例如這裡）。如果有很多壞區塊，您可能需要編寫此腳本。

e2fsck沒有幫助，它只是檢查檔案系統本身的一致性，因此它只會對包含「管理」檔案系統資訊的壞區塊起作用。

文件中的壞塊將只是空的。

編輯

好吧，讓我們弄清楚塊大小。讓我們用 512 位元組設備塊製作一個試用檔案系統：

$ dd if=/dev/zero of=fs bs=512 count=200
$ /sbin/mke2fs fs

$ ll fs
-rw-r--r-- 1 dirk dirk 102400 Apr 27 10:03 fs

$ /sbin/tune2fs -l fs
...
Block count:              100
...
Block size:               1024
Fragment size:            1024
Blocks per group:         8192
Fragments per group:      8192

因此檔案系統區塊大小為 1024，我們有 100 個檔案系統區塊（以及 200 個 512 位元組設備區塊）。拯救它：

$ ddrescue -b512 fs fs.new fs.log
GNU ddrescue 1.19
Press Ctrl-C to interrupt
rescued:    102400 B,  errsize:       0 B,  current rate:     102 kB/s
   ipos:     65536 B,   errors:       0,    average rate:     102 kB/s
   opos:     65536 B, run time:       1 s,  successful read:       0 s ago
Finished                                     

$ cat fs.log
# Rescue Logfile. Created by GNU ddrescue version 1.19
# Command line: ddrescue fs fs.new fs.log
# Start time:   2017-04-27 10:04:03
# Current time: 2017-04-27 10:04:03
# Finished
# current_pos  current_status
0x00010000     +
#      pos        size  status
0x00000000  0x00019000  +

$ printf "%i\n" 0x00019000
102400

所以十六進制ddrescue單位是字節，而不是任何區塊。最後我們來看看有什麼debugfs用。首先，創建一個文件並找到其內容：

$ sudo mount -o loop fs /mnt/tmp
$ sudo chmod go+rwx /mnt/tmp/
$ echo 'abcdefghijk' > /mnt/tmp/foo
$ sudo umount /mnt/tmp

$ hexdump -C fs
...
00005400  61 62 63 64 65 66 67 68  69 6a 6b 0a 00 00 00 00  |abcdefghijk.....|
00005410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

所以資料的位元組位址是0x5400。將其轉換為 1024 位元組檔案系統區塊：

$ printf "%i\n" 0x5400
21504
$ expr 21504 / 1024
21

讓我們也嘗試一下區塊範圍：

$ /sbin/debugfs fs
debugfs 1.43.3 (04-Sep-2016)
debugfs:  testb 0
testb: Invalid block number 0
debugfs:  testb 1
Block 1 marked in use
debugfs:  testb 99
Block 99 not in use
debugfs:  testb 100
Illegal block number passed to ext2fs_test_block_bitmap #100 for block bitmap for fs
Block 100 not in use
debugfs:  testb 21
Block 21 marked in use
debugfs:  icheck 21
Block   Inode number
21      12
debugfs:  ncheck 12
Inode   Pathname
12      //foo

因此，結果符合預期，但區塊 0 無效，可能是因為檔案系統元資料在那裡。因此，對於0x30F8A71000來自的位元組位址ddrescue，假設您在整個磁碟而不是分割區上工作，我們減去分割區起始的位元組位址

210330128384 - 7815168 * 512 = 206328762368

將其除以tune2fs區塊大小即可得到檔案系統區塊（請注意，由於多個實體區塊（可能已損壞）組成了一個檔案系統區塊，因此數字不必是精確的倍數）：

206328762368 / 4096 = 50373233.0

這就是您應該測試的區塊debugfs。

答案2

NTFS、ext3、ext4

使用 複製故障磁碟機上的資料後ddrescue，使用ddrutility尋找受影響的檔案名稱。

我成功地讓它ddrescue在 20 秒內列出了給定映射檔案的 1TB 分割區上受影響的 NTFS 檔案。

它將日誌檔案寫入目前目錄。

連結頁面提到了對 NTFS、ext3 和 ext4 的支援。

btrfs、zfs

這些檔案系統有自己的內建scrub功能。

答案3

我會推薦一個已經實現的實用程序，稱為ddrutility.這將消除手動繁瑣的計算。

你應該在你的克隆上運行它複製（不是原廠的）驅動設備如下：

ddru_findbad /dev/sdb /ddrescue-disk-copy.map

此處必須使用地圖檔案（第二個參數）。

該實用程式非常智能，支援不同的檔案系統（甚至 NTFS），並且還具有測試尚未分割的錯誤扇區的功能（將它們標記為臨時壞扇區），因此您應該能夠估計是否需要整個ddrescue過程待完成。另請注意，/dev/sdb此處用作整個磁碟（不是像 的某些分割區/dev/sdb1），因為整個磁碟最初是克隆的。

該實用程式在 Debian 儲存庫中可用，並且可以透過以下方式安裝：

sudo apt install ddrutility

該計畫的維基百科：https://sourceforge.net/p/ddrutility/wiki/Home

答案4

我使用 Filezilla simple 並解決了我的問題。使用常規 Filezilla 備份所有好的資料。我注意到一個大檔案未正確複製（中途停止並重新啟動傳輸）。幸運的是我有相同文件的先前備份。要複製磁碟，我必須使用以下程序找到磁碟上的壞區塊：

首先找出問題磁碟，使用識別高清信息fdisk -l

第二個如果假設你的磁碟是/dev/sdb那你需要運行命令 壞區塊 -v /dev/sdb它會列出驅動器上的所有壞塊。幸運的是會有一些。如果沒有發現壞塊，則表示您的驅動器塊沒問題，需要解決其他問題。我的區塊大小是 512，所以我使用該預設數字來運行 DD

第三個區塊的大小是 512，所以我所做的是設定 bs=512

每次我像往常一樣定期運行 DD 時，出現錯誤後我的資料都會損壞。所以我然後使用頁面上解釋的參數https://www.gnu.org/software/coreutils/manual/html_node/dd-inspiration.html搜尋“故障磁碟”部分。

dd if=/dev/sdb of=/dev/sda bs=512 conv=noerror,sync iflag=fullblock

花了一段時間。每個壞塊都會遇到類似故障驅動器撞擊聲的聲音。它確實逐塊複製，並且通過我所有的壞塊發出相同的噪音。發出噪音的次數是因為它發現了另一個壞塊並告訴您有關顯示錯誤訊息的資訊。什麼是'轉換=無錯誤，同步'是用 NUL 填滿壞讀，而'iflag=全塊'適合短時間閱讀，但始終保持資料同步。完全沒有損壞，它只是不複製錯誤的塊並用空的 NUL 填充它。

使用 DD 複製完成後，我只需替換那個壞文件，從過去的備份中恢復 Filezilla，一切都正常工作。我希望這對其他嘗試備份故障磁碟機的人有用。

注意：我的壞塊彼此非常接近。大約一次將 4 個區塊分組在一起檢測到不良情況。如果您的區塊遍布整個磁碟，則多個檔案可能會受到影響。幸運的是，就我而言，只有一個 4GB 的大資料庫檔案受到影響。

相關內容