Can someone just confirm if these steps for removing a drive was correct, i did a fair bit of Googling to get to this point to not lose any data.

 

[*]Stop the array

[*]Un-assign the disk on the main page

[*]Power down the server

[*]Remove the bad drive

[*]Power on the server

[*]Make sure array is stopped and telnet into it and run "initconfig" "Yes"

[*]Reassign drives to original configuration minus the bad drive

[*]Start the array for parity sync

 

I almost feel like being sick because I have a feeling that is wrong. I can't see any data that was originally on the drive in the shares. Luckily i can still read it on my windows machine (although it's taken 3 hours just to copy 20GB off).

 

Now it could be that i'm just being impatient and won't see the data show up until the parity sync is done, but i think the lack of proper routine information for removing a drive out there lacks detail.

 

I'm not replacing a drive, I'm removing. Some forum posts i read, the tone of the post seemed to suggest that after typing INITCONFIG unraid would automatically pickup the new config without the broken drive, but when i ran it i lost all drive configurations and had to manually reassign each drive to the original slot.

 

Thank god i took a screen cap of that config page.

I think you are confusing proceedures.

 

You said you want to just remove a bad drive - then you have done the right proceedure to Remove a drive.

 

However, you then say all the files are missing from the array that were on the 'bad' drive.  Hate to say this; but of course they are, you REMOVED the drive.  If you wanted the files you needed to REPLACE the drive and use Parity to rebuild the data onto a new drive.  Or at least move the files off the Simulated drive before rebuilding parity.

 

Is the drive you took out still readable? can you mount the drive in another system (or put back in your unraid box and mount it outside the array)?

 

INITCONFIG is used to start a fresh configuration and should only be done if you are sure you want to remove protection and start again (create a new parity for a new drive configuration - as you have done).

Yes it is readable, dead slow readable though. I'll have to wait for the parity to finish in 3 hours.

 

So now my real question to that is, if a drive dies completely, what does one do? Leave the drive in there and start the array?

 

How do I remove a dead drive without replacing it? I would have figured that by removing the drive, that parity would be able to rebuild the data on the drive.

 

Maybe my understanding of parity is incorrect. I have this quote I saved from some forum somewhere and someone explained parity, to me it sounds like the partiy drive has 1 number, the dead drive had another number and a third drive had another number and through some type of math it would be able to rebuild.

 

To make it easy say you have a setup like this:

 

DRU (2TB)

DRU (2TB)

DRU (2TB)

PPU (2TB)

 

That gives you 6 TB of data and 2 TB parity. A simple definition is

that Parity is a calculation based on data that exists on all drives.

Think of it using math: 1+2+3=6.

 

Assume DRU1 = 1, DRU2 = 2, DRU3 = 3, and the PPU = 6

 

If I drop any of those drives, I can calculate what I lost. For example

if I lose DRU3 the formula would look like this:

 

1+2+?=6

 

I can figure out that the missing data is 3. Obviously this is a simple

example, but now take that same idea across all the bits of all files on

the drives. If you lose drive 3, FlexRAID can recover all the data on it

based on what you have on DRU1, DRU2, and the PPU. Replace the dead drive

and run recover and when it's done, you have drive 3 back. However if you

lose 2 drives or more than the 2 TB, then you won't be able to recover

everything - that's why many people are using 2 or more parity volumes.

With 2 parity volumes, you'd have to lose 2 drives before you couldn't

recover everything.

 

So maybe if I had not done INITCONFIG it would have rebuilt the data properly? I'm fairly certain i'm f*cked but i still have the old super.dat backed up. Parity sync is at 45% with 160 minutes remaining.

I just had an idea, since it's being considered a new array, what if i stick this drive back in and place it back into the old slot and let it rebuild again.

 

Instead of it just sitting here on my desk.

Leave the drive out. You have lost your original parity that was would have built your old drive.

Pray you get your data off that drive without losing anything or it dieing completely.

 

Read the wiki for how to recover from a failed drive.

 

Sent from my SGH-I727R using Tapatalk

Well, this should be a wonderful day.

 

Connected to my laptop it wouldn't transfer more than 6-7GB/hour but I put it back in the unraid box and it's managing 40MB/s.

 

So to recap, to remove a drive just copy the data off it first then remove it from the array?

 

To replace a drive, stop the array, remove from config, power down and replace the drive and then power on again and start the array.

Procedure:

 

Drive needs replacing ?

 

1) Bring down the array

2) Remove the drive from the array

3) Place new drive in system

4) Add new drive to array

5) Wait patiently untill unraid has rebuild the drive using the parity

 

Instead of steps 3 and 4 you could also (from your windows system) copy all the files from the removed drive (that are still visible because of parity) to the remaining drives (assuming you have enough space).

 

During this timeframe you have no redundancy anymore so the timeslot needs to be as small as possible, I have "architected" the following:

 

- One drive allready in the system, precleared but not added to the array (since it is not used it is continuously spun down);

- Whenever a drive fails I bring the array down, remove the failing drive from the unraid configuration and add the drive that was sitting there waiting.

 

The above is the quickest I can think of, combined with status mails to my blackberry office email to alert me of failing drives..

 

Went to bed last night, woke up to 15+ emails warning me about the drive. I checked the SMART data which said FAILED but i just checked it 2 minutes ago and it now says PASSED.

 

I've managed to pull the data off the drive on my windows machine. I checked drive 7 because i added that one only 4 days ago and it has nothing on it, so i'm thinking I'll remove it from the array and use that as a spare replacement for the next drive to go. Only two drives left from 2007 in there.

Well, after a completely unproductive day, I can say the array is right back to how it originally was, potentially bad drive and all.

 

I'm not sure what went on this morning, SMART had reports of writing issues and so then began my mistakes of the day. SMART is now reporting all clear with no errors. I stopped the parity sync I started originally and readded the supposed broken drive back into the array in the same slot and started it, everything came right back and parity sync started and finished without issue. It's about 30mins away from finishing a parity check.

 

I'm not sure what to trust, do I trust SMART despite this mornings report, or do I trust the report I just got. It's a 2007 drive that's been running damn near 24/7 since it's purchase.

 

I'm thinking about removing the newest drive I added 4 days ago (640GB) and leaving it in as a spare between now and purchasing a new drive (I don't have the money to get another drive for at least 2 weeks). Just in case the 2007 drive goes.

 

To remove a drive i just stop the array, remove it from config and turn the array back on? I keep seeing posts online about pressing Restore but there isn't a restore button. This is a post the wiki refers us to http://lime-technology.com/forum/index.php?topic=2088.0 but it's missing information (or 5.0 already does the requirements for you)

 

Here's one recommending initconfig which is what screwed me this morning. http://lime-technology.com/forum/index.php?topic=6728.0

Here's one recommending initconfig which is what screwed me this morning. http://lime-technology.com/forum/index.php?topic=6728.0

 

If you look at Joe L's post in that thread, he explains that the initconfig command does the same thing as the restore button, and then explains what happens.

 

 

Typing that command is exactly like pressing the old button.  The label on the old button was misleading and caused some users to lose data when they were attempting to re-construct a failed disk.  Instead, the button immediately deleted their existing disk configuration and immediately invalidated parity.  That is NOT what they needed when they had a failed drive as it prevented them from re-constructing the old drive's contents.

 

Using initconfig tells unRAID to forget everything about your old configuration, including parity. What you wanted to do was remove a drive and the data still be available. This is 1. Definitely not recommended as you no longer have parity protection and

2. I don't think its possible to manually do this, unraid does it automatically in the event of a drive failure.

 

If you were removing a drive that was failing, you should have copied the data off of it to another drive(if you didn't plan on replacing the drive immediately) or if you had another (empty) drive ready to go into your array, you should have

1. Stopped the array,

2.Shut down the server,

3.Removed the disc and installed the new disc in its place.

4.Start the server back up,

5.Make sure all other discs are still configured correctly,

6.Assign the new disc to the old discs location.

7.Start array and let parity rebuild the data from the old drive to the new drive.

OK, I've added that to my notes bank for the future, I'm still trying to figure out removing a drive. The 640GB drive which is new is completely empty and I'm wanting to remove it from the active array while leaving it in the machine as a hot spare.

I believe the answer to that is (kind of) in the thread you linked as well.

To avoid parity sync(server unavailable and unprotected):

http://lime-technology.com/forum/index.php?topic=6728.msg73822#msg73822

To remove a drive from the protected array, copy any data you want to keep off of it, then zero the drive using :

dd if=/dev/zero bs=2048k of=/dev/md?

replace the "?" in of=/dev/md? with the number of the drive being removed, so if the drive you want removed is /dev/md5 the command would be

dd if=/dev/zero bs=2048k of=/dev/md5

 

Doing this will remove the drive from parity(in a manner of speaking, it actually just makes the math correct with or without the drive).

 

Once zero'd, unassign the drive from the array, type initconfig and issue the set invalidslot command like this:

mdcmd set invalidslot 99

This is where one of the more experienced unraid users will hopefully jump in. I've read mixed reports on if this works in 4.7 up.

 

After issuing set invalidslot, do not refresh the webconfig page, press START and the array will start and a parity check will start. Note that the array is still protected during a parity check and is available.

 

If you just want to remove the disc from the array and don't mind letting parity rebuild, stop the array, unassign the drive, type initconfig, restart array and parity sync will start.

 

Thanks to Joe L. for all the great information. I feel like I'm cheating because my replies are essentially the same as what you've said before! 

 

To use the drive as a spare, after it is zero'd, run a preclear on the drive by following this guide:http://lime-technology.com/forum/index.php?topic=2817

You can use the -n option to skip the pre-read and post-read if you are satisfied the drive is reliable.

 

After the drive is precleared you can leave it in your unraid machine, just do not assign it to the array. Then if a drive fails you can remove the failed drive and assign your spare in its place and restart the array, parity rebuild will start.

I've seen that a few times, i did the initconfig and basically rebuilt from scratch right back to original status, which sucked.

 

I didn't zero out a drive, but i did the INITCONFIG part and this step:

 

6.1.3) At this point all your drives will be blinking BLUE and Unraid is waiting for you to press the Start Button.

 

Never happened, when I view the web page all drives were set as unassigned and i manually reassigned them to the proper slot. But i didn't know about the /root/mdcmd set invalidslot command at the time.

 

28 minutes left on parity check.

 

As well, when it wants to umount the drive and it says md? the disk is listed as disk6 in the web portal, that matches md6 i hope? it's not possible to cd into md5 since it's not a directory.

 

unMenu answered that for me.

Zeroing out the drive is only needed if you do not need to reconstruct the data, as I said before all it does is zero the drive and updates parity with the zero, so going with the aforementioned explanation of parity if:

DRU1=2TB

DRU2=2TB

DRU3=2TB

PPU=2TB

 

DRU1=1,DRU2=2, DRU3=3, so PPU=6. If you want to remove DRU3 and do not want to reconstruct data, you zero the drive, so now:

DRU1=1, DRU2=2, DRU3=0, PPU=3.

Now you remove DRU3 and:

DRU1=1, DRU2=2, PPU=3.

 

Zeroing the drive just makes sure the math is correct, so when you issue the set invalidslot command telling unraid the parity is correct, it ignores that DRU3 is missing and you know parity is still correct.

 

Again, you only have to go through this if you wish to remove a drive and do not want to do a parity sync. Removing the drive and allowing parity to rebuild does the same thing just with the added effect that 1. Your array is offline during the sync and 2. The array is not protected during the sync.

 

I'm not sure about the drives blinking blue, have not seen it. I'd test it for you but don't want to go through a parity sync and don't have a test server setup. I don't think they should blink as the initconfig command will make a new configuration with the disks currently assigned, so they will be "unassigned" and not "new".

 

As far as I can tell the initconfig command works a little differently with the beta's than it did on older versions.

 

1. Your array is offline during the sync and 2. The array is not protected during the sync.

1. The array is not offline and during a parity rebuild.

2. The mcdc command should almost never be used.

 

See the wiki for instructions on removing or rebuilding a disk.

 

http://lime-technology.com/wiki/index.php?title=FAQ#How_do_I_replace_a_hard_disk.3F

http://lime-technology.com/wiki/index.php?title=FAQ#How_do_I_remove_a_hard_disk_that_I_do_not_plan_on_replacing.3F

Thanks for the clarification on number 1. Haven't had to do a rebuild so I was going off of something I read, must have read it wrong.

 

And for number 2. I know it shouldn't be used often, but in the case of removing a disc and keeping parity valid, every tutorial says to use that command. I'm not saying it should be used in other situations. Thought I made that clear in the post. Sorry for any misunderstandings

The mcdc command should almost never be used.

Any reason?

 

The wiki lists this method as a way to remove a disk without losing protection, and if this drive really is this close to dying, I don't really want to push that limit by not having it protected. If the only trade off is time consuming zeroing the drive but keeping protection, I'll stick with protection.

 

Now, i just have to figure out why i can't ping anything from within unraid, or get it to access the external internet.

The mcdc command should almost never be used.

Any reason?

 

The wiki lists this method as a way to remove a disk without losing protection, and if this drive really is this close to dying, I don't really want to push that limit by not having it protected. If the only trade off is time consuming zeroing the drive but keeping protection, I'll stick with protection.

 

Now, i just have to figure out why i can't ping anything from within unraid, or get it to access the external internet.

 

If the drive is close to dying it would be a bad idea to try an zero it. It's much safer to remove the bad drive and run initconfig.

Try typing

/etc/rc.d/rc.inet1 restart

 

That should restart your network config.

If the drive is close to dying it would be a bad idea to try an zero it. It's much safer to remove the bad drive and run initconfig.

I'm not removing the dying drive just yet, I'm removing a brand new one I put in there like 4-5 days ago that is still empty to use as the drive to take over for the dying one.

 

That should restart your network config.

Thank-you, in the process of looking at my network.cfg i realised that somehow my router was set to give it static IP of x.205 and the bloody config on unraid was set to it's own static x.3 it's been like this for months, not sure why it decided to give me a hard time today. Although, bad things come in three's so i guess i'll have to be very careful this week.

So, from what I've learned so far, I'm on version 5.0 beta 14

 

initconfig wipes the config and doesn't bring it back, you have to manually reassign each drive to it's slot.

 

"/root/mdcmd set invalidslot 99" does not echo any output, it's silent, so i'm not even sure it worked as intended.

 

After assigning each drive, and doing the mdcmd twice, once before assigning the drives and again after assigning them, all the drives were blue and it's now doing a parity check, not a sync/rebuild.

 

7.72 hours to zero a 640GB hard drive. Hopefully this check goes through without error.