Permanently remove a drive

[rutherford]

I've got eight drives in the server. There is plenty of empty space on the drives. I made a mistake of doing the following and losing all the data that was on the one drive I removed.

 

Run parity check

stop array

shut down server

removed bad disk

telnetted in and ran "initconfig"

reassigned all the drives to their same positions

started the array

boom - data gone.

 

I guess I'd figured that because the information was on the parity drive, the stuff would come back - but I was mistaken. Luckily there was nothing on the drive that was not irreplaceable - just annoying to lose stuff. I would like to request that someone who knows what they're doing (not me in this case) fill out this wiki so people can do this procedure without losing data.

 

this one is too long: http://lime-technology.com/forum/index.php?topic=2591.0

there's mixed information on this one: http://lime-technology.com/forum/index.php?topic=7222.0

apparently in v5.0b14 the "restore" button is gone, so these instructions need to be fixed too: http://lime-technology.com/forum/index.php?topic=6178.0

 

If someone directs me to the correct information for removing a drive, I will happily remove another drive from my server, and make all the screen shots with directions all the while

 

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!

[Joe L.]

I've got eight drives in the server. There is plenty of empty space on the drives. I made a mistake of doing the following and losing all the data that was on the one drive I removed.

 

Run parity check

stop array

shut down server

removed bad disk

telnetted in and ran "initconfig"

reassigned all the drives to their same positions

started the array

boom - data gone.

 

I guess I'd figured that because the information was on the parity drive, the stuff would come back - but I was mistaken. Luckily there was nothing on the drive that was not irreplaceable - just annoying to lose stuff. I would like to request that someone who knows what they're doing (not me in this case) fill out this wiki so people can do this procedure without losing data.

 

this one is too long: http://lime-technology.com/forum/index.php?topic=2591.0

there's mixed information on this one: http://lime-technology.com/forum/index.php?topic=7222.0

apparently in v5.0b14 the "restore" button is gone, so these instructions need to be fixed too: http://lime-technology.com/forum/index.php?topic=6178.0

 

If someone directs me to the correct information for removing a drive, I will happily remove another drive from my server, and make all the screen shots with directions all the while

 

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!

Typing "initconfig" immediately invalidates parity.  It cannot be used to reconstruct a removed drive when invalidated.

 

If the drive you removed has not failed, the data is still on it.  You can mount it and get to the files.

[rutherford]

The drive was pretty much gonzo - but you're right, I totally shoulda kept it around. Instead I was pleased to discover that the drive was still under manufacturer warranty and sent it out that day. Ah well, them's the breaks. I would still like to write this wiki article on how to do it properly - so can you start pointing me in the right direction for:

 

I've got a server with 8 drives.

The total space is only half taken up.

I would like to remove one of the hard drives to re-purpose

How do I remove the hard drive, without losing any data off the drive?

 

Thanks Joe!

drew

[dgaschk]

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

[rutherford]

dgaschk

that is one of the wiki's I was looking at, but the procedure it describes doesn't talk about anything cool. Hmm, that sounds stupid. All it says is "Before you make any configuration changes, if there are any files on the drive being removed you wish to keep, copy or move them to a different drive." which isn't all that helpful.

 

I think some of this has a basis in my lack of understanding on how reiserfs allocates user shares as "High water." Like for instance. I have an unraid server with four hard drives. I have all six seasons of the TV show 24. I start copying them over to the server into a "high water" user share called TV/24 (/mnt/user/TV/24). Unraid magically puts a few episodes on disk 1, a few episodes on disk 2 and so on and so forth. While all the shows and seasons appear to be in their correct spots inside /mnt/user/TV/24, the physical files are spread throughout all the hard drives.

 

I've I'm going to copy stuff off one of the hard drives - well that's a time consuming procedure because there are hundreds of sub-folders for all these different seasons/shows/movies/music/photos etc.

 

Let's say a hard drive shits the bed - it's okay because I have unraid and it's raid capabilities. Any one single drive of mine can totally fail, and the rest of the array will pick up the slack - literally recreating the failed drive from parity information. This is amazing.

 

But I have plenty of extra space on the rest of my server, why not be able to tell the server: you are not getting that hard drive back. Please write all that parity stuff you're magically doing to the existing array's empty space.

 

THAT should be possible. If it isn't automagically possible, there should a way to do it besides manual file copies. This is a raid we're talking about here.

 

Thanks for the additional input - I'm going to take it into consideration while writing the detailed answer for my own question here one of these days!

[dgaschk]

You can easily find the files on the drive by looking at the disk shares e.g., /mnt/disk1

[Joe L.]

dgaschk

that is one of the wiki's I was looking at, but the procedure it describes doesn't talk about anything cool. Hmm, that sounds stupid. All it says is "Before you make any configuration changes, if there are any files on the drive being removed you wish to keep, copy or move them to a different drive." which isn't all that helpful.

I disagree...  It basically say, the files on the disk being removed will be gone once you  remove the drive.  If you wish to save them, move them to a drive that is not being removed.

 

I think some of this has a basis in my lack of understanding on how reiserfs allocates user shares as "High water."

You are mixing apples and oranges.  "reiserfs" has absolutely nothing to do with where files are stored.  It is a file-system that is used on the individual data drives.    You havein your array a set of individual data drives, each with their own file-system, each with their own set of files.  You are presented those file-systems in the "disk" shares.  (disk1, disk2, etc)  When you write a file, the allocation method you elected is used to figure out where to write a file.  It will always be on one of the data disks.    The "user-share" feature of unRAID lets you see a merged vies of those files simulating a single large directory hierarchy of files, even if on multiple physical disks.

Like for instance. I have an unraid server with four hard drives. I have all six seasons of the TV show 24. I start copying them over to the server into a "high water" user share called TV/24 (/mnt/user/TV/24). Unraid magically puts a few episodes on disk 1, a few episodes on disk 2 and so on and so forth. While all the shows and seasons appear to be in their correct spots inside /mnt/user/TV/24, the physical files are spread throughout all the hard drives.

Exactly. 

I've I'm going to copy stuff off one of the hard drives - well that's a time consuming procedure because there are hundreds of sub-folders for all these different seasons/shows/movies/music/photos etc.

Simply log onto unRAID via telnet, or on the system console.  Then type "mc", navigate to the disk (/mnt/disk1 as an example) and then copy the files you wish moved to another drive where space is available.  you do not need to copy individual files, you can copy the top level directories and all the files in them and subdirectories will be copied too.

Let's say a hard drive shits the bed - it's okay because I have unraid and it's raid capabilities. Any one single drive of mine can totally fail, and the rest of the array will pick up the slack - literally recreating the failed drive from parity information. This is amazing.

almost true.  The failed drive is re-constructed from parity in combination with ALL the other data drives in your array.

But I have plenty of extra space on the rest of my server, why not be able to tell the server: you are not getting that hard drive back. Please write all that parity stuff you're magically doing to the existing array's empty space.

Basically because the "raid" works at the individual disk level, and has absolutely no concept of files.  To the "raid" driver, it is just bits.

THAT should be possible. If it isn't automagically possible, there should a way to do it besides manual file copies. This is a raid we're talking about here.

Raid protects you from a disk failure, it has no concept of files....  besides, most times, removing a drive from the array is not desired or expected.

 

Thanks for the additional input - I'm going to take it into consideration while writing the detailed answer for my own question here one of these days!

In EVERY situation, to physically remove a drive permanently from the array, the first step will be identical.

 

1.  Copy  (or move) all files on the drive being removed to a different drives (ones remaining).

Use the /mnt/diskX drives for this.  For best speed, use "mc" on the server, or "cp" or "mv" commands from the command line.

 

Then, you can use any of the other methods to set a new disk configuration without the drive being removed.

Either:

    A:  Stop the array

        un-assign the drive being removed

        set a new initial disk configuration  (three different commands, depending on version of unRAID)

        start array calculating parity.

 

    B:  Copy zeros to the entire /dev/mdX device corresponding to the drive being removed. 

        Stop the array

        un-assign the drive being removed

        set a new initial disk configuration  (three different commands, depending on version of unRAID)

        force unRAID to think that slot 99 in the array is invalid instead of slot 0 (parity) being invalid.

        start the array validating parity.

 

Method "B" is more dangerous, as if you copy zeros to the wrong drive, you just erased the wrong files. (and there is NO way to get them back)

If you get the correct disk, it might be less risky as you never go without parity protection..

 

Method "A" is easier, but you lose parity protection between the time where you set a new disk configuration until after parity is re-calculated.

(In other words, if another drive were to fail in that time, you lose its contents)

 

You already posted the links to the two methods as described in detail.

[abs0lut.zer0]

sorry to butt in..

just an info question ...

in step b. you say it forces unraid to believe slot99 is invalid and not slot0

 

first why slot99 ? and what tells unraid that slot99 is the "empty" disk ?

 

thanks

[Joe L.]

sorry to butt in..

just an info question ...

in step b. you say it forces unraid to believe slot99 is invalid and not slot0

 

first why slot99 ? and what tells unraid that slot99 is the "empty" disk ?

 

thanks

I purposely left out the specific commands.  They are described in the threads linked to earlier.  The "set invalidslot" command has been reported to not work in recent betas, but that might be because of how it was used.

 

As far as "99" goes, it can be any number greater than the highest numbered disk in your array.  Since we can only have 20 data disks, 99 is as good a number as any.  slot 0 is the parity disk.  When initializing an array to a new disk configuration, it is set as invalid by default when you type the initconfig command. (or its equivalent)    We just want the number to not represent a slot in the array, otherwise, that slot would be considered invalid, and re-constructed when the array is next started.

[rutherford]

Joe. L:

Thank you for the long and thoughtful reply. You blew my mind a couple of times.

 

Is the idea of "high water" user shares not unique to unraid?

 

Where does reiserfs come in to save the day as a type of software raid? Is it where the failed/removed drive can be reconstructed on the fly from the datadisks+parity drive?

 

Now that I'm thinking about mc and shell commands - Let's say I'm removing disk2. Doing a

cp /mnt/disk2/* /mnt/user/

will preserve the file structure - right? For example, the above cp command would copying an individual file: /mnt/disk2/TV/24/Season 1/24 - s01e02.avi into the /mnt/user/TV/24/Season 1/<same file name> without overwriting problems because there is only one instance of that "24 - s01e02.avi" on the array - which is on /mnt/disk2/....

 

using the above cp /mnt/disk2/* will recurse in the all the directories and put all the files into the correct /mnt/user/share where it belongs. Ooo, that being said, what procedures/settings should I use to ensure that these files I'm copying from disk2 are not copied back to disk2 as part of that High Water allocation method that I specified for my user share /mnt/user/TV?

 

While unraid is good software, it's not quite awesome enough (yet) to stand on it's own. Users like you, prostuffs1 and our community that keep unraid driving ahead to better documentation stability and value. Thanks again.

[lionelhutz]

The root of your inquiries comes down to the simple fact that there is no mechanism in unRAID to automatically copy the data off of an existing disk and then remove the disk.

 

I didn't see anywhere in the other threads you linked where it was described the automatic recovery of data like you expected.

 

Reiserfs is the file system on each disk and has nothing to do with the parity raid. Reiserfs is another variation of file systems like fat32 or ntfs or ext4.

 

Now that I'm thinking about mc and shell commands - Let's say I'm removing disk2. Doing a

cp /mnt/disk2/* /mnt/user/

will preserve the file structure - right?

 

Well, that won't work so don't spend too much time baffled by it. The files already exist in both locations so you can't copy the file to a location where it already exists. You have to copy directly to another disk where the file doesn't exist. The simplest 1-command move would be to copy the whole disk to the cache, remove it, rebuild the parity and then run the mover to put files back onto other disks.

 

Peter

 

[RobJ]

Or another way, remove the shared files on Disk 2 from the user shares, then copy or move them to the user share:

 

1. On web management page for configuring user shares, remove disk 2 from inclusion in any shares (or exclude it) (eg. disk1,disk2,disk4 -> disk1,disk4)

2. At console, rename the share folder on Disk 2 to a temp name (eg.  rename  /mnt/disk2/Movies  /mnt/disk2/MoviesTemp )

3. At console, copy the Disk 2 shared files to the user share (eg.  cp  -r  /mnt/disk2/MoviesTemp/*  /mnt/user/Movies )

 

You probably will need to reboot between steps 2 and 3, in order for the User Share system to be correctly rebuilt without the files on Disk 2, in order to avoid 'duplicate file' warnings.

 

Disclaimer: I have no personal experience with user shares!