ProLiant Servers (ML,DL,SL)
Showing results for 
Search instead for 
Did you mean: 

Proliant ML350 G5 Raid move.

Occasional Visitor

Proliant ML350 G5 Raid move.

My company has a very important server installed in an ML350 G5 box with a Raid5 configuration.

The problem is this box has never worked properly (unstable), and has started suffering from regular reboots due to memory errors.

I've already replaced a number of components and am now fairly certain that the problem comes from a faulty memory controller on the main board.


Unfortunately, the reboots happen mostly when the server is being backed up. Which means that the backups are sporadic at best.


I cant virtualize the server, or properly migrate the data because the server always restarts during the file transfers.


Now, I have another server exactly like it right next to it, which is working just fine. Same model, they were porchased at the same time.


As a last resort solution, I am now thinking of virtualizing the working server, and moving the drives from the defective machine to the working hardware.


What are the chances that the Raid controller on the "new" hardware will not recognize the arrays as they were configured? And what are the chances that this could cause data/raid corruption and loss?


Is there anything specific I need to do prior to moving the drives?



Regular Advisor

Re: Proliant ML350 G5 Raid move.

Make sure you have backed up your data before attempting any move.


The raid should pick up fine with a straight disk move.


Re: Proliant ML350 G5 Raid move.

I know this is old, but I do feel it's worthy of posting. Several years ago now I had a server doing random reboots and it seemed like disk intensive tasks like defragging or backups it would reboot the most. I had everyone involved in solving this from the defragging vendor and even MICROSOFT but the problem continued. Come to find out, the source of the 6+ month problem ended up being a defective power cord for ONE of the two server power supplies! Kid you not, this was the source of these random reboots that appeared to happen the most during heavy disk IO.

The defragging vendor (Raxco) really put a lot into this, and I feel bad for them now, but they assumed responsibility for this and was willing to do what t took to resolve it, including a free upgrade to the newest version, but we did not go that way since it was resolved and not their problem, but major kudos to them for their support in this crisis event. their support set the bar high for software providers...

We are talking ML370G2 that is still in production today, but I am here to look at upgrade options. :-)