Back up all your Microsoft Windows Server – on-premises, in remote locations, in private and hybrid clouds. Your entire Windows Server will be backed up in one easy step with patented, block-level disk imaging. We achieve RTOs (recovery time objectives) as low as 15 seconds.
COURSE of the MONTH
15 days, 14 hours left to enrollBecome a Premium Member and unlock a new, free course in leading technologies each month.
Solved
Replace Hard Drives on Server
Posted on 2011-02-27
I have a Dell PowerEdge SC1420 with Microsoft Windows Server 2003 R2 Standard Edition SP2. It has a hardware controller CERC SATA 1.5/6ch which has two hard drives connected to it with a RAID1 configuration. The hard drives are 160GB drives and I am out of space. I am going to replace both of them with 1TB drives. I need help on two things. I need to copy over the old hard drive information keeping system state, data, etc. in tack and setup the two new hard drives in RAID1 configuration. What is the best way to proceed with this and what is the best software to copy all the information from the original RAID1 drives to the new RAID1 drives.
FYI, this server is a Domain Controller and is just a file / print server. Also the drives are partitioned. C Drive - 25GB D Drive - 125GB. The software will need to expand the partitions on the new drives.
FYI, this server is a Domain Controller and is just a file / print server. Also the drives are partitioned. C Drive - 25GB D Drive - 125GB. The software will need to expand the partitions on the new drives.
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
5
4
2- +5
19 Comments
Active 1 day ago
One method to consider is to replace the second hd with one of the new 1T drives as if the second drive failed an was being replaced. Give the system lots of time to remirror. Once done, remove the first drive, set the second drive as the main RAID1 drive, install the other 1T drive and have it mirror to that one.
When you are done, you'll have both 1T drives installed properly as RAID1, except for the fact that the partitions won't be the sizes you want. I believe that Server 2003 will allow you to move and expand the partitions.
When you are done, you'll have both 1T drives installed properly as RAID1, except for the fact that the partitions won't be the sizes you want. I believe that Server 2003 will allow you to move and expand the partitions.
Personally, I would use Symantec Backup Exec System Recovery Server (BESRS) to image the server, then replace the drives, create the new partitions the size you want them to be and then use BESRS to recover the partitions from image to the new disks.
The alternative would be to swap one of the drives and re-mirror, then once mirrored, swap the other drive and re-mirror. You will then have the server with no down-time, on new 1TB disks and although you don't have a larger C: drive, you will have lots of free space you can use.
Then you can use Paragon Partition Magic Server to re-size the partitions - which is much cheaper than BESRS.
Paragon Software:
http://www.paragon-software.com/business/pm-server/
Symantec Software:
http://www.symantec.com/business/backup-exec-system-recovery-server-edition
The alternative would be to swap one of the drives and re-mirror, then once mirrored, swap the other drive and re-mirror. You will then have the server with no down-time, on new 1TB disks and although you don't have a larger C: drive, you will have lots of free space you can use.
Then you can use Paragon Partition Magic Server to re-size the partitions - which is much cheaper than BESRS.
Paragon Software:
http://www.paragon-software.com/business/pm-server/
Symantec Software:
http://www.symantec.com/business/backup-exec-system-recovery-server-edition
1 option is to use Symantec ghost v15.
Safest way is ,
Boot off ghost CD to make a complete back up to remote drive. ( you probably need CERC SATA driver)
Remove the Mirror Drives and add new drive and setup up the new mirror them.
Boot off ghost CD again to make a complete restore from the remote drive.
Safest way is ,
Boot off ghost CD to make a complete back up to remote drive. ( you probably need CERC SATA driver)
Remove the Mirror Drives and add new drive and setup up the new mirror them.
Boot off ghost CD again to make a complete restore from the remote drive.
If you are looking for cost effective Image software I have been using R-Drive Image 4.7 on my Windows 2003 servers for the past year. I have done a complete restore a few times (mostly for migrations) without a hickup.
Active 7 days ago
First of all make sure you get certified drives from Dell, it is unlikely you'll get 1 TB drives that work properly with this controller.
Then use an imaging like was mentioned above. I prefer either Gparted which is on the PartedMagic LiveCD and opensource to image your current system to another Disk, possibly USB or something elsewhere on the LAN. If the tool doesn't recognize your hardware use another tool like that from paragon which was mentioned above. Then replace the old disks with the new ones, build your array and restore the images. That way you'll still have the old disks intact in case something goes wrong.
http://partedmagic.com/
Then use an imaging like was mentioned above. I prefer either Gparted which is on the PartedMagic LiveCD and opensource to image your current system to another Disk, possibly USB or something elsewhere on the LAN. If the tool doesn't recognize your hardware use another tool like that from paragon which was mentioned above. Then replace the old disks with the new ones, build your array and restore the images. That way you'll still have the old disks intact in case something goes wrong.
http://partedmagic.com/
Active 2 days ago
If you attempt to upgrade the RAID by simulating a failure by yanking the disk and putting in a 1TB drive, then you will not only risk data loss, (how do you know you won't have any new bad blocks on the surviving disk or that the surviving disk you are rebuilding on won't fail? If either happens, the drive you yanked will be marked failed by the controller and so you have to go through work to get it forced in .. and even that disk may have problems.
The answer is to just get some decent imaging software let lets you resize the partition, that works from the booted windows environment. It must support your RAID controller. If you attempt to image physical drives on another computer, then it will fail because the CERCs use metadata. Your imaging software needs to be supported.
Personally I would go with Ghost, and make 100% sure you do the CD version that has CERC drivers. Consider this a wonderful testing opportunity.
The answer is to just get some decent imaging software let lets you resize the partition, that works from the booted windows environment. It must support your RAID controller. If you attempt to image physical drives on another computer, then it will fail because the CERCs use metadata. Your imaging software needs to be supported.
Personally I would go with Ghost, and make 100% sure you do the CD version that has CERC drivers. Consider this a wonderful testing opportunity.
Active today
I have done this operation many times with Paragon Drive Backup 10: http://www.paragon-software.com/business/db-server/
Here is step by step description what you need to do:
1)Download and install DB10 - take backup of entire partitions on your HDD (actually RAID detected as single HDD). If 2003 server is used take system state backup using NTbackup before you take full backup with DB10. Sometimes it is needed for correct sync of server with domain. But I never needed it.
2)Download and create WinPE Recovery CD of the RCD.exe file that comes with Paragon Drive Backup 10 Server
3)Turn off the server and disconnect the smaller drives. Connect 1TB drives - get to RAID utility and reconfigure the RAID with bigger drives.
4)Boot the server from WinPE Recovery CD by Paragon - get to full scale launcher and see if the RAID is detected as single HDD in its interface. If not then use Load Driver for RAID controller. Driver can be loaded from USB flash drive or CD. Normally you need x86(32bit) Windows Vista+ compatible driver. But if the RAID is detected ok - then run restore from previously created backup image.
5)While you are in Restore wizard use "Resize proportionally" option to allocate new space proportionally to partitions. Or you can restore partitions one by one - manually entering new size for each partition. So no resize software is needed.
6)When restore is done - reboot to Windows.
Here is step by step description what you need to do:
1)Download and install DB10 - take backup of entire partitions on your HDD (actually RAID detected as single HDD). If 2003 server is used take system state backup using NTbackup before you take full backup with DB10. Sometimes it is needed for correct sync of server with domain. But I never needed it.
2)Download and create WinPE Recovery CD of the RCD.exe file that comes with Paragon Drive Backup 10 Server
3)Turn off the server and disconnect the smaller drives. Connect 1TB drives - get to RAID utility and reconfigure the RAID with bigger drives.
4)Boot the server from WinPE Recovery CD by Paragon - get to full scale launcher and see if the RAID is detected as single HDD in its interface. If not then use Load Driver for RAID controller. Driver can be loaded from USB flash drive or CD. Normally you need x86(32bit) Windows Vista+ compatible driver. But if the RAID is detected ok - then run restore from previously created backup image.
5)While you are in Restore wizard use "Resize proportionally" option to allocate new space proportionally to partitions. Or you can restore partitions one by one - manually entering new size for each partition. So no resize software is needed.
6)When restore is done - reboot to Windows.
The best way is unfortunately not the quickest. This is the way I do it:
check your service pack level on the server, and ensure you have the install media, drivers and license key.
take an ntbackup (included with server 2003) including system state and your partitions.
verify the backup
destroy the raid config and re-create the array with the newer drives
create your desired partitions and install windows
update to the same service pack as before
restore the C partition
reboot
restore the data partition
reboot
job done
check your service pack level on the server, and ensure you have the install media, drivers and license key.
take an ntbackup (included with server 2003) including system state and your partitions.
verify the backup
destroy the raid config and re-create the array with the newer drives
create your desired partitions and install windows
update to the same service pack as before
restore the C partition
reboot
restore the data partition
reboot
job done
Active 1 day ago
@dlethe:
I am not sure if we disagree or if I was not clear enough. Here is a better description of what I meant (but left out many details):
1) make and confirm that you have a good backup (isn't this always assumed? <G>)
2) shut down the server
3) remove the second RAID 1 drive
4) confirm that the system boots properly (plus a warning message about the drive missing) on 1 drive
5) shut down the server
6) remove the first RAID 1 drive, install the second RAID 1 drive
7) confirm that the system boots properly
We now have confirmed that there are two good drives with live data (no, we haven't scanned the entire drives) and there should also be a backup separate from them
8) remove the second RAID 1 drive, reinstall the first RAID 1 drive, add the 1T drive as the second drive
9) if it doesn't do it automatically, tell the system to use the 1T drive as the second RAID drive
10) boot up, confirm that the system is working, monitor the RAID mirror process
11) when mirroring is done, shut the system down
12) remove the first RAID 1 drive, install the other 1T drive as the first RAID drive
13) if it doesn't do it automatically, tell the system to use the last installed 1T drive as the first RAID drive
14) boot up, confirm that the system is working, monitor the RAID mirror process
15) when done, reboot, then extend the partitions
With better details, do you still have the same concerns?
If I remove the second RAID properly (i.e. with the computer shut down), shouldn't it be a valid copy of the system? I've done it successfully on at least one Intel system.
I will concur that I'm taking some risk about bad blocks existing or appearing during the process.
I am not sure if we disagree or if I was not clear enough. Here is a better description of what I meant (but left out many details):
1) make and confirm that you have a good backup (isn't this always assumed? <G>)
2) shut down the server
3) remove the second RAID 1 drive
4) confirm that the system boots properly (plus a warning message about the drive missing) on 1 drive
5) shut down the server
6) remove the first RAID 1 drive, install the second RAID 1 drive
7) confirm that the system boots properly
We now have confirmed that there are two good drives with live data (no, we haven't scanned the entire drives) and there should also be a backup separate from them
8) remove the second RAID 1 drive, reinstall the first RAID 1 drive, add the 1T drive as the second drive
9) if it doesn't do it automatically, tell the system to use the 1T drive as the second RAID drive
10) boot up, confirm that the system is working, monitor the RAID mirror process
11) when mirroring is done, shut the system down
12) remove the first RAID 1 drive, install the other 1T drive as the first RAID drive
13) if it doesn't do it automatically, tell the system to use the last installed 1T drive as the first RAID drive
14) boot up, confirm that the system is working, monitor the RAID mirror process
15) when done, reboot, then extend the partitions
With better details, do you still have the same concerns?
If I remove the second RAID properly (i.e. with the computer shut down), shouldn't it be a valid copy of the system? I've done it successfully on at least one Intel system.
I will concur that I'm taking some risk about bad blocks existing or appearing during the process.
Active 1 day ago
I had one other thought on this. Suppose you install the 2 1T drives as a second RAID 1 drive, then do software mirroring in Windows from the original RAID drive to the new one, then move the partitions? Would the 1T pair be bootable after the 160G pair were removed? It seems that they ought to be.
Active 2 days ago
No, CompProbSolv - the technique you have has some inherent problems
1) You have no way of knowing at this point if the 2 disks are an exact match (i.e, RAID1 is consistent). If it is not, then you have a 50% chance of placing the wrong data on the system .. and you will NEVER know.
2) What if the surviving (first) disk can't read a block? Murphy's laws and all that...
If this does happen, then let's assume that the mirror is 100% valid & tested. So you now have to boot to the disk you took out. (Ignore for the fact that history can repeat itself).
When you introduce the original disk#2, it will be listed as Dead/Foreign, and will not be part of the RAID set. Remember, the controller thinks it failed. So now you have to tell the controller that the 2nd disk is live, the 1st is "bad". You will get a metadata mismatch. So now you have to go through the process of making sure you recover from the degraded condition correctly, then rebuild & start over.
3) Lets assume you do 1-7 and get lucky (which I admit, the odds favor)....
What will the capacity be on the logical drive? EXACTLY what it was before you started. This will not put free space at the end of the partition. It will leave free/reserved space that only the CERC controller can see.
1) You have no way of knowing at this point if the 2 disks are an exact match (i.e, RAID1 is consistent). If it is not, then you have a 50% chance of placing the wrong data on the system .. and you will NEVER know.
2) What if the surviving (first) disk can't read a block? Murphy's laws and all that...
If this does happen, then let's assume that the mirror is 100% valid & tested. So you now have to boot to the disk you took out. (Ignore for the fact that history can repeat itself).
When you introduce the original disk#2, it will be listed as Dead/Foreign, and will not be part of the RAID set. Remember, the controller thinks it failed. So now you have to tell the controller that the 2nd disk is live, the 1st is "bad". You will get a metadata mismatch. So now you have to go through the process of making sure you recover from the degraded condition correctly, then rebuild & start over.
3) Lets assume you do 1-7 and get lucky (which I admit, the odds favor)....
What will the capacity be on the logical drive? EXACTLY what it was before you started. This will not put free space at the end of the partition. It will leave free/reserved space that only the CERC controller can see.
Active 2 days ago
"I had one other thought on this. Suppose you install the 2 1T drives as a second RAID 1 drive, then do software mirroring in Windows from the original RAID drive to the new one, then move the partitions? Would the 1T pair be bootable after the 160G pair were removed? It seems that they ought to be."
Yes, but the side-effect is that you will have to later deal with
* converting to dynamic & inherent small risk of that, plus then mirroring (easy), and at some point converting from a mirrored to a non-mirrored.
* then you have to do partitioning under windows (but that is easy)
* Now you have to tell the PERC that the other disk is primary boot, or LUN number, which now changes the drive letter, so have to get that all sorted out. Not anything I would want somebody to walk through
... but it could be done.
Still, much easier, safer, and cleaner to backup. Plus, you end up with a backup. You have the highest risk of drive failure within the first few days of deploying new disks. Always good to have a backup..
Yes, but the side-effect is that you will have to later deal with
* converting to dynamic & inherent small risk of that, plus then mirroring (easy), and at some point converting from a mirrored to a non-mirrored.
* then you have to do partitioning under windows (but that is easy)
* Now you have to tell the PERC that the other disk is primary boot, or LUN number, which now changes the drive letter, so have to get that all sorted out. Not anything I would want somebody to walk through
... but it could be done.
Still, much easier, safer, and cleaner to backup. Plus, you end up with a backup. You have the highest risk of drive failure within the first few days of deploying new disks. Always good to have a backup..
Active 1 day ago
@dlethe:
Your #3 is the serious fatal flaw in my first approach. I was confusing extending a partition on a drive (which is possible) to extending a RAID drive (which is either not possible or just that I don't know how to do it).
As far as RAID being consistent, if one shuts the system down properly and then boots to the RAID utility, is the confirmation there that they are consistent not good enough? (the question is moot in this context because of my fatal flaw above, but I'm trying to learn here)
As far as introducing the second drive (as a test) and the live/dead issues, at least with a particular Intel server I've been playing with, this goes without a hitch. Of course, that doesn't really speak to other controllers and how they would behave.
I absolutely agree with the Ghost approach, with the only significant issue being that of cost. I know, we're dealing with servers here and that shouldn't be so much of an issue, but it does tend to be in my (small-sized) customer base.
It's often a difficult decision to weigh cost vs. risk. Beyond that, I can't disagree with your logic and appreciate your insight.
Your #3 is the serious fatal flaw in my first approach. I was confusing extending a partition on a drive (which is possible) to extending a RAID drive (which is either not possible or just that I don't know how to do it).
As far as RAID being consistent, if one shuts the system down properly and then boots to the RAID utility, is the confirmation there that they are consistent not good enough? (the question is moot in this context because of my fatal flaw above, but I'm trying to learn here)
As far as introducing the second drive (as a test) and the live/dead issues, at least with a particular Intel server I've been playing with, this goes without a hitch. Of course, that doesn't really speak to other controllers and how they would behave.
I absolutely agree with the Ghost approach, with the only significant issue being that of cost. I know, we're dealing with servers here and that shouldn't be so much of an issue, but it does tend to be in my (small-sized) customer base.
It's often a difficult decision to weigh cost vs. risk. Beyond that, I can't disagree with your logic and appreciate your insight.
Active 2 days ago
Agreed, should have led with the dealkiller ;)
But #1 & #2 do happen, especially on larger systems, and remember you wouldn't be swapping disks anyway if they were healthy to begin with.
No, absolutely it is not consistent until you run a consistency check. Most people don't even know that this is regular RAID maintenance. You get block mis-matches all the time, more so if you don't have a controller with i'ts own BBU for write cache. Any power loss can create such mis-matches.
Now if all the work gets done at the POST w/o any background I/O, risk is much, much less, but in order to limit risk, you need to do a full parity check/rebuild. But bad blocks can happen any time, and it really is a pain to get back.
(But I'm in the 'biz, so I have to be extra conservative ... Bottom line, however, any time you attempt a config/state change where you only have one copy of the data then you create risk. The moment you separate the RAID1 into 2 disks, you do NOT have 2 copies of the data. You have 1 copy each of 2 sets of data. It is a subtle difference, but nevertheless, you have 2 datasets. If disks never degraded and and it was impossible to have an ECC error or any other kind of error then I would capitulate :)
ECC, another thing .. the disks are desktop/consumer, so considering that you are going to be imaging several TBs worth of data before it is all done, then statistically you have about 1/4 chance of getting an ECC error somewhere.
But #1 & #2 do happen, especially on larger systems, and remember you wouldn't be swapping disks anyway if they were healthy to begin with.
No, absolutely it is not consistent until you run a consistency check. Most people don't even know that this is regular RAID maintenance. You get block mis-matches all the time, more so if you don't have a controller with i'ts own BBU for write cache. Any power loss can create such mis-matches.
Now if all the work gets done at the POST w/o any background I/O, risk is much, much less, but in order to limit risk, you need to do a full parity check/rebuild. But bad blocks can happen any time, and it really is a pain to get back.
(But I'm in the 'biz, so I have to be extra conservative ... Bottom line, however, any time you attempt a config/state change where you only have one copy of the data then you create risk. The moment you separate the RAID1 into 2 disks, you do NOT have 2 copies of the data. You have 1 copy each of 2 sets of data. It is a subtle difference, but nevertheless, you have 2 datasets. If disks never degraded and and it was impossible to have an ECC error or any other kind of error then I would capitulate :)
ECC, another thing .. the disks are desktop/consumer, so considering that you are going to be imaging several TBs worth of data before it is all done, then statistically you have about 1/4 chance of getting an ECC error somewhere.
Featured Post
We value your feedback.
Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Hyper-convergence systems have taken the IT world by storm and have quickly started to change our point of view of how the data center should and could be architected. In this article, I’ll explain the benefits of employing a hyper-converged system …
this article is a guided solution for most of the common server issues in server hardware tasks we are facing in our routine job works.
the topics in the following article covered are,
1) dell hardware raidlevel (Perc)
2) adding HDD
3) how t…
In this video, Percona Director of Solution Engineering Jon Tobin discusses the function and features of Percona Server for MongoDB.
How Percona can help
Percona can help you determine if Percona Server for MongoDB is the right solution for …
In this video, Percona Solutions Engineer Barrett Chambers discusses some of the basic syntax differences between MySQL and MongoDB.
To learn more check out our webinar on MongoDB administration for MySQL DBA: https://www.percona.com/resources/we…
Suggested Courses
Course of the Month15 days, 14 hours left to enroll
743 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.