[SOLVED] Removing disks from array


luca

Recommended Posts

I'm planning to reduce the amount of data currently stored on my unraid server.  This is what I was thinking, please correct any flaws:

 

1. remove a disk from the existing array

2. stop the array

3. upon starting the array, the removed disk shows up as "missing"

4. run tools / new config (keeping existing parity disk)

5. start array / run parity-sync

6. if parity-sync successful, rinse and repeat

 

In step 4. when I re-assign the disks to the array, does it matter they are in the same slots as before, and do I need to respect any gaps (i.e. if disk 15 was unassigned before, does it still need to be unassigned in the new config?)

Edited by luca
Link to comment

I just did this except that I moved the data to one, new larger drive instead of just discarding it.

 

No, there's no need whatsoever to maintain physical-drive-to-logical-disk-ID except for the fact that you may know that certain disks are included/excluded from certain user shares. If you change disk assignments, those in-/ex-clusions will need to change. You'll have to adjust your user shares and your thinking/habits.

 

Also, I believe steps 1 & 2 are swapped - I'm not sure how you'd remove a disk from the array without first stopping the array. Unless you have hot-swap cages and you're planning on physically pulling the drive while the array is started, in which case I'd think that's just taking extra, unnecessary risk. unRAID should survive that with no issue, by why test it unnecessarily. Unless you want to test it...

 

UPDATE: Unless you have a lot of time to kill or your parity syncs are pretty quick, I'd pull all the drives you're planning on removing and do just one parity build. Were something to go wrong, you'd have all the disks with their data on them, and you could put them all back in and re-do a parity build to get back to where you are today.  Even if your parity build only takes 8 hours, you can do at most 3 drives a day if you're monitoring it 24/7...

 

Also, you will need to Build parity, not Sync parity (the system will do that for you), so removing 1 drive at a time really gains you nothing. You can't check the "parity is known to be valid" because, by definition, it can't be. You've removed data from the system that was used to build the drive, therefore it will make parity invalid. If you were to zero out the data with the disk still active in the array, then parity would be in sync once the drive was physically removed, but I'm not sure you can do that...

Edited by FreeMan
Link to comment

You did not mention that before removing any disks you first need to copy any data you want to keep to another location as removing a disk from the array also removes any content it might have.

 

Once you have done that you can remove as many disks as you like in one operation as removing any disk invalidates parity so it will need rebuilding anyway whether you remove one disk or several disks at the same time.    After doing the New Config you are free to change what slots disks are assigned to, and to remove drives you no longer want in the array   When you start the array unRAID will recognise disks previously used by unRAID and their data will be left intact.

Link to comment

@FreeMan  So parity is the only disk I need to worry about in keeping the array integrity, that's going to make the whole process a lot easier.  I don't believe I have any per-disk exclusions, but I'll double check.  The server does have hot-swap cages, but don't mind stopping the array first to avoid any potential issues.

 

@itimpi  That's even better, thanks!  Wow, unRAID very smart :)

Link to comment
3 minutes ago, itimpi said:

You did not mention that before removing any disks you first need to copy any data you want to keep to another location as removing a disk from the array also removes any content it might have.

He did say:

 

16 minutes ago, luca said:

I'm planning to reduce the amount of data currently stored on my unraid server.

 

So I made (the possibly incorrect) assumption that there was no need to move the data to another location. Also, I did call that out:

12 minutes ago, FreeMan said:

I just did this except that I moved the data to one, new larger drive instead of just discarding it. 

 

Link to comment
1 minute ago, luca said:

So parity is the only disk I need to worry about in keeping the array integrity, that's going to make the whole process a lot easier.  I don't believe I have any per-disk exclusions, but I'll double check.  The server does have hot-swap cages, but don't mind stopping the array first to avoid any potential issues.

Correct - parity is the only drive that will need to remain assigned where it was. Otherwise, if you assign a different drive to the parity slot, all the data on that drive will be overwritten with parity data from the rebuild. There is a big warning in the New Config process warning you about this. There's also a check box to tell New Config to keep the existing parity disk and assign it to parity in your New Config.

 

There's also an option to keep the cache disk assigned to the cache disk slot, as well.

 

Before you start, I would strongly recommend getting a screen shot of your existing disk configuration from the Main page, just to be sure you've got all the disk serial numbers, just in case.

Link to comment
8 hours ago, FreeMan said:

Correct - parity is the only drive that will need to remain assigned where it was. Otherwise, if you assign a different drive to the parity slot, all the data on that drive will be overwritten with parity data from the rebuild. There is a big warning in the New Config process warning you about this. There's also a check box to tell New Config to keep the existing parity disk and assign it to parity in your New Config.

 

There's also an option to keep the cache disk assigned to the cache disk slot, as well.

 

Before you start, I would strongly recommend getting a screen shot of your existing disk configuration from the Main page, just to be sure you've got all the disk serial numbers, just in case.

 

I do take a screenshot of the drives, from time to time, which has helped, over the years.  Thank you to FreeMan and itimpi for helping me. :)

Link to comment
12 hours ago, luca said:

 

I do take a screenshot of the drives, from time to time, which has helped, over the years.  Thank you to FreeMan and itimpi for helping me. :)

I take one every* time I make a drive config change. I date it and paste the screen shot into my server config note in Evernote. I move the old dated image to the bottom, so I've got a complete history.

 

*every time except for the previous change where I upgraded to an 8TB parity drive and moved the previous 4TB parity into the array to replace a 2TB drive. Fortunately, I know what changes I made there, but still... there goes my reputation for slightly OCD... :(

Link to comment

Yesterday I finally completed moving the data from the drives to be removed to the drives that were staying.  The server is now rebuilding parity on the new config; the array was shrunk from 22 to 13 drives (plus parity plus cache).  unRAID rocks.  :)

Edited by luca
Link to comment
  • 4 months later...

Sorry to kick this topic as it is already marked solved but I'm still a bit puzzled - because I'm new to unraid everything is "scary" when making changes like this. If I read and understand everything correctly then this is what i should do to remove one (or more) disks at once (I copied this list partially from @Luca

 

1. make screenshot from your array (disk locator plugin is very useful here)

2. stop the array.

3. exclude the disk(s?) at the global share settings.

4. restart the array

5. move all the data from the disk(s?) you want to remove to other disks pref. using krusader (great vid by SpaceInvaderOne on youtube!)

6. stop array

7. physically remove the disk(s?) from the existing array

8. start array (but not possible since there is/are missing disk(s) so go to 9.

9. run tools / new config (keeping existing parity disk(s))

10. assign the remaining disks (I assume the remaining disks needs to be assigned at the exact same place where they were - hence the screenshot)

11. start array / run parity-sync


So euhm.. If I understand the procedure correctly it does not matter if you yank out more then one disk at once as long as the date from those disk has been moved to other disks. Parity needs to be rebuild anyways so.. and yes the array in not protected by parity at this point. From my understanding this is only possible because unraid is not a raid but a jbod with normal filesystem on it..

 

Also.. Can this procedure also be used to rearrange the physical disks (move them into an other physical slots of the array) or does unraid not care where the disks are as long as the order in the unraid-config stays the same?

 

Could someone  confirm this..

 

edit 16feb2019:

12. Do not forget to re-set the global share to include all disks and exclude none if you want unraid to use any new disks in those "slots". I added this morning 3x 3TB from my old rig and was wondering why I had a disk-share named "disk2" and why disk 2 was not spinning up. Disk two was the one I removed couple of days ago.

 

Edited by sjoerd
  • Like 1
Link to comment

That's about it. You can skip step 8 😄

 

You can skip steps 2,3,4 if you don't write any new data to your server while doing this. In fact, it's probably simpler if you don't exclude any disks globally then there won't be any confusion if you rearrange things.

 

And the unBALANCE plugin might be an easier way to accomplish step 5. I haven't looked at that video but I know some configurations of Krusader won't let you work directly with the disks, which is what you need to do here. You should never work with user shares and disks at the same time or you could lose data.

 

As for step 10 and your last question, yes you can rearrange the DATA disks. The main thing you MUST NOT do is assign a data disk to the parity slot since it would be overwritten.

 

Some people are afraid New Config wipes out everything they have done. The only thing it will do is allow you to change your disk assignments, and it won't even write anything except (optionally) parity. And you do have to rebuild parity when removing disks.

 

Just in case, if it offers to format anything at any point, DON'T.

  • Like 1
  • Upvote 1
Link to comment
  • 10 months later...

this is great info.  I was lookign to take a drive out of my array which i dont use anymore and i followed these steps.  unfortunately my screenshot got corrupted somehow so I don't know which drives were in which slot.

 

I did the tools > new confiuration and preserved the parity slot, but i don't know which drives were in which slots.

 

it sounds like this shouldn't matter, but i just want to make sure before i reassign all the disks.

 

how does that work?  if I have a user share that pulls from disk 1 and 3 for instance, but then i rebuild my config and the disks which were in slot 1 and 3 are not in slot 5 and 6 for instance, how would unraid know where to pull the dat for those user shares?

Link to comment

Unraid just gets the data for each user share completely based on which top level folders exist on each disk. The user shares ARE the top level folders with the same name as the user share.

 

That is how it works for reading the user shares. For writing the user shares the settings for each user share are considered in addition to which disks contain them, and the user share settings take precedence, so for example if you exclude a specific disk, that excludes it for writing, but for reading any disk with the folder is included.

Link to comment

Thanks for the quick reply!   So if I went to tools > new config.  And I saved the parity drive then all other drives are currently unassigned. 
 

So since I don’t know which slots each disk was assigned to, can I assign the disks to whatever slot I want and keep my data and user shares intact?

 

are there any other steps I need to follow to ensure that parity is rebuilt and the user share still work if some of my disks get assigned to different slots(which they inevitably will)?

Link to comment

One of the choices with New Config is to keep all the assignments. All that means is it won't forget any, but you can still change them including unassigning any or moving them to different slots. So keeping only parity isn't really necessary to allow you to change the others.

 

But if you have done that then every thing should still be fine.

 

There are only two thing that can cause loss of data. One is assigning any data disk to any parity slot, since that would result in overwriting the data with parity.

 

The other is formatting any disk that you know has data on it. Just in case something goes wrong with a connection or something, don't agree to format anything.

Link to comment
1 hour ago, trurl said:

The other is formatting any disk that you know has data on it.

Maybe I've just worked with computers for far too long, but I'm constantly amazed by the number of people who post here saying they ran into issues, were given an option to format something they thought had data on it, and clicked "OK". Formatting a disk will never result in being able to access the data (without an expensive trip to the data recovery services).

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.