Hi All,

 

During a parity check, one of my array disk was disabled due to overheating. I used the following instructions to enable the disk again: How do disks become disabled.

Only I made 1 critical error. I was thinking this was a good opportunity to switch the file system of this array disk from reiserFS to XFS. So I changed the file system and and selected form disk from the unraid GUI. After this I hit Parity check/Rebuild Parity and was expecting all my data restored on the array disk from the parity disk. However after rebuild my disk was empty which I know understand. 

Is there a way to recover the data that used to be on my array disk? I suppose it is erased from parity drive also?

Edited December 23, 20205 yr by TvdK

Parity doesn't contain any of your data, and formatting a disk in the array updates Parity just the same as any other write operation. Format means write an empty filesystem, and Parity agrees it's empty. 

 

Some people have had success with UFS Explorer 

Thanks for the tip for UFS Explorer. I also found some recommendations for TestDisk - CGSecurity. 
Will give these options a try tomorrow.  If I get the reiserFS filesystem and partition back on the disk, how to reintroduce it into the array and rebuild the parity?

I don't think those recovery tools will recover to the same disk so you will get the data somewhere else, then you can copy it to the array. I haven't used them so can't say for sure.

Found an older post that suggested to change the file system back to reiserFS and use the ‘reiserfsck rebuild tree’ option. This looks like it might be a better option.
Can anyone recommend the best procedure to recovery with reiserfsck and rebuilding parity?

Do I have to unassign the parity disk in this process?

To repair the filesystem of a disk in the parity array, parity MUST be included with the repair or you will invalidate parity.

 

https://wiki.unraid.net/Check_Disk_Filesystems#Checking_and_fixing_drives_in_the_webGui

11 minutes ago, TvdK said:

Found an older post that suggested to change the file system back to reiserFS and use the ‘reiserfsck rebuild tree’ option.

Do you have a link to that? I'm not sure how you can change the filesystem back to reiserFS without formatting it again.

Found the recommendation in this topic. although the exact procedure is still unclear to me. I will likely have to rebuild parity since I did a parity check with the empty array disk.

 

 

If @JorgeB said it I believe it.

Current xfs uses a lot more space for metada, so likely there will be some data loss in the beginning of the disk, still worth a try, change the disk fs back to reiser, then rebuild the superblock, then rebuild tree.

Thanks for help. After changing back to reiserfs I try to run the reiserfsck check option from the GUI. This results in the following error. Do I need to reformat or do I need to run it from command line?

 

reiserfsck 3.6.27

Will read-only check consistency of the filesystem on /dev/md1

Will put log info to 'stdout'

Failed to open the device '/dev/md1': Unknown code er3k 127

Tried to rebuild the superblock but got the same error: 

Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Failed to open the device '/dev/md1': Unknown code er3k 127
 

Am I forgetting any steps?

What Unraid release? Some older reiserutils have bugs.

I'm running Unraid 6.8.3. 

When you say changing the disk fs back to reiser, do I need to do something more than just selecting it from the drop down in disk settings in the GUI?

When starting the array is normal mode the disk is not mountable because it lacks a file system. Can I use the Format button from the GUI to create a new reiser filesystem or will this further destroy my data?

36 minutes ago, TvdK said:

do I need to do something more than just selecting it from the drop down in disk settings in the GUI?

That's it.

 

3 minutes ago, TvdK said:

Can I use the Format button from the GUI to create a new reiser filesystem or will this further destroy my data?

You can, it would be best without doing it, but if rebuilding the superblock isn't working maybe the only option.

After format I can run reiserfsck with the following results:

reiserfsck 3.6.27 Will read-only check consistency of the filesystem on /dev/md1 Will put log info to 'stdout' ########### reiserfsck --check started at Tue Dec 22 11:26:37 2020 ########### Replaying journal: Replaying journal: Done. Reiserfs journal '/dev/md1' in blocks [18..8211]: 0 transactions replayed Checking internal tree.. finished Comparing bitmaps..finished Checking Semantic tree: finished No corruptions found There are on the filesystem: Leaves 1 Internal nodes 0 Directories 2 Other files 0 Data block pointers 0 (0 of them are zero) Safe links 0 ########### reiserfsck finished at Tue Dec 22 11:28:01 2020 ###########

 

Would you recommend to rebuild the superblock or only rebuild tree?

try --rebuild-tree and also with --scan-whole-partition

Rebuild tree is running. This will take a couple of hours. Hopefully there will some data on this disk after.

Let you know if I have been able to recover the data. 

Didn’t expect this to be feasible. Most of my data appears te be recovered after formatting it back to reiserFS and rebuild. I have to investigate the exact damage but already very happy with this result.

 

Took about 8 hours for this 1.5TB to rebuild.

 

@JorgeB, thanks for the help and patience.