Cable Popped Loose - UPDATE - Errors during Data Rebuild?? - Syslog added

That email script looks like it worked great!

 

I cannot confidently say that there were no writes to this disk since disabling.  I added this disk because my array was so full and was in the process of moving lots of files to it around the time of the failure.  I would probably feel better working off the assumption that writes were in process.  I have however been very careful to not write anything to the array since the error.

Understood.

NOTE:  If you are not sure, there may be some way to mount the disk13 drive outside the array and see what is on it.  I will leave to one of the Linux experts to see if that is a feasible thing to do.

I think I can do this if necessary.  I'm pretty sure that since the drive is disabled, I can pull it out and attach it to my Windows workstation with a usb-SATA dock and then load the Reiser driver on Windows and inspect the disk.  Do I have to power off the array first, then pull the drive?  Should I not power on the array without the drive in place or does this not matter since it's disabled.  I think I want to ensure that the array does not "forget" about this drive until I'm ready.

When a disk fails like yours did, unRAID takes it out of the array and does not try to read or write to it anymore.  But it maintains the illusion that the disk is still connected.  So at the moment of failure, the data on your REAL disk13 and the data on the simulated disk13 are exactly the same.  But if you wrote data to the simulated disk13, it will be out-of-sync with the data on the real disk13.  Seems simple but kind of confusing.  Want to make sure that is clear.

I was suggesting here that there might be a way to mount the real disk13 without removing it from the Linux box.  Then you could look at both the real disk13 and the simulated one and see exactly where the differences are.

5.  The current state gives you an opportunity to backup any critical data off of the simulated disk13 which you can copy to another disk on the array, one of the non-array disks attached to the server, or to an attached workstation.

What is the best way to do this.  Should I use MC and do a disk13 to diskX copy?  Or is it better to pull the data from a windows machine through the network?  I'm leaning towards the network solution so I can keep array activity to a minimum until this is solved and I am fully protected.

Either way.  I'd lean towards getting it off the unRAID box.

   b.  If you have written data to disk13, I might suggest rebuilding onto a spare disk or replacement disk.  You can then do the data REBUILD procedure onto the new disk.  With the exception of that one sector with a current pending remap, the disk should rebuild.  (You could leave it that way, or you could put your disk13 back into the array and attempt to rebuild back onto that original disk.  If there were some problem, you'd have the spare disk and could put it back in and do the trust procedure and not lose any data. )

So this seems like the best bet for me. 

 

So if I understand correctly, my safest course of action would be to --

1. Backup important files from disk13 share over the network to my Windows workstation

2. Shutdown the array

3. Replace disk13 with a new hard drive

4. Start the array

5. Stop the array

6. Assign my new drive to the array in the devices tab

7. Check the box next to Start the Array

 

Then parity should rebuild to the new drive.  If something happens, I still have the old failed drive as a backup.

8. Inspect new disk13 contents on the rebuilt new drive and replace any missing files from the backup I took in step 1

 

Then I could use the old disk13 to replace an older smaller disk in the array at a later date -- after everything has been running smoothly for a while.

Correct.

Would this be the best plan of attack to get my array back on solid ground?

 

Thanks again for all the insight.

The only issue is that one unmapped bad sector.  With RAID a single bad sector during a drive rebuild will kill the drive rebuild (I think they call it stripe kill).  With unRAID I do not think that is the case, but am not 100% sure.  If you feel that the updates to disk13 AFTER the failure were small, and you still have the source data and could recopy it, I'd consider the trust the drive method.  Whichever way you go, make sure that you have everything copied off the disk13 that you cannot salvage in another way before you begin.

Good luck!