Getting straight to it - I know I have lost data.

However, I would appreciate some help recovering/keeping what I can.

 

This is the current status:
 

Is there anyway for me to restore the 2 array disks that are suddenly inaccessible?

 

On a side note, I just want to say thanks to the many contributors in this community - I have learnt a lot just reading over the years, and this forum has saved my bacon more than once!

nas-diagnostics-20240512-0010.zip

Note, I believe there to be two different issues.

 

1. Parity and disk 5

Disk 5 failed (due to a faulty sata cable) and then my parity disk also failed, whilst rebuilding disk 5.

Hence the no fs error.

I assume there is no resolution to this...?

 

2. Disk 3

This disk is part of the encrypted array and just suddenly stopped mounting.

I would like to hope this issue can be resolved...?

Have you tried the process documented here for handling unmountable disks (or at least the check part)?

 

Please let us know so we can provide best advice.   There is an excellent chance all data can be recovered if you are careful.

Thanks for assisting, @itimpi

 

Unfortunately, I am unable to run check on disk 3:
 

Since parity is invalid it won't be able to emulated the disabled disk, if you think disk3 is healthy, and the rebuild was being done on the old disk, you can do a new config to re-enable that disk and then re-sync parity, but note that any data written to that disk after it got disabled would be lost.

 

 

Thank you, @JorgeB.

Smart tests indicate all drives are healthy - if these are to be trusted.

And, at this point, I'm just trying to recover as much data as possible.

 

Will your recommended 'new config' approach have any adverse affects on disk 3?

i.e. is this my starting point, or do I need to go down a different route for disk 3 first.

 

Thanks everyone 

1 minute ago, Madmol said:

Smart tests indicate all drives are healthy - if these are to be trusted.

The extended SMART test tends to be an excellent indication of health.   The others are only good at indicating failures - not so good at indicating health.

Point noted about the extended tests.

I shall run these tests as well. If one/more are on their way out, I shall replace them - as soon as I have recovered all possible data.

5 minutes ago, Madmol said:

Will your recommended 'new config' approach have any adverse affects on disk 3?

Assuming the disk is OK it should mount normally after the new config, if you want, you can try mounting it with UD before the new config, for that the disk needs to be unassigned first.

Disk 3 seems to mount fine in UD, so I shall proceed with the new config and report back.

Good news - disk 3 is back up and running! Thanks a lot.

 

Are there any steps I can take for disk 5 at all?

Check fileystem on disk5, run it without -n, and if it asks for -L use.

Thanks @JorgeB

Unfortunately, I was unable to check filesystem successfully on disk 5, with/without -L.

In fact, check filesystem is not available within the disk settings GUI page.

File system status just show's '-' and the File system type shows as 'auto', and is unchangeable.

 

Running

xfs_repair -Lv /dev/sdh1

via the command lines shows:

Quote

Phase 7 - verify and correct link counts...
SB summary counter sanity check failed
Metadata corruption detected at 0x47c2cb, xfs_sb block 0x0/0x200
libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1
SB summary counter sanity check failed
Metadata corruption detected at 0x47c2cb, xfs_sb block 0x0/0x200
libxfs_bwrite: write verifier failed on xfs_sb bno 0x0/0x1
xfs_repair: Releasing dirty buffer to free list!
xfs_repair: Refusing to write a corrupt buffer to the data device!
xfs_repair: Lost a write to the data device!

fatal error -- File system metadata writeout failed, err=117.  Re-run xfs_repair.

Am I out of options?

Running on the sd device will not update parity, click on the disk, set the filesystem to xfs, try running it again using the GUI and post the results.

32 minutes ago, JorgeB said:

Running on the sd device will not update parity, click on the disk, set the filesystem to xfs, try running it again using the GUI and post the results.

Unfortunately, the gui will not permit me to change the fs. I can post a screenshot a little later. It is immutably set as 'auto'.

16 minutes ago, Madmol said:

Unfortunately, the gui will not permit me to change the fs. I can post a screenshot a little later. It is immutably set as 'auto'.

Did you remember to stop the array before trying to change it to xfs?

3 hours ago, itimpi said:

Did you remember to stop the array before trying to change it to xfs?

🙄... I am an idiot. Yes, I forgot...

 

However, I still receive this error:

 

I'm afraid that if xfs repair cannot fix the filesystem not much that can be done on the Unraid side, you can try making a post in the xfs mailing list or using a file recovery app like UFS explorer.

Ok. Thanks to everyone that has helped thus far. I shall mark the topic as solved, and go from there.