How to upgrade to larger hard drives on PE1800 w CERC SATA 1.5/6?

Mr Push,

If I understand you, you are trying to image a drive and then transfer that drive to the server and then mirror it?

The issue with doing this, and why the system is having issues, is that when you drop an image to the drive you are also copying the System State files and MBR from a workstation. Then trying to boot to it with completely different hardware.

The issue with the controller itself is it doesn't see array configuration data on the drives.

The most stable thing for you to do is to backup whatever data you need to a backup device and then create the arrays (with the larger drives) as you need and then load the Windows Server 2003 OS. This is the driver file you will need to load drivers on the controller -

www.dell.com/.../DriverDetails

During install you can configure your partitions and then after OS is installed you can restore the data.

Flash,

Thanks for the tip, but I have log files and such that I don't want on raid 5 on this boot array for performance reasons.  

Thanks,

MP

Also, there is another simpler/built-in way to add additional space to your server ... your controller has 6 SATA ports, and you can reconfigure your RAID array, making it bigger, but adding disks to it.  For example, if you have a RAID 1, you can reconfigure that on the fly to a 3 (or more) disk RAID 5; you can reconfigure a 3-disk RAID 5 to a 4, 5, or 6-disk RAID 5, etc., adding space to your original array.

Hi Flash,

"CERC SATA 1.5/6CH can convert a concatenated disk to a RAID 1"  

I must be on mars then I guess.  I have other PE1800's with single concatenated disks added.  In Open Manager, it will not let me add them to any other arrays.  These concats were not part of of a broken array.

How a RAID system will not let the user decide which way to mirror drive is just crazy, my old netware boxes at least let me choose which direction....just think of how many people probably have lost data this way?

 "As Chris said, the CERC writes metadata to the drives, including mapping out the space for use for the RAID array and array configuration information.  Without this, the CERC will not recognize the information on the drive and will treat it as an empty drive."

Flash, I find this to be not be true for the following reason.  I have taken one half of a RAID1 out of another PE1800 (same exact hardware) but with a different size and make hard drive, put in another PE1800 CERC and IT BOOTS RIGHT UP!  Works fine!  Other than a CERC bios "RAID 1 Degraded" error, its a peach!  With different size and make drives, the "array data" has to somehow be updated for it to work, right?

The re-install is not really an option for me.  This is an IIS server and I can't possibly go through all that reconfiguration to get things where they need to be.  I just want to image the drives like so many products will do, but not on this PE?

I read last week of folks that did an image swap in a PE1800 and it worked fine.  I'm trying to find that URL.  They stated:  

Put new drive in "another system"  Add partitions. (some imaging software requires a partition to copy images to)

Copy images to new drive.  

Swap out old for new

Reconfigure RAID1 with 2 new drives

Thanks,

MP

The CERC SATA 1.5/6CH can convert a concatenated disk to a RAID 1, but it is possible it cannot be done in the CTRL-A utility - you may need to do it in OMSA from the OS (and keep in mind that if you broke a RAID 1 to a concatenated disk, you CANNOT go back to RAID 1 - you would need to configure them fresh):

<ADMIN NOTE: Broken link has been removed from this post by Dell>

PERC/CERC controllers don't have a primary and secondary drive for mirroring the array - they are treated as equals.  The controller picks the drive with the most recent/complete metadata and uses that one.  All configuration information must be removed/cleared for this to work as you intended. 

As Chris said, the CERC writes metadata to the drives, including mapping out the space for use for the RAID array and array configuration information.  Without this, the CERC will not recognize the information on the drive and will treat it as an empty drive.

Do as Chris suggests.  You should be able to just as easily install/restore to an existing RAID 1 as to a concatenated disk and then reconfigure to RAID 1.

Chris,  

Thanks for your help.

Are you telling me that I have to re-install the OS to upgrade to new drives?  

I am finding that hard to believe.   If this is the case, then Acronis etc would not work to image boot drives on these servers.  The images I make are EXACT duplictes of the existing drives.  From what  I understand the only problem that can arise is that  the boot.ini file can get messed up in the process.

The imaged drive should have an exact copy of the array confguration files, less the "new drive".

For example, I have taken one drive out of a RAID 1 boot drive from another 1800 server, put in on this cerc, and it boots that other server on this server with no problems (other than its not the right setup, different server roles etc).  Different make and size HD, but they are both PE 1800's.  Only HD size and make are different, boots right up!

Where is the array data stored?  Does the accept / reject in the raid bios make that different maybe and changes the array data?  How can it work from an entirely different server which should have different array data then?

Also, last week I did find some folks that have done this with success on PE1800's.  Setup the drives partitons on another system, copy images to them (that should include exact array data), pop them in the existing raid slots, rebuild RAID 1 and all worked fine.

I'm confused as to why this should not work.  Partitioning the drive in a windows XP system could cause the boot.ini to be different, cut I still should be able to see the dirves.

Also, I can creating the partitons from the same server by putting the new drive on the onboard sata.  I can see it then and add partitions and then image it.  It should have he EXACT same array data and work like the drive does out of the other server then, right?

I get lost in a paradym.  How can windows not see drives in the CERC until they are in a volume, when you need to first at least partiton them and make them bootable from outside the CERC????  

I must be missing one littel thing, like marking the drive as ACTIVE or BOOTABLE or something.  I booted from a bootable cd, and it can't see the drive when on the CERC.  

How can it be then that the Windows OS install CD would see them to allow them to be partitioned and marked as active or bootable?

I'm getting dizzy.

Thanks,

MP

"I must be on mars then I guess.  I have other PE1800's with single concatenated disks added.  In Open Manager, it will not let me add them to any other arrays.  These concats were not part of of a broken array."

It may be supported by a minimum firmware level, but it is documented in OMSA as far back as v5.1.

"How a RAID system will not let the user decide which way to mirror drive is just crazy, my old netware boxes at least let me choose which direction....just think of how many people probably have lost data this way?"

Most Adaptec (old onboard PERC 2/3, CERC SATA controllers) and LSI (all other PERC's) treat mirrors the same way.  The low-end SAS controllers do have a primary/secondary, and it can be a nightmare.  I doubt many people go about rebuilds an migrations this way, so I suspect the number of people who have experienced data loss is very low.

"Flash, I find this to be not be true for the following reason.  I have taken one half of a RAID1 out of another PE1800 (same exact hardware) but with a different size and make hard drive, put in another PE1800 CERC and IT BOOTS RIGHT UP!  Works fine!  Other than a CERC bios "RAID 1 Degraded" error, its a peach!"

This works because the controller can see, recognize, and use/import the RAID metadata and settings from a Virtual Disk created on the same controller.  RAID settings are stored on the controller AND on the disks, so if ever they do not match, you must choose what you want to do with the configuration on the disk; on the CERC, you must ACCEPT the changes detected to use the config on the disk.  With the CERC, because it is a very low-end card, you can even take a disk from a RAID 1, attach it to a non CERC controller and "see" the raw data on it (there is nothing special about how the data is written to the drives), but the reverse is not true ... the CERC cannot use the drive if it does not have CERC metadata on it.  Likewise, PERC 5 arrays can be moved to other PERC 5 and PERC 6 controllers and function completely normally.

"With different size and make drives, the "array data" has to somehow be updated for it to work, right?"

I believe that the CERC SATA controller is the only one in Dell's assortment that CAN resize a virtual disk to encompass the entire size of the disk after replacing the smaller ones with bigger ones (other PERC controllers and many other controller makes cannot do this automatically or manually). 

What Chris suggested should work ... when you restore your data - I've never used Acronis, but - you should be able to restore your data to a live OS, updating and overwriting existing files, settings, and configurations with the backed up versions.

Another option would be to put the two larger drives on the controller, configure them in a RAID 1, then do a block-level copy from VD0 to VD1 (must be block-level copy of the entire disk or metadata will not be copied).

Good luck.

Another thing that might work (and how most people attempt to do this, but on other controllers it won't work like they expect), is to replace a smaller drive with the larger drive, then rebuild.  Then replace the other smaller drive with the larger drive, then rebuild, so you have both large drives with live RAID data.  IF my understanding of the CERC is correct (going off of memory, as I've had only limited first-hand experience with the CERC SATA), it will resize (or allow you to resize) the array to the new size of the disks.  Maybe someone can confirm this, but I was under the impression that this card was the only one that could safely do it.

"Where is this metadata stored?"

Exactly where the metadata is stored, I don't know ... I just know that only copying a partition or a file-level copy does not copy the part of the disk where this information is stored.  You must copy not just the partitions, but the entire disk, at the block level.

"If the above is all true, and lets say my image software is messing up the meta volume data,  then after image is done with the drive on the onboard sata (you said I could see raw data w this CERC), why could I not just copy the meta data back on the new drive?"

1) You and I don't know where the metadata resides (maybe someone does - and i may just be in the first few sectors of the disk), and 2) the CERC may not accept the metadata in any place but where it is programmed to put it, meaning you would have to leave enough space at the beginning of the disk for this metadata to be written.

"you said I could see raw data w this CERC"

To clarify what I meant to say:  You can boot a CERC drive on the onboard SATA ports and see the raw data, but you cannot do that in reverse (boot a drive on the CERC that was set up on the onbaord SATA ports).

"And I thought if you did that it rendered the extra drive space on the larger drive unusable?"

True that doing a disk copy will keep your partitions the same size, so you would then need to resize them manually (as many backup softwares can restore partition data to larger partitions), but the disk space at least should be available as Unpartitioned Space.

One way you might be able to do this is to attach configure your larger disks on the CERC, then boot to WinPE with the RAID drivers to format and partition the space, then restore your partitions from backup.  That makes sure that the metadata is intact when the partitions are formatted, which is, I believe, the source of the problem here.

Guys,

I have proven that "Array Data" from another PE1800 with different SIZE and Make Hard drives will work on a PE1800 already configured with RAID1 array by simple "swapping" of drives.  Only error is "RAID 1 degraded".

I put one of my NEW drives on the onboard sata of the same server, add partitions to it, (Dell utility, C drive, D drive)make sure they are or correct TYPE (fat, primary ntfs, primary ntfs), and the 2nd partiton is marked BOOTABLE.

I then image the existing BOOT drive to this NEW drive, remove 2 existing, add two new, and re-create the RAID1 array, it should work.

The only question is my imaging software somehow messing with or missing the array data.  Where is this data stored?

Thanks,

MP

Flash,

Good info here thanks.

If my image software makes a exact copy of the meta data, then why would it not be seen on the new imaged drive?

(maybe caseu the drive was not marked active or bootable?)

If the above is all true, and lets say my image software is messing up the meta volume data,  then after image is done with the drive on the onboard sata (you said I could see raw data w this CERC), why could I not just copy the meta data back on the new drive?

Where is this metadata stored?

How does one do a block level copy of a CERC virtual disk?

And I thought if you did that it rendered the extra drive space on the larger drive unusable?

Thanks,

MP

Flash, That is a good idea, did not think of that.  I thought I had read that the volume might be limited to the original smaller size disk howerver.  I guess I could try it.  As long as I have at least one of the originals, I should be fine so as to not lose mey data.   Huh, I could make backup images of the drives, but they likely would not be recognized by the cerc anyway!  Back to source of my problem! Now the CERC may not show the increased size, but could I not go into Drive manager in Windows and grow it there?  I have gparted as well that can grow partitons.  I did it successfully on one of my other PE's, but it was on the existing drive, not new drives. Thanks, MP

The problem that most people run into in doing this is say they replace two 250GB drives with 500GB drives ... after rebuilding each one, their VD (RAID 1) is still 250GB, and because of restrictions in the hardware/logic of the controller, the only thing they can do with that extra 250GB of space is create a new VD across those disks (called "slicing").  This appears to Windows as a separate "disk" in Disk Management, and as such cannot be used to extend existing partitions, and there is no software that will extend VD's.

If I remember right, this controller is the only one that can extend the size of the VD after rebuilding the drives in this manner - by design.  This controller is different from every other controller that Dell has ever used (for example, it can reconfigure to and from a RAID 10 (nested array), where no other controller, Adaptec or LSI, can reconfigure to or from a nested array).  AFTER the VD is extended, THEN  you can use a partitioning utility (Disk Management should be fine) to extend your data partition.

If this isn't the case, and you choose to try it without confirmation, then I apologize for even bringing it up :)

"One way you might be able to do this is to attach configure your larger disks on the CERC, then boot to WinPE with the RAID drivers to format and partition the space, then restore your partitions from backup.  That makes sure that the metadata is intact when the partitions are formatted, which is, I believe, the source of the problem here."

Flash,

I have an Ultimate boot disk, not sure that would work or not.  What you are saying is that this would enable me to see the drives to do the format and partition adding CERC array data, but when I copy my images back over the these partitions, would it not just wipe out the array data again?

Maybe you are talking about a "FILE BACKUP" here and not an IMAGE backup?

Thanks,

MP

If you are only restoring a partition, it will not wipe out the array data.

Keep in mind that Windows cannot talk directly to the drives; the CERC manages the individual drives and creates a logical disk - a virtual disk - that Windows can use:

When you configure RAID, the blue RAID Array /  Logical Drive layer is created, reserving space for metadata and array management; this space is not accessible by Windows.  Windows only has access to those parts of the disk that the RAID array has been configured to make available (the purple).  So, by creating/configuring RAID on the CERC, you ensure the metadata is written to the drives, making a logical disk ready to be presented to Windows.  By booting to a WinPE disk, you can then format and partition the disk as needed - the metadata is protected against access by Windows.  At this point, you would be ready to restore partition-level backups (you said you were trying to restore C:?).

I don't know about Ultimate Boot Disk, but I suspect it will not have the RAID drivers in order to see and work with drives attached to the CERC, which is why I suggested WinPE with the RAID drivers added to it ... so it can see the logical disk made available to the OS by the controller, then partition and format that disk.

If you only take a backup - even an image backup - of a just a partition (I realize this is much faster than imaging the entire drive), then it will not copy that important metadata that is inaccessible/invisible to the OS, which is why you need to partition it first.  Like I said, I'm not familiar with Acronis, but the only way to get a block-level backup is pobably to boot to the backup software, and probably provide the RAID drivers so the software can see the array(s) on the controller.

Have you backed up the entire disk or individual partitions (probably for time/space constraints)?  How does Acronis work ... what are the steps required to make a backup?