Hi,

 

Looking for some suggestions for a recovery approach.

 

Had a disk show up a few read errors, went to buy a new disk (which took about 48 hours) and then when I got home with the fresh drive a whole different disk had fully died (red "x").

 

I didn't think much of the errors, was too focused on getting the replacement disk in there. So I swapped the new disk in over the failed one (not the one with read errors that I was originally going to replace), and kicked off a data rebuild.

 

That's currently running onto my new drive... but 27% into the rebuild, and the disk with read errors has thrown 182 during the rebuild, reminding me (belatedly) that there was more than one disk with problems.

 

I'm now thinking through the consequences of my hasty actions, and starting to wish I'd discovered the File Integrity plugin before this happened, so that I could more easily identify which files will now be bad.

 

Luckily I have a CrashPlan backup of everything of importance, so I'm mostly concerned with finding what files are messed up and need replacing from backup - ideally something more precise than just restoring everything though, as my CrashPlan has about 1.1TB and I'm on ADSL. I also don't really want to start CrashPlan backing up again until this is fixed.

 

Any suggestions?

 

I do have logs with the lines including sector numbers, which I thought would be easy to map to files, but that doesn't seem to be the case.

 

Thanks,

-- tallorder

With a bit of Python and bash hackery, I've managed to identify the files that relate to the bad sectors from the disk with read errors (disk5).

 

My question now is: will the sectors with the same exact numbers be also be 'corrupt' (improperly reconstructed) on the disk that has been rebuilt (disk1)?

 

If so, I'll be able to find the files on the rebuild disk (disk1) that overlap the same sectors reported bad by disk5, and restore them from backup too.

 

Or, just delete them... so far, the only impacted file has been a Macrium image of some old desktop PC's boot disk that I made in 2014... why that was still there, I don't know, but it's not exactly a massive loss

 

-- tallorder

 

 

PS: For those who follow in my footsteps and want to map bad sectors back to files, the approach I used was based running on this command on every file on the disk, and saving the output as a CSV file. (It depends on pcregrep, installed via the pcre package in the Dev Pack plugin.)

filefrag -b512 -e "/path/filename" | pcregrep -o1 -o2 --om-separator=: '^\s*\d+:\s+\d+\.\.\s+\d+:\s+(\d+)\.\.\s*(\d+):'

Then to extract the bad sectors reported in syslog:

grep "read error" /var/log/syslog | sed -r 's/.*sector=([0-9]+)/\1/'

After that, I wrote some Python to figure out which of the extents reported by the first command actually overlap the bad sectors reported by the second one. It's sort of simple, but my script there is pretty messy so I'll post that later.

Edited May 27, 20197 yr by tallorder

13 minutes ago, tallorder said:

My question now is: will the sectors with the same exact numbers be also be 'corrupt' (improperly reconstructed) on the disk that has been rebuilt (disk1)?

Yes, as they will be if you now replace another disk, until a parity check is done.

 

 

Thanks.

 

I will use the same sector IDs on the reconstructed disk to identify which files need restoring.

 

Going forward, the File Integrity plugin seems like a must-have to avoid this kind of issue in future!

 

-- tallorder