Hi all,

 

For the last few weeks my parity disk has been sporadically producing read errors which don't stop until I restart the array. I'm fairly confident the disk is okay and the issue lies in my cabling, motherboard, or SATA card (probably the latter). However, I had a power cut recently and it appears as though one of my array disks is now dying. The `Current pending sector` SMART attribute is now at `3` and it's producing a ton of read errors.

 

Because of the parity disk situation I believe I'm going to lose some data, as the parity disk was in an error state at the time. It's not the end of the world, but I'd like to recover what data I can from the array disk before removing it.

 

Starting the array with both the parity disk and array disk allocated I can see some data on the disk. However unraid is showing the disk state as `device contents emulated` and trying to read data off the disk eventually results in read errors from the parity or array disk, locking up my server. My plan is to remove the parity disk and array disk from the array and mount the array disk as an unassigned disk. Then try to copy what data I can from the disk to the array. Is this plan sane?

 

Thanks in advance for any advice.

blackbox-diagnostics-20220301-1956.zip

Disk5 dropped offline so there's no SMART, probably because of the controller, but it does appear to be failing, suggest connecting it to the onboard SATA ports (swap with another disk) and then and since parity isn't valid run ddrescue to try and recover as much data as possible.

 

Pparity looks healthy, though would recommend getting rid of that SASLP controller since they are not recommended for a long time, replace it with an LSI HBA.

Thanks for the reply. Your post on using ddrescue looks very helpful, but I don't have another empty disk of the same size to copy to. The only choice I have is another larger array disk that is mounted and has data but has enough free space to rsyc the salvaged data onto. I've already used `xfs_repair` to salvage some data. In this case do you recommend that I just take the dying disk out of the array into unassigned devices and rsync data from there into the array disk?

Or actually I could temporarily take the parity disk out of the array and use that to clone to, and then copy the results into the array before returning the parity disk to the array. Just hope nothing else fails during this process...

You can copy as much data as possible to another array disk(s), still recommend first connecting it to onboard Intel SATA since the SASLP usually crashes/drops the disk when it encounters a read error.

Thanks, that's good advice. I'll give this a whirl this weekend and see it how it goes. Thanks for your help and for your guide!

@JorgeB I have moved over both source and destination drives to onboard SATA, but I'm a little confused on how to proceed. Your guide says the drives shouldn't be mounted, but how do I access them through the CLI without them being mounted? They do not show up under `/dev/mnt/` (which is to be expected). I've installed the Unassigned Devices plugin but wary of proceeding with formatting the destination drive so it can be formatted, and then I'd have to mount them anyway? Would appreciate any guidance. Thanks in advance.

 

Edit: For further clarification, this is what I see under `/dev`

 

Edited March 5, 20224 yr by Moussa

Are you going to copy the data manually as mentioned or using ddrescue? For ddrescue you use the devices identifier, /dev/sdX for both source and destination.

I'm going to be using ddrescue. I think I've got it running now. Thanks again for the help.