DELL PERC 6i Raid 10 import raid config

No, it simply tells the controller to use the config stored on the drives.

Just to clarify.

After I import the raid config from the VD1 HDD to the server, can I read the preserved data inside the VD1 data partition?

Yes.  It will be exactly like plugging in a single disk on a desktop/laptop.

thanks theflash1932. Did you try on raid 10? I also have tried on raid 1 and confirm it works.

I've done this many times with many different controllers, although not on Linux machines ... I don't known what might cause this in the OS - it has never not worked for me, although I've heard others say they have had problems (I don't remember any details).

Thanks theflash1932.

I also think like that. Did you try that before?

I upgraded one server from Centos 5.4 to Centos 6.2 last week and did the same procedure. Some how the partition was gone on the VD1 HDD after I import the raid config, and all data on the VD1 HDD was gone. The partition is ext3 format.

Would it possible the Raid card issue ?

I'm not sure if I've done it on a RAID 10 or not, but probably.  However, the RAID level should make no difference in the process or success rate.

Macushk...

Separate arrays on LSI based controllers are fiercely independent of each other. Should the first failed, the other is not going to be affected unless one makes a mistake and reconfigures the arrays, and your method has it's possibilities... you should concentrate on protecting the OS array, not the data array. The biggest danger during an upgrade is the OS array gets scrambled, needs to be reinstalled and file/directory permissions need to be reinstituted on the data array, personally I have had this happen a number of times but I have never had data loss on a second array caused by the loss of another array (excluding a controller failure); again with little experience, a user can do damage to a second array by messing around with configuration of a raid adapter.

You need to concentrate your effort in protecting the OS array in case an upgrade goes bad. On an upgrade of the OS, the safest procedure is to have a cold spare on hand or better still a hot spare, pull one of the raid 1 members, which becomes an emergency restore disk. Either let the hot spare rebuilds automatically or you add the cold spare, let that rebuild, then do the OS upgrade. Should the OS upgrade fail, you could always reinstate the "emergency restore disk", and your back to your original state before the upgrade. Obviously a full backup should be taken before any proceed such as this, but in 21 years of using this method I never had a situation where it failed to get me back to the original state if an issue occurred. 

The procedure to restore to the original state is relative simple/safe. If the upgrade goes south, you pull both OS raid member disks, insert the "emergency restore disk", boot to verify in goes into the OS, then you replace one of the pulled disks back into the OS array slots, which with the newer controllers, will rebuild automatically. During an upgrade, which might cause an issue. 95% of the time I do a simpler procedure during off hours. I just unlatch (1) of the drives, let the OS array become degraded, do the upgrade, reboot, check that everything is OK, then push the drive back into the slot once I am sure the upgrade has caused no issues. If you use the longer method, you could restore to the original state days/weeks later.

pcmeiners,

Thanks for you reply.

I have already set of HDDs to protect the raid 1 OS disk, so I can roll-back immediately if anything goes wrong after the upgrade.

However, this time the data partition is lost unfortunately, so I would like to figure out any possibility the raid 10 disk array import doesn't work as I expected.

�