I moved my innards to a new enclosure and I'm sure managed to swap drive connections.

I followed the instructions for Make Unraid trust the parity drive. Afterward when I started the drive it appeared to be checking parity.

One of the drives showed an error, which unfortunately I do not remember) but did show the same growing number of reads as the other data drive, and no writes to the drive in question, which led me to believe that there were no issues. No errors were found.

Now that drive shows as unformatted.

I have not formatted the drive in question.

In accordance with the suggested trouble shooting method I have copied the syslog in this posting. I hope that someone can assist me in recovering the data on the unformatted drive.

 

Thank you in advance,

syslog.txt

I've never even seen the version you're on. I do know that unRAID since v5 has been able to keep track of drives by serial number. Did you take a screenshot or something so you would know what your drive assignments were supposed to be, in particular, the parity drive?

 

Sounds like you might have gotten parity and one of your data drives mixed up. If so, then it probably "corrected" the parity by overwriting one of your data drives, and the unformatted drive is actually your parity drive which doesn't have any data to recover.

 

You might post a screenshot and perhaps someone will come along that may have some idea how to work with version 4.5.6. even if they aren't using it anymore.

 

 

 

Now that drive shows as unformatted.

I have not formatted the drive in question.

In older version of unRAID a drive showing as 'unformatted' only meant that it was not successfully mounted - not that it was really unformatted.    Assuming the drive has not physically failed, the common cause of this is some sort of file system level corruption that can almost certainly be corrected using the reiserfsck recovery tool.

 

I am not sure what the exact steps are for running reiserfsck on such an old version of unRAID.  In case it might help on v5 the steps would be:

• Stop the array and restart it in maintenance mode.  Not sure if the version of unRAID you are using had this?
  
• From a console/telnet session run a command of the form
  

reiserfsck --check /dev/md?

where ? corresponded to the disk number in the GUI.  This command would tell you if corruption was present and suggest a way forward. 

 

If your version of unRAID does not have maintenance mode then the above instructions will not work although there should be something similar available.

 

The key thing is not to do something if you are not sure what is intended at any stage.  For instance you definitely do NOT want to format the drive as that would result in the loss of data on it.

Thank you both for your feedback.  When the parity check occurred, there were a virtually identical number of reads on both data drives and a very small number of write to the parity drive and the data drive that had no issues.

Because all the drives were involved in the parity check and so few writes occurred it appeared that the parity check went well and so I believe the parity drive is the correct one.

I'll did some research on the reiserfsk commend before I proceeded with that. There is no maintenance mode option in my GUI version so I wanted to be careful as to what I did.

Since the mount of drive 4 failed there is no /dev/mnt4 to run a check on. I suspect running in maintenance mode in the newer versions does the mount, but even that would not work.

I could run it on the physical dev /dev/sda, but is there any issue with doing so? In particular the offset of 63 cylinders.

Also reiserfsck wants to know what version of reiserfs I am running. From the log I believe 3.6 as noted in the line

Nov  2 22:20:49 Tower kernel: REISERFS (device md1): found reiserfs format "3.6" with standard journal

 

I realize that I was stupid to have proceeded without a backup or at least some screen prints, but I thought I had marked my cables well when I moved everything.

Clearly I did not.

If you have to run against the physical device then you need to include the partition number (e.g /dev/sda1).  The issue is that doing so will invalidate parity.  This means that until parity is rebuilt you are no longer protected against another disk failing.  I do not know with the version you have whether there is any way to run reiserfsck and maintain parity.

 

The maintenance mode in v5 onwards gives you virtual devices (/dev/md?) that maintain parity when they are changed.

I'm currently cloning the drive with clonezilla. I have a machine model drive that I have not yet used so I'm doing a sector by sector copy. I'll play with that copy to see what I can achieve using reiserfsck and the above guidance.

Use the Check Disk File systems wiki page, the section for v4.  It will give you the correct steps, including how to stop samba and unmount the drive, after the array is started.  Use care to use the correct device symbol (e.g. sdj1 or md5), depending on whether the drive you are working on is in or out of the array.  A wiki section near the top discusses that.

 

If you didn't swap the parity drive for a data drive, then there's a good chance you haven't lost anything.  It may just be a case of a loose connection, after re-configuring and handling the hardware.

 

And please consider upgrading to v6!   

How do I determine what the block size is to specify for the superblock rebuild?

The log file I posted only shows 512 blocks, but default is 4096 for unraid, and I do not remember specifying anything different, but it has been a few years.

Should I ignore the 512 in the log file?

How do I determine what the block size is to specify for the superblock rebuild?

The log file I posted only shows 512 blocks, but default is 4096 for unraid, and I do not remember specifying anything different, but it has been a few years.

Should I ignore the 512 in the log file?

 

Down at the bottom of that wiki page is the section Rebuilding the superblock.  I hope that helps.

Thank you to all for your assistance. I was able to recover all data. As suggested I had swapped the parity drive with a data drive, and had to rebuild the super block on the data drive. I pulled all files from each data drive to a large external drive and am now upgrading to V6.