My full array currently has 12 drives in it (2, 10TB Parity Drives and 10 data drives. 5, 4TB drives, 2, 8TB drives, 2, 1.5TB drives and a single 10TB). I am wanting to get 2 more 10TB drives and replace some of the older smaller, pre-fail drives in the array. Specifically the 1.5TB drives and a VERY old HGST 4 TB drive that I would like to remove. Is it possible to do this? I can pull 2 drives at once and still rebuild since I have 2 parity drives right? I would think it would be a long process of pull the 4TB replace with a 10TB and rebuild and then do the same with the 1.5TB drives? Of course doing a pre-clear etc prior to, but as long as the original drives are still good and available there isn't really much risk in doing so is there?

 

Thanks,

You can only replace and rebuild one to one using built in procedures. If you want to empty a drive slot without substituting a fresh drive, you will have to manually copy all the data from that slot to another destination, remove the drive, and rebuild parity without it.

 

How much free space do you have total right now before changing out drives?

 

If you are on the bleeding edge of running out of space, I think I would replace one of the 1.5's' with a 10 normally, and fill the remaining 8.5ish with the contents of the other 1.5 and the 4 that you want to remove. After that data is safely copied, not moved, then set a new config and rebuild parity with the old drives removed and the second 10 added. That way you still have all the data intact on all the removed drives in case you have issues.

I just thew in a 10TB drive that is completely empty so theoretically, I could move the entire contents of the 4 and the 2, 1.5 drives onto the 10 and still have room to spare. Could I think just remove the other 3, unassign them and rebuild?

Don't move, COPY to the empty 10TB. That way you can verify the data is intact, and when you remove the disks they can serve as backups for that portion of your data.

 

What is your experience level with linux command line?

 

How much of that data is archival and not subject to additions, and how much is live?

 

Are you comfortable with temporarily making all that data invisible to user shares until it's copied to the 10TB?

Good call on the copy! Not incredibly experienced with the Linux command. The data on the drive is all technically "Live" because it's mostly media for my Plex container and part of my caAppdata Backup lives there as well.

Can you live with taking your media dockers down for the duration of each drive's copy operation? Otherwise it's going to get a little hairy trying to manage which drive is being written to and updated, the original or the new.

 

Here is the command line I use when I migrate data from disk to disk.

rsync -arv /mnt/diskX/ /mnt/diskY
rsync -narcv /mnt/diskX/ /mnt/diskY

The first line does the copy, with no verification. The second line does a verify, and if anything doesn't match, it gets flagged. Ideally the second command just chews through the drives and doesn't actually do anything because the first copy went perfectly. 🙂

 

The syntax is VERY important, note the trailing slashes on the source part (diskX) and the LACK of trailing slashes on the destination part (diskY).

 

BTW, copying from drive to drive is SLOW, because you have a minimum of three drives involved, source, destination, and parity. Moving is even slower, because each deletion is a write to the source drive, so the parity drive gets hammered hard keeping up with writes to both source and destination.

Edited March 15, 20197 yr by jonathanm
correction

I am actually copying one of the 1.5TB's over to the 10 right now using the Unbalance plugin as I've moved directories before that way and was successful. I was going to see how that goes before moving to command line that way I don't have to take the dockers down. Unbalance is using 

rsync -avPR -X so I'm doing some more digging into rsync to learn a little about the different flags available.

Quote

BTW, copying from drive to drive is SLOW, because you have a minimum of three drives involved, source, destination, and parity. Moving is even slower, because each deletion is a write to the source drive, so the parity drive gets hammered hard keeping up with writes to both source and destination.

That is extremely helpful. Common sense tells me that a move is faster than a copy, but that makes perfect sense when you throw in the extra drive activity.

Unbalance actually has a verify stage after the copy is finished that runs a rsync -rcvPR -X. I was looking at the command syntax you sent over and since the 2nd line is -narcv wouldn't that just be a dry run because of the -n?

 

Thanks for all the tips. It's showing me that I need to read the rsync syntax and I'm wanting to get more familiar with the Linux command line now as well. Without this I would have tanked my server somehow. :)

2 hours ago, IndianaJoe1216 said:

2nd line is -narcv wouldn't that just be a dry run because of the -n?

Yep, you caught me. I don't actually want the second run to do anything, I want to know if something went wrong with the first run so I can fix it.

Does using unbalance matter vs command line especially if I can verify?

 

Also, once the copy is completed and validated what's the process for removing the disks? At this point the data on the disks is on the 1.5TB and the 10TB in the array so the parity would reflect that so I can't just pull the disks and leave those slots empty. That means I would have to do a new config and then rebuild parity? 

Edited March 15, 20197 yr by IndianaJoe1216
Added a Q

53 minutes ago, IndianaJoe1216 said:

Does using unbalance matter vs command line especially if I can verify?

 

Also, once the copy is completed and validated what's the process for removing the disks? At this point the data on the disks is on the 1.5TB and the 10TB in the array so the parity would reflect that so I can't just pull the disks and leave those slots empty. That means I would have to do a new config and then rebuild parity? 

I'm not all that familiar with unbalance, to me it's pretty much just a GUI front end for rsync, which I have a fairly good handle doing manually. If it copied the files and left the originals in place, then you can verify with whatever tools you are familiar with. There are many different file comparison methods out there.

 

Yes, once all the data is where you want it, then it's new config time. Bonus, if you want to add more 10TB drives, you can do it during the new config phase without worrying about clearing them. Just make sure they are tested somehow, because once a drive is added, it becomes part of parity and will effect recovery of other drives, whether there is data on it or not. Parity calculates the entirety of the drive, not just the data.

 

The only other gotcha I can think of for you at this moment is that if you were to access the array normally or a docker accesses a user share and modify one of the files that is currently duplicated or adds a new file, you may be dealing with a file on the old drive instead of the new, depending on the drive number. Lower drive numbers take precedence for duplicate resolution. Be mindful of any write activities until the old drives are removed.

There are 3 shares that are written to the most often (which are the only 3 on those drives) and when I started the first copy I went ahead and adjusted the shares to exclude the 2, 1.5TB disks. Yeah good call on add the other drives during the new config process, but I have 2 Exos enterprise drives on the way and I want to swap my parity drives out with those after I rebuild which unfortunately means rebuilding several more times so I am looking at ways to minimize the damage there, but that's still TBD. 

 

Wow I am an idiot. Since I am rebuilding anyways I could just do a new config and pull the parity drives at the same time since they are going to be rebuilt anyways. That would allow the new drives to be rebuilt as parity and I could add the current ones to the array no problem.

Edited March 18, 20197 yr by IndianaJoe1216
Not thinking during original post

Parity rebuild in progress! Thanks for all your help! 25TB free is a BEAUTIFUL sight!