# Steps to move data to bigger drive and remove old drive

## Recommended Posts

Yes, you understand it quite well.

One clarification:  It not only makes no difference which SATA ports each of the drives are connected to (this was NOT true in v4.7, but has been true since v5);  but it also makes no difference which "slot" you assign the drives to, except that the parity drive and (if you have one) the cache drive (or drives if you're using a pool) must be assigned correctly.

i.e. in your case the drives that are assigned as disk1 through disk9 can be randomly assigned to whichever slot you want and everything will still work fine (and parity will still be valid).    No particular reason to change them ... although some like to assign the disks in the physical order they're mounted in the case, for example.

Thanks.

Although I am still puzzled as to how unRaid can keep the parity straight.  My mental model is of a "stripe" (not in the RAID sense,though) which runs through the same sector of each disk.  If there is a disk in the array that is smaller than the parity disk, then the parity calculation for the sectors on the parity disk with a number greater than the last sector on that data disk does not include data from that smaller disk.  (wow, that's harder to describe in words than with a diagram :-)

What I don't understand is that unRaid MUST somehow know how big each disk is and that this information MUST be linked to the serial number.  Otherwise it would need the size linked to the logical disk "slot" number and that does not seem to be the case.

Single parity is actually a very trivial mathematical operation.    As you noted, you can think of each bit on the parity disk as a stripe that goes through the corresponding bit on EVERY disk in the array that HAS a bit in that location.  Clearly if there are disks of different sizes, then not every bit is present on every disk.

But the value of the parity bit is simply based on the binary sum of every corresponding bit in the array disks.  Since UnRAID uses even parity, the parity bit is the appropriate value to make the binary sum a zero.  [if it used odd parity, it would be a 1]

The oft-requested "dual parity" is a far more complex calculation ... it requires a more sophisticated calculation to provide the 2nd level of fault tolerance.  Hopefully that will be implemented "one of these days" ... but it's not high on the list of features a Limetech, so it may be a while.

Clearly UnRAID has to know the size of all of the disks, but that information is available from the disk itself as its mounted.    It does keep track of the disks by serial number, so it knows which disk is assigned to each slot.  But which disk is assigned to which slot makes no difference in the parity calculation.

I got done with the remove-drive-without-loosing-parity procedure and would like to update JarDo's detailed procedure.

This procedure worked for me with unraid 6.0 beta 12. Like JarDo, I can not guarantee results for others.

```1) Start a screen session or work on the physical console of the server, as this may take more than a day
2) With the array started, empty the drive of all contents (move all files to another drive)
3) Stop Samba : "/root/samba stop"
4) Unmount the drive to be removed : "umount /dev/md?" (where ? is Unraid disc number)
4.1) If the command fails issue "lsof /dev/md?" command to see which processes have a hold of the drive.  Stop these processes
4.2 If AFP is stubborn, consider : "killall afpd"
4.3) Try "umount /dev/md?" again
5) Restart Samba : "/root/samba start"
6) At this point the drive may should show 0 (zero) Free Space in the WEB GUI. If it does, move on to step 7
6.1) If, instead of showing zero free, it shows an incorrect size you may experience very slow writing speeds
6.2 In this case, clear enough of the partition that no filesystem is recognized and stop/restart the array
6.3) To make the filesystem unrecognizable : "dd if=/dev/zero of=/dev/md? bs=1G count=1"
6.4) Stop the array
6.5) Restart the array
6.6) Confirm the drive is now listed as unformatted (and is therefore not mounted)
7) Write Zero's to the drive with the dd command "dd if=/dev/zero bs=2048k | pv -s 4000000000000 | dd of=/dev/md? bs=2048k"
7.1) The pv pipe acts as a progress indicator
7.2) Replace "4000000000000" with the size of your drive in bytes (note that so-called 4TB drives are 4 trillion bytes, not 4TiB)
7.3) Wait for a very long time until the process is finished
7.4) If writing to the drive is very slow, then cancel and go back to step 6.1
Stop the array
9) Make a screenshot of your drive assignments
10) From the 'Tools' menu choose the 'New Config' option in the 'UnRAID OS' section.
10.1) this is equivalent to issuing an 'initconfig' command in the console
10.2) This will rename super.dat to super.bak, effectively clearing array configuration
10.3) All drives will be unassigned
11) Reassign all drives to their original slots, while refering to your screenshot.  Leave the drive to be removed unassigned.
11.1) At this point all drives will be BLUE and Unraid is waiting for you to press the Start Button
11.2) Assuming all is good, check the "Parity is valid" box and press the 'Start' button
12) At this point, provided all is OK, all drives should be GREEN and a parity-check will start.
12.1) Note this is a parity check, not a rebuild. If everything went well, it should find 0 parity errors.
13) If everything does appear to be OK (0 Sync Errors) and you want to remove the drive straight away
13.1) Cancel the parity check
13.2) Stop the array
13.3) Shut down the server
13.4) Remove the drive
13.4) Power up the server
13.5) The array should start on its own
13.6) Maybe a good idea to do complete a parity-check.```

Notes:

- The reason this works is you are operating on the md? device, which is the parity protected partition for the data disk you want to remove. Fill that partition with zeros, and parity will not be affected by it's presence, same way as when you are adding a pre-cleared drive, only in reverse.

Another point that may not be obvious is that unRAID needs to know which is the parity disk, but it does not need to know the order of the data disks.  When calculating parity it simply sums all the bits on all the data disks for a given sector so the value stays the same even if the order of the disks is shuffled.    Therefore after doing a 'new config' it is perfectly OK to shuffle the order of the data disks if this is convenient for some reason.

• 3 months later...

I am about to take out 4 of my old 2TB disks, i have already moved the data of to the 4TB replacements.

I have two questions before i start the zeroing process so i can keep my array protected.

1. Can i zero the 4 drives at the same time or do i need to do it 1 by 1.

2. Has anyone an estimate on how long a zeroing process takes eg MB/hour.

Thx.

Rob.

Doing more that one at a time will be slower and cause excessive wear on your parity drive, as all the writes to your parity-protected MD? device will need to be accompanied by a write to parity. Recommend one at a time. The instructions include how to add a progress indicator which will give you the best idea how long it is going to take. But figure about a day per drive for a rough estimate.

Although it won't maintain parity -- i.e. you'll be running "at risk" during the parity sync -- it'd be FAR quicker to just do a New Config, leaving out the disks you want to remove.    If you decide to do this, be sure to run a parity check BEFORE you do it, to confirm all is well.

• 10 months later...

Maybe this will help you.  Below is the procedure I follow to remove a drive from my server without losing parity or access to my array for long periods of time.

- Be sure to record your drive assignments before performing this procedure (take a screen shot of the Main Unraid screen)

- In step #2, make a subdirectory on the target drive to prevent creating a share with duplicates

- Steps #1-5 are done while the array is Started.  You don't stop the array until step #6

- Step #5 can take a very long time, depending upon the size of the drive being zero'ed, but all the while your array is available.

- I have not yet used this procedure on v6, but I don't see why there would be any issues.

- This procedure has been tested on v6b12.

- This is the procedure I use.  I can not guarantee results for others.

- If you plan to write zeros to your drive from a remote console, I suggest using SCREEN.

UPDATE 1

- Added alternate dd syntax in Step 5 to show a progress bar, speed, total time and ETA.

Jarod

I don't understand why a sub directory in step 2.  In another wiki something similar is done when rsync'ing but no sub directory is called for.  https://lime-technology.com/wiki/index.php/Replacing_Multiple_Data_Drives_with_a_Single_Larger_Drive

Can you explain the duplicate comment?

I don't understand why a sub directory in step 2.  In another wiki something similar is done when rsync'ing but no sub directory is called for.  https://lime-technology.com/wiki/index.php/Replacing_Multiple_Data_Drives_with_a_Single_Larger_Drive

Can you explain the duplicate comment?

If there are 2 files on different disks with the same full path and name, only the file on the lowest number disk will be shown in the corresponding user share. This creates confusion and management issues.

/mnt/disk1/folder1/file1.txt --> /mnt/user/folder1/file1.txt

/mnt/disk2/folder1/file1.txt --> doesn't show up in the share "folder1" but still takes up space, and can be very confusing.

The files may be binary duplicates, but don't have to be, so you can't just delete one of them without comparing.

Better just to avoid the possibility altogether.

Will it still have the same file structure for my libraries or will this mess up sickbeard and plex etc...

So would /mnt/disk1/Movies/Antman/Antman.mkv become /mnt/disk2/disk1/Movies/Antman/Antman.mkv or on the Share /user/unraid/disk1/Movies/Antman/Antman.mkv?  Or do you move it back to a root drive when finished? Step missing?

Or does this rsync somehow move the share and pointers ?

jonathanm is correct that there's a brief period of duplication (with possible minor confusion), but I've never seen any serious effects involved.  It is after all just a temporary state while the files are being moved, and as soon as you remove the old drives and restart the array, there's no more duplication.  I've never seen the need for that extra step, unless you are doing this over a long period.

If that period of duplication is still a concern, an alternate method is to temporarily exclude the new drive (in the global share settings), then once all copying is complete, remove the old drives and remove the exclusion and restart the array.

jonathanm is correct that there's a brief period of duplication (with possible minor confusion), but I've never seen any serious effects involved.  It is after all just a temporary state while the files are being moved, and as soon as you remove the old drives and restart the array, there's no more duplication.  I've never seen the need for that extra step, unless you are doing this over a long period.

If that period of duplication is still a concern, an alternate method is to temporarily exclude the new drive (in the global share settings), then once all copying is complete, remove the old drives and remove the exclusion and restart the array.

As long as NOTHING is writing to the user shares during this process, you are fine with the temporary duplicates. If you have background processes (like plex) that could possibly make changes at the user share level, only the lowest number disk will get the changes.

I try to catch the user case that assumes the array will be fully operational while the copy is happening, so why bother to stop using it during the process.

Honestly, this is a rather advanced procedure with many risk points, especially since we are dd'ing zeros to an array device. I would prefer NOT recommending this procedure to anyone not clear on how user and disk shares interact, and a thorough understanding of parity and why the procedure was developed in the first place.

If I would have thought it through to begin with, my answer would have been different. Instead of directly answering the question of why the recommendation of the sub directory was there, I would have redirected the conversation to what the questioner wanted to accomplish, and why they were drawn to this procedure to accomplish it.

jonathanm is correct that there's a brief period of duplication (with possible minor confusion), but I've never seen any serious effects involved.  It is after all just a temporary state while the files are being moved, and as soon as you remove the old drives and restart the array, there's no more duplication.  I've never seen the need for that extra step, unless you are doing this over a long period.

If that period of duplication is still a concern, an alternate method is to temporarily exclude the new drive (in the global share settings), then once all copying is complete, remove the old drives and remove the exclusion and restart the array.

As long as NOTHING is writing to the user shares during this process, you are fine with the temporary duplicates. If you have background processes (like plex) that could possibly make changes at the user share level, only the lowest number disk will get the changes.

That's valid, something I hadn't thought of.  They probably should consider shutting down any processes like Plex during this.

If not, I think I still feel that a temporary drive exclusion is a little more intuitive than a separate subfolder with additional tree move.  Although with ANY of these methods, Plex etc could add or change metadata files *after* their related files had been copied.  Probably best to shut them down.

Any method that requires a user to be very careful about the details or they will lose their data should only be recommended to users that really understand how it all works. There are other (though perhaps less efficient) methods for removing drives already documented that don't require the command line and I think we should always recommend those first to any user we are unsure about.

Excluding the disks from the share makes more sense imo, but wouldn't you also want to exclude the old disk(s)?

Also, in the sub folder method,  I am still curious if the last step is to move the files from the sub folder back to the root of the disks copied to?

And to answer why I'm drawn to this?  Least amount of downtime so plex CAN be used during the process. I'm going from 640 and 1tb drives to 3tb drives.  8 in total. So it's gonna take time

I think it just clicked why the new excluded, as long as it's just reads we are fine, but writes will screw things up as there is risk.  So I think I can do this but just shutdown sabnzbd and transmission.  Still unclear how the sub folder doesn't screw up libraries with an additional folder unless when process is complete you move it back up a folder.

Unless you are running version 5 of unraid, this is the wrong area to discuss this, and you will get more eyeballs and better suggestions if you start your own topic in the General Support (V6) section. I would NOT recommend you follow this particular guide to accomplish what you want, it's just not user friendly and liable to end up with data loss that is unrecoverable.

I suggest starting a post outlining what drives you have right now and how full each one is, what drives you want to end up remaining in the array including new drives. Also, it would be a good idea to outline your user share structure and what share(s) is(are) on each disk now, and what you want to end up with.  I think that a combination of pulling existing drives and replacing (rebuilding) them with your new drives plus using the unbalance plugin will accomplish what you want safely and without much array downtime.

Excluding the disks from the share makes more sense imo, but wouldn't you also want to exclude the old disk(s)?

Also, in the sub folder method,  I am still curious if the last step is to move the files from the sub folder back to the root of the disks copied to?

And to answer why I'm drawn to this?  Least amount of downtime so plex CAN be used during the process. I'm going from 640 and 1tb drives to 3tb drives.  8 in total. So it's gonna take time

I went back to the beginning of this thread, and I'm sorry, this thread should probably have been closed and locked, as obsolete, helpful once but certainly not now, not safely any way.  It involved a number of users hashing out ways to do this, and never really produced a good and complete procedure for v6.  You noticed the subfolder copy, and I assume they thought everyone would know to move the files up a level, later.  Various steps and methods were suggested, some considerably more dangerous than others, but never a complete and safe procedure, ready for new users.

What I would normally recommend instead is Replacing Multiple Data Drives with a Single Larger Drive, but it does need to be updated for the problems of background processes writing to the drives.  *That* is a real problem, and affects ALL of the different methods, and if you are certain you want to keep Plex working throughout the duration of the process, you're going to have to deal with it too.  You are trying to change the underlying drives that Plex is writing to, live, while it's writing to them!

Jonathan was right, we should have probably started a new thread for you, and helped to find a safe hybrid procedure that will accomplish what you want.  I'm sure you won't be the last to want this.

When you say 8 drives, is that 8 640's and 1tb's going to 3 3tb drives, or is that a bunch of 640's and 1tb's going to 8 3tb's?

• 2 weeks later...

Excluding the disks from the share makes more sense imo, but wouldn't you also want to exclude the old disk(s)?

Also, in the sub folder method,  I am still curious if the last step is to move the files from the sub folder back to the root of the disks copied to?

And to answer why I'm drawn to this?  Least amount of downtime so plex CAN be used during the process. I'm going from 640 and 1tb drives to 3tb drives.  8 in total. So it's gonna take time

I went back to the beginning of this thread, and I'm sorry, this thread should probably have been closed and locked, as obsolete, helpful once but certainly not now, not safely any way.  It involved a number of users hashing out ways to do this, and never really produced a good and complete procedure for v6.  You noticed the subfolder copy, and I assume they thought everyone would know to move the files up a level, later.  Various steps and methods were suggested, some considerably more dangerous than others, but never a complete and safe procedure, ready for new users.

What I would normally recommend instead is Replacing Multiple Data Drives with a Single Larger Drive, but it does need to be updated for the problems of background processes writing to the drives.  *That* is a real problem, and affects ALL of the different methods, and if you are certain you want to keep Plex working throughout the duration of the process, you're going to have to deal with it too.  You are trying to change the underlying drives that Plex is writing to, live, while it's writing to them!

Jonathan was right, we should have probably started a new thread for you, and helped to find a safe hybrid procedure that will accomplish what you want.  I'm sure you won't be the last to want this.

When you say 8 drives, is that 8 640's and 1tb's going to 3 3tb drives, or is that a bunch of 640's and 1tb's going to 8 3tb's?

5 x 1TB and 1 x 640gb left all going to 8 x 3tb drives.  I already have done the slow method on the parity and two data drives (remove and rebuild).

Would I just want to exclude the drive from the share while i run unbalance to move the files?

I ran unbalance and move data off of disk 4 then I swapped it out but new 3tb disk is still going to take 7 hours to rebuild.  There wasn't anything on 4?! Is the rebuild the preclear, parity?  Both?

I ran unbalance and move data off of disk 4 then I swapped it out but new 3tb disk is still going to take 7 hours to rebuild.  There wasn't anything on 4?! Is the rebuild the preclear, parity?  Both?

Rebuild must do every bit of the disk regardless of the contents. If you think about it that should be obvious, since parity is on every bit of every disk.

No other disks are affected

## 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.