I currently have 5 2tb drives in my array. 1 Parity, 4 data

One of my drives has redballed but I want to replace it with a 4tb drive instead of a 2tb.

 

I know my parity must be the largest drive so I was wondering if I replace my parity drive with the 4tb will I then be able to replace my

dead drive with a 4tb drive and not lose data?. Or do I HAVE to rebuild the drive first with a 2tb or smaller and then start to add 4tb drives?

 

Thanks

 

I currently have 5 2tb drives in my array. 1 Parity, 4 data

One of my drives has redballed but I want to replace it with a 4tb drive instead of a 2tb.

 

I know my parity must be the largest drive so I was wondering if I replace my parity drive with the 4tb will I then be able to replace my

dead drive with a 4tb drive and not lose data?. Or do I HAVE to rebuild the drive first with a 2tb or smaller and then start to add 4tb drives?

 

Thanks

 

Since the parity drive is what holds the data in order to rebuild your failed drive you are going to need to rebuild that drive before replacing parity. If you put a new parity drive in it's going to create a whole new parity set based on your working drives and there is no way to recover your failed drive (considering the new parity drive won't even know there is a missing disk since it wasn't used when parity was calculated).

 

IMHO I would replace the Data drive first and rebuild it. Then upgrade your Parity Drive. AFAIK to rebuild a Parity Drive (edit: to original state) requires all Data Drives.

 

You should be able to do the rebuild onto the old parity drive by putting the 4TB in the parity slot and assigning the old parity drive to the failed drive slot. Then after a full parity check, you could replace the old parity drive with another 4TB.

 

You can only ever replace 1 drive at a time without data loss, because unraid's parity recovery relies on ALL the drives to reconstruct the data for 1 missing drive.

 

HOWEVER... it's a risky procedure because there are so many things that can go wrong. It would be safer to rebuild to a 2TB first, then upgrade the parity drive after the array is healthy again.

 

Do you have backups of all your critical data? Are all your other drives healthy? Which version of unraid are you running? Have you precleared the 4TB drives to make sure they are error free and work in your system?

 

Also, you may want to Preclear your new drives first.

Do we know for sure that the redballed drive is bad? Maybe it is just a connection problem. If the drive is good then you can rebuild it onto itself, then worry about upsizing parity and other disks after the array is back to good health.

You should be able to do the rebuild onto the old parity drive by putting the 4TB in the parity slot and assigning the old parity drive to the failed drive slot. Then after a full parity check, you could replace the old parity drive with another 4TB.

 

Really? I've never seen this proposed before. Are you sure this would work? I would think it would risk data corruption. As I think it through I would think there is no guarantee that the parity data binary bits are going to match the missing disk. Is this explained somewhere?

A good investment that will make your unRAID experience so much better:

 

http://www.aleratec.com/1-1-usb-3-sata-hard-disk-drive-duplicator-dock-350123.html

There are a couple of different strategies.

 

1 - there is a process called parity swap disable that would allow you to replace parity with a bigger disk and then rebuild your failed disk into the old parity. You'd have to look up the instructions.

 

2 - another option is to mount another disk outside the array or using your cache slot (disabling mover script) and copy the data from your failed disk (which unRaid is simulating). Once copied to your new disk, you could do a new config and add a larger parity drive and rebuild parity.

 

As trurl points out, though, your issue may be connection related. If you are doing rebuild the connections need to be rock solid or you face rebuild failure which is more difficult to recover from.

You should be able to do the rebuild onto the old parity drive by putting the 4TB in the parity slot and assigning the old parity drive to the failed drive slot. Then after a full parity check, you could replace the old parity drive with another 4TB.

 

Really? I've never seen this proposed before. Are you sure this would work? I would think it would risk data corruption. As I think it through I would think there is no guarantee that the parity data binary bits are going to match the missing disk. Is this explained somewhere?

The procedure is called swap-disable, and it works by making a full binary copy of the old parity drive to the new drive, then overwriting the old parity drive with the rebuild information of the failed drive from the freshly copied parity and the rest of the drives. It's more risky because the copy of the parity drive isn't really fully tested before it's used to overwrite the old parity information. If everything works properly, it's fine. If the copy doesn't, then you have overwritten your old parity drive with junk. http://lime-technology.com/wiki/index.php/Un-Official_UnRAID_Manual#Replace_a_failed_disk

 

As I said, it's the riskiest way to proceed at this point. I personally wouldn't do it without knowing I had full current backups.

You should be able to do the rebuild onto the old parity drive by putting the 4TB in the parity slot and assigning the old parity drive to the failed drive slot. Then after a full parity check, you could replace the old parity drive with another 4TB.

 

Really? I've never seen this proposed before. Are you sure this would work? I would think it would risk data corruption. As I think it through I would think there is no guarantee that the parity data binary bits are going to match the missing disk. Is this explained somewhere?

The procedure is called swap-disable, and it works by making a full binary copy of the old parity drive to the new drive, then overwriting the old parity drive with the rebuild information of the failed drive from the freshly copied parity and the rest of the drives. It's more risky because the copy of the parity drive isn't really fully tested before it's used to overwrite the old parity information. If everything works properly, it's fine. If the copy doesn't, then you have overwritten your old parity drive with junk. http://lime-technology.com/wiki/index.php/Un-Official_UnRAID_Manual#Replace_a_failed_disk

 

As I said, it's the riskiest way to proceed at this point. I personally wouldn't do it without knowing I had full current backups.

 

Looks interesting, but I wouldn't risk it with my data either.

I agree with jonathanm => the "swap-disable" process is documented, and usually works fine, but is not my first choice for this situation if you don't have backups.    There have also been some reports of it not working correctly with v5, but it's not clear that those who had that issue did it correctly ... and it must be done EXACTLY as outlined in the manual.

 

FYI, here's the relevant section from the manual:

--------------------------------------------------------------------------------

You must replace a failed disk with a disk which is as big or bigger than the original and not bigger than the parity disk. If the replacement disk is larger than your parity disk, then the system permits a special configuration change called swap-disable.

 

For swap-disable, you use your existing parity disk to replace the failed disk, and you install your new big disk as the parity disk:

1. Stop the array.

2. Power down the unit.

3. Replace the parity hard disk with a new bigger one.

4. Replace the failed hard disk with you old parity disk.

5. Power up the unit.

6. Start the array.

 

When you start the array, the system will first copy the parity information to the new parity disk, and then reconstruct the contents of the failed disk.

---------------------------------------------------------------------------------

 

Regardless of how you choose to proceed, it's a good idea to first copy ALL of the data from the failed disk to another disk connected to a PC on your network if you don't already have backups.

 

THEN you could do a swap-disable (as long as it works, you're done);  or you could simply create a new config with both a 4TB parity and a new 4TB drive added to the array, and then copy the data back to the array.    The swap-disable should be fine -- but having the relevant data backed up beforehand is always a good idea.  Note that if you do the swap-disable, you'll still need to then replace the old parity drive with one of your new 4TB drives (or just add it as another storage drive).

 

 

Safest and easiest root is a bit more expensive...

 

1) Get TWO replacement harddrives

2) put the 1st one in and have it replace the failed drive

 

(now your data is safe again but it the replacement drive is bigger then your parity drive you cannot use that extra space)

 

Now if you want to take advantage of that extra space:

 

3) put the 2nd drive in and make that your new parity drive

 

(now your parity drive is the biggest drive again and the extra space you got in step 2 is usable)

 

4) make the old parity drive a new data drive, giving you even more storage.

 

Since storage tends to grow anyhow I would actually advise this route.. It is the easiest, and yes its more expensive, but if you take into account that you will probably will need to upgrade at some time anyhow, it just pulls that investment..

Safest and easiest root is a bit more expensive...

 

1) Get TWO replacement harddrives

2) put the 1st one in and have it replace the failed drive

 

(now your data is safe again but it the replacement drive is bigger then your parity drive you cannot use that extra space)

It is not quite that easy!  unRAID will not let you install a data drive that it thinks is larger than the parity drive.  The closest is to use the swap-disable process where you simultaneously put in a larger parity drive and make the old parity drive replace the failed drive.

The most direct route is to simply do the swap-disable with a new 4TB drive and the old parity drive;  then, after it's done, replace the old parity drive with the 2nd new 4TB drive.

 

But as I noted earlier, if you don't have backups of your data, be sure to create a backup copy of the data from the failed drive before you do that.    If you DO have backups, then simply do the swap-disable (but even in the case be sure you have a directory listing for the failed drive, so you know for sure which files were on the drive).

 

There are a couple of different strategies.

 

1 - there is a process called parity swap disable that would allow you to replace parity with a bigger disk and then rebuild your failed disk into the old parity. You'd have to look up the instructions.

 

2 - another option is to mount another disk outside the array or using your cache slot (disabling mover script) and copy the data from your failed disk (which unRaid is simulating). Once copied to your new disk, you could do a new config and add a larger parity drive and rebuild parity.

 

As trurl points out, though, your issue may be connection related. If you are doing rebuild the connections need to be rock solid or you face rebuild failure which is more difficult to recover from.

 

The second option above was never discussed and sorry off got buried in the responses. I have done this or similar many times (not just with failures but also when swapping out a bunch of smaller disks for larger ones all at one time). Copies go at full write speed in exchange for one parity build at the end.

 

Good luck!

Safest and easiest root is a bit more expensive...

 

1) Get TWO replacement harddrives

2) put the 1st one in and have it replace the failed drive

 

(now your data is safe again but it the replacement drive is bigger then your parity drive you cannot use that extra space)

It is not quite that easy!  unRAID will not let you install a data drive that it thinks is larger than the parity drive.  The closest is to use the swap-disable process where you simultaneously put in a larger parity drive and make the old parity drive replace the failed drive.

 

 

Seriously ?  wayw... got that fully wrong then... Have allways been in the perception that it would be possible to have a larger datadrive bt tht you simply would not be alble to use the extra space.. Ah well.. I guess that regularly replacing the parity drive with the larget one on the market has some sense then..

... Have allways been in the perception that it would be possible to have a larger datadrive bt tht you simply would not be alble to use the extra space.. Ah well.. I guess that regularly replacing the parity drive with the larget one on the market has some sense then..

 

Absolutely cannot use a larger drive than the parity drive.    There IS a way to do it in a pinch ... but it's FAR better to just use the correct size drive for a replacement.    You should ALWAYS have a spare drive handy that's equal to the size of your parity drive so you can use it for a rebuild in the event of a drive failure.

 

IF you only have a larger drive, you can use the "SetMax" function in the free HDAT2 utility to effectively turn the larger drive into a smaller one        Note that when you eventually want to change it back to its native size, you'll lose all the data on it, so this isn't really a good idea; but some folks have just not wanted to spend the $$ for a new drive of the correct size, so it IS possible.

 

[The most common case of this I've seen is when you RMA a drive and the manufacturer replaces it with a larger one ... a fairly common occurrence these days]

 

HDAT2 is free and is available here:  http://www.hdat2.com/

... Have allways been in the perception that it would be possible to have a larger datadrive bt tht you simply would not be alble to use the extra space.. Ah well.. I guess that regularly replacing the parity drive with the larget one on the market has some sense then..

 

Absolutely cannot use a larger drive than the parity drive.    There IS a way to do it in a pinch ... but it's FAR better to just use the correct size drive for a replacement.    You should ALWAYS have a spare drive handy that's equal to the size of your parity drive so you can use it for a rebuild in the event of a drive failure.

 

IF you only have a larger drive, you can use the "SetMax" function in the free HDAT2 utility to effectively turn the larger drive into a smaller one        Note that when you eventually want to change it back to its native size, you'll lose all the data on it, so this isn't really a good idea; but some folks have just not wanted to spend the $$ for a new drive of the correct size, so it IS possible.

 

[The most common case of this I've seen is when you RMA a drive and the manufacturer replaces it with a larger one ... a fairly common occurrence these days]

 

HDAT2 is free and is available here:  http://www.hdat2.com/

 

This tool just creates an HPA on the drive - and there are several ways to do it.

 

Again, not the best solution, but if you made a 4T drive your parity, and it has an HPA, adding an HPA to a data drive is a better solution than swapping around parity which would be a royal pain to get you way less than a MB! (Now if you're adding a 6T drive, this makes no sense. You'd want to install the 6T as the new parity and rebuild (see the how to in my sig).)

 

The real danger of HPAs, BTW, is having a motherboard that wants to add them. Some MBs are not so smart, and try to put an HPA on an already LINUX formatted disk. This can have a dramatically bad impact! Having a BIOS option to stop it from creating the HPA is great, but if the BIOS option defaults to "on", then in some situations it may happen unexpectedly. It is therefore best if the BIOS doesn't do it, but second best is a BIOS option that defaults to off.

FWIW, I'm not aware of ANY motherboard/BIOS that will add an HPA to a drive IF there is already one with an HPA on it.  The most well-known "offender" is some Gigabyte boards; and they all use the following logic to "back up" the BIOS:  If it finds a backup of the BIOS on any current drive, then no action is taken;  if it does NOT find a backup, then it creates an HPA on the first enumerated drive  with available unpartitioned space and backs up the BIOS to that drive.

 

The simplest workaround if you're using a Gigabyte board that doesn't allow you to disable the "BIOS Backup" function is to install a drive BEFORE you install UnRAID;  attempt to boot (doesn't matter if there's an OS) ... which will create the HPA/backup on that drive;  and then install the remaining drives you want to use -- being certain the drive you originally installed is NOT assigned as parity.    If you have enough SATA ports, you may not want to use that drive at all      [i know a few folks who just put in an ancient tiny SATA drive for that function.]

 

The simplest workaround if you're using a Gigabyte board that doesn't allow you to disable the "BIOS Backup" function is to install a drive BEFORE you install UnRAID;  attempt to boot (doesn't matter if there's an OS) ... which will create the HPA/backup on that drive;  and then install the remaining drives you want to use -- being certain the drive you originally installed is NOT assigned as parity.    If you have enough SATA ports, you may not want to use that drive at all      [i know a few folks who just put in an ancient tiny SATA drive for that function.]

Until the drive that you are using for a sacrificial anode decides to fail, or just takes too long for the motherboard's liking, and it decides you need a backup on another drive. Too risky for my taste.

Until the drive that you are using for a sacrificial anode decides to fail, or just takes too long for the motherboard's liking, and it decides you need a backup on another drive. Too risky for my taste.

 

I agree ... and don't use Gigabyte boards for that reason.    But the fact is it won't add an HPA to a drive unless there's unpartitioned space, so the only risk is when you're adding a new drive ... and even then the only time it would have any real consequences is if it was a new parity drive.

 

FWIW, I'm not aware of ANY motherboard/BIOS that will add an HPA to a drive IF there is already one with an HPA on it.  The most well-known "offender" is some Gigabyte boards; and they all use the following logic to "back up" the BIOS:  If it finds a backup of the BIOS on any current drive, then no action is taken;  if it does NOT find a backup, then it creates an HPA on the first enumerated drive  with available unpartitioned space and backs up the BIOS to that drive.

 

The simplest workaround if you're using a Gigabyte board that doesn't allow you to disable the "BIOS Backup" function is to install a drive BEFORE you install UnRAID;  attempt to boot (doesn't matter if there's an OS) ... which will create the HPA/backup on that drive;  and then install the remaining drives you want to use -- being certain the drive you originally installed is NOT assigned as parity.    If you have enough SATA ports, you may not want to use that drive at all      [i know a few folks who just put in an ancient tiny SATA drive for that function.]

 

I think it is actually looking for an HPA on the first disk, not any old disk. I may be wrong but as BIOS'es shift drive order based on a variety of factors, I think it is more than possible to have an HPA on one disk, and the BIOS adds an HPA to another.

 

Maybe if you have a gigabyte MB, you just need to add an HPA to every disk.

i find it fun that when you buy a san or nas of lets say 20 tb, they say backup your data first.... IT IS the backups... lol how theh hell you gonana backup 20 TB ?

I think it is actually looking for an HPA on the first disk, not any old disk.

 

No, not true.  GB "BIOS Backup" motherboards always search starting from SATA-0 upwards, and will STOP if they find a disk with a backup (NOT just an HPA, but an HPA in the special GB format that saves the BIOS backup).    If they don't find one, they'll add a backup to the first disk it encounters that has unformatted space available to create an HPA (it won't shrink an existing partition).

 

 

Maybe if you have a gigabyte MB, you just need to add an HPA to every disk.

 

You couldn't do this even if you wanted to -- at least not without a lot of "fiddling."  [You could connect one disk at a time (disconnecting all others) in an unpartitioned state, and then boot.  Repeat that for all disks and you'll ultimately have an HPA BIOS Backup on every disk  ]