I have an SSD with LVM with one LV dedicated to a Win7 VM .vdi file of 80Gb.
The underlying fs
is ext4
.
After installing a new SSD and setting up the new LV's in migrating, the copy from the old SSD failed on copy with
Input Output Err No.5
Failed on cp
, rsync
, dd
And a quick look at
dmesg
[ 5829.294651] sd 2:0:0:0: [sdb] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[ 5829.294653] sd 2:0:0:0: [sdb] tag#14 Sense Key : Medium Error [current]
[ 5829.294654] sd 2:0:0:0: [sdb] tag#14 Add. Sense: Unrecovered read error - auto reallocate failed
[ 5829.294656] sd 2:0:0:0: [sdb] tag#14 CDB: Read(10) 28 00 51 50 f9 47 00 00 08 00
[ 5829.294658] blk_update_request: I/O error, dev sdb, sector 1364261191 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
A selftest with smartctl
gives the a fail with the LBA
badblocks
shows me 6 bad blocks and a further check with debugfs
confirms the inode
for all bad blocks as belonging to the .vdi file.
There is nothing on that LV bar the VM which currently still boots fine in virtualbox
(which also won't copy the VM).
So the assumption is that the bad blocks are in some rarely used part of the VM filesystem and it doesn't care (yet) but the day will come.
Now I can't blame my Linux box for disliking the Win7 VM but I would like to save the old girl if only for sentiment.
Is there a way to recover the .vdi, perhaps by defaulting to a zero filled block on a bad read and skipping to the next block?
Just found
https://serverfault.com/questions/489696/recovering-a-file-with-bad-blocks-in-the-middle
Soon as I typed ....giving it a go