Migrating RAID to new motherboard
I've been running on the same CPU/Motherboard combo for about 5 years now, and my mobo is handling my RAID-5 array today. My system's starting to have some issues that is prompting me to look at a new motherboard/CPU. However, I'm assuming that since the RAID volume structure info is stored on my current motherboard, that I would lose that when going to a new motherboard, and that would basically invalidate the RAID array.
Am I correct in this, and if so, is there any way to safely migrate a RAID array to a new controller? I'm even contemplating just getting a separate controller for handling the array, since I've read that motherboard controllers are just not up to the job of handling RAID (at least not very well, compared to a dedicated controller card). However, a separate controller card still has the same migration issue.
Am I correct in this, and if so, is there any way to safely migrate a RAID array to a new controller? I'm even contemplating just getting a separate controller for handling the array, since I've read that motherboard controllers are just not up to the job of handling RAID (at least not very well, compared to a dedicated controller card). However, a separate controller card still has the same migration issue.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
May or may not be, depending on your hardware, BUT its a very big risk of data loss doing so. So a good backup should ALWAYS be there.
Remember, a RAID is NO Backup, sometimes the RAID controllers went havoc, destroying all data, sometimes a power surge kills more than one HDD, etc. pp.
Furthermore RAID5 is not secure nowadays anymore, why, you can read here.
http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
Same applies for RAID6 in a few years.
Remember, a RAID is NO Backup, sometimes the RAID controllers went havoc, destroying all data, sometimes a power surge kills more than one HDD, etc. pp.
Furthermore RAID5 is not secure nowadays anymore, why, you can read here.
http://www.zdnet.com/article/why-raid-5-stops-working-in-2009/
Same applies for RAID6 in a few years.
>> , I'm assuming that since the RAID volume structure info is stored on my current motherboard << don't you know you have a separate raid controller?
that's the first thing to look up (you can probably install it on a new mobo)
but - if you choose a more recent mobo, chances are you'll need another RAid controller also - and then your only way is BACKUP - and rebuild from a fresh setup
that's the first thing to look up (you can probably install it on a new mobo)
but - if you choose a more recent mobo, chances are you'll need another RAid controller also - and then your only way is BACKUP - and rebuild from a fresh setup
You need to take backup of existing configuration and restore it over new one (best if you get the config with hardware RAID controller). Then you need to adjust the OS to new hardware so that it boots properly.
Have a look on this article: https://www.experts-exchange.com/articles/2569/Windows-OS-migration-to-dissimilar-hardware-How-to-migrate-to-new-hardware-without-OS-reinstallation.html
Have a look on this article: https://www.experts-exchange.com/articles/2569/Windows-OS-migration-to-dissimilar-hardware-How-to-migrate-to-new-hardware-without-OS-reinstallation.html
ASKER
@nobus - I am not using a separate/dedicated RAID controller. I am using the controller that is embedded on the motherboard. I don't believe that can be removed and installed on a new motherboard.
@andreas - I do have a separate backup service (CrashPlan), but I was trying to avoid having to re-initialize the array, then download multiple terabytes of data back onto it (or even copying all that data). I was hoping to avoid any unnecessary I/O.
As a side note, the concept that RAID-5 or RAID-6 is dead or insecure is simply not correct. Someone who didn't understand probabilities and HDD error handling wrote up an anti-RAID article several years ago, and this article is just basically repeating it. The problem with the article is that it assumes that bigger hard drives = more chances of errors, and so time = bigger hard drives = less-reliable RAID arrays. The fact that the article tries to tie it to a specific year is just rubbish.
1. It assumes that everyone will buy bigger hard drives every year, and that they'll always try to make bigger-and-bigger RAID arrays.
2. It ignores the error-handling and sector-remapping that goes on automatically behind the scenes during normal usage.
3. It relies on the idea that there has to be a total HDD failure PLUS another, brand-new URE on a second disk during the rebuild - a URE that had not already been handled by the disk itself.
4. It takes the vendor spec'd URE for a disk and assumes that it is a given constant (that there will ALWAYS be an error), when that spec is defining an ACCEPTABLE range of errors. A vendor isn't saying, "Hey, we're producing a 4 terabyte hard drive, and no matter what you do, that sucker is going to come with some bad sectors." It's saying, "While we try to make every disk come with 100% good sectors, the bigger the hard drive, the higher the chance of a disk having a bad sector or two. And if there's a bad sector or two, our disk should automatically remap it and still report as reliable."
5. It assumes that RAIDs are otherwise infallible, and any infallibility means they are insecure or bad. Realistically, anything can fail with enough errors, and that has never changed. If my non-RAID disks fail tomorrow, they'll be completely inaccessible. If I have a completely mirrored array and more than half of the disks fail, then the array will experience data loss.
So RAID arrays are still quite useful and still offer more security than individual, non-RAID disks. I'm sure a lot of comments on that article will probably echo some of the above.
@noxcho - Any idea if there are utilities out there that can migrate the configuration from motherboard controllers? That's ultimately what I'm after.
@andreas - I do have a separate backup service (CrashPlan), but I was trying to avoid having to re-initialize the array, then download multiple terabytes of data back onto it (or even copying all that data). I was hoping to avoid any unnecessary I/O.
As a side note, the concept that RAID-5 or RAID-6 is dead or insecure is simply not correct. Someone who didn't understand probabilities and HDD error handling wrote up an anti-RAID article several years ago, and this article is just basically repeating it. The problem with the article is that it assumes that bigger hard drives = more chances of errors, and so time = bigger hard drives = less-reliable RAID arrays. The fact that the article tries to tie it to a specific year is just rubbish.
1. It assumes that everyone will buy bigger hard drives every year, and that they'll always try to make bigger-and-bigger RAID arrays.
2. It ignores the error-handling and sector-remapping that goes on automatically behind the scenes during normal usage.
3. It relies on the idea that there has to be a total HDD failure PLUS another, brand-new URE on a second disk during the rebuild - a URE that had not already been handled by the disk itself.
4. It takes the vendor spec'd URE for a disk and assumes that it is a given constant (that there will ALWAYS be an error), when that spec is defining an ACCEPTABLE range of errors. A vendor isn't saying, "Hey, we're producing a 4 terabyte hard drive, and no matter what you do, that sucker is going to come with some bad sectors." It's saying, "While we try to make every disk come with 100% good sectors, the bigger the hard drive, the higher the chance of a disk having a bad sector or two. And if there's a bad sector or two, our disk should automatically remap it and still report as reliable."
5. It assumes that RAIDs are otherwise infallible, and any infallibility means they are insecure or bad. Realistically, anything can fail with enough errors, and that has never changed. If my non-RAID disks fail tomorrow, they'll be completely inaccessible. If I have a completely mirrored array and more than half of the disks fail, then the array will experience data loss.
So RAID arrays are still quite useful and still offer more security than individual, non-RAID disks. I'm sure a lot of comments on that article will probably echo some of the above.
@noxcho - Any idea if there are utilities out there that can migrate the configuration from motherboard controllers? That's ultimately what I'm after.
You don't need to migrate the motherboard configuration. The RAID you are using is a fake RAID based on so called fake RAID controller. There is no such tool which could migrate the NVRAM from one motherboard to another.
What you need to do is to take backup of your HDDs (as Windows sees them) and restore it over the new configuration.
What you need to do is to take backup of your HDDs (as Windows sees them) and restore it over the new configuration.
exactly as i posted :
but - if you choose a more recent mobo, chances are you'll need another RAid controller also - and then your only way is BACKUP - and rebuild from a fresh setup
but - if you choose a more recent mobo, chances are you'll need another RAid controller also - and then your only way is BACKUP - and rebuild from a fresh setup
@gr8gonzo
1. yes you are true if you use smaller discs you are safer.
2. remapping is only done on a WRITE operation to a defective sector, If a disk reports an uncorrectable sector its bad until new information is written back to it.
Transparent remapping can only be done if the disk can read the block at least one more time and got the block will go bad as error correction was at its limits.
Was a block not accessed tooo long and decayed too long so that error correction cant repair the failing data, the block will fail even there are spare sectors to remap left.
On a next WRITE to the defective block that cant be corrected (Thats actually what URE is defined) the block will be "repaired" by remapping, but that too late for the RAID
one defective block whilst a rebuild on a replaced disk in raid 5 will give a double error and break the RAID.
3 see too, there may be unhalndled UREs if disks are old and some data is rarely accessed.
4. correct but looking at my own failure statistics i wont bet on it. Recently we had a few deaths of some WD reds and some WE enterprise, all still WITHIN the warranty, they had unhandled UREs on archive HDDs with data written once and rarely read, some files never again after writing.
A reformat "repaired" the disks in the fashion that the defective blocks were remapped to spare ones. one disk was in the hundreds of decective blocks.
5. correct.
Furthermore theres a chance you hace 2 idsks of the same faulty batch in your RAID and that the disk will break soon after resync begun. The resync on a $TB+ HDD can take quite a long in days range and so the additional continuosl stress may crash the 2nd faulty disk too.
So Im still thinking RIAD5 shouldnt be considered out of redundancy reasons, its good for assembling LARGE volumes of smaller disks, with a chance of redundancy if one disk fail.
1. yes you are true if you use smaller discs you are safer.
2. remapping is only done on a WRITE operation to a defective sector, If a disk reports an uncorrectable sector its bad until new information is written back to it.
Transparent remapping can only be done if the disk can read the block at least one more time and got the block will go bad as error correction was at its limits.
Was a block not accessed tooo long and decayed too long so that error correction cant repair the failing data, the block will fail even there are spare sectors to remap left.
On a next WRITE to the defective block that cant be corrected (Thats actually what URE is defined) the block will be "repaired" by remapping, but that too late for the RAID
one defective block whilst a rebuild on a replaced disk in raid 5 will give a double error and break the RAID.
3 see too, there may be unhalndled UREs if disks are old and some data is rarely accessed.
4. correct but looking at my own failure statistics i wont bet on it. Recently we had a few deaths of some WD reds and some WE enterprise, all still WITHIN the warranty, they had unhandled UREs on archive HDDs with data written once and rarely read, some files never again after writing.
A reformat "repaired" the disks in the fashion that the defective blocks were remapped to spare ones. one disk was in the hundreds of decective blocks.
5. correct.
Furthermore theres a chance you hace 2 idsks of the same faulty batch in your RAID and that the disk will break soon after resync begun. The resync on a $TB+ HDD can take quite a long in days range and so the additional continuosl stress may crash the 2nd faulty disk too.
So Im still thinking RIAD5 shouldnt be considered out of redundancy reasons, its good for assembling LARGE volumes of smaller disks, with a chance of redundancy if one disk fail.
ASKER
Sounds like this is the only way.
ASKER
I'm looking specifically for a way to be able to move the HDDs into a new box, set up the RAID structure to mirror the old configuration and be able to access everything as it was.