HPE Community read-only access December 15, 2018
This is a maintenance upgrade. You will be able to read articles and posts, but not post or reply.
Dec 15, 4:00 am to 10:00 am UTC
Dec 14, 10:00 pm CST to Dec 15, 4:00 am CST
Dec 14, 8:00 pm PST to Dec 15, 2:00 am PST
ProLiant Servers (ML,DL,SL)
Showing results for 
Search instead for 
Did you mean: 

hp proliant 380 g4 raid

Occasional Visitor

hp proliant 380 g4 raid



i need some help, i have a HP Proliant DL380 G4 that has aparently failed yesterday


i have tried to recover by reseating the riser cage and stripping out some extra ram and swapping the psu's and i have been unable to load even to the POST.


HP have quoted a repair cost of $3.5k to repair so obviously it is easier to purchase new hardware, my issue is that i have data that i need to recover off this server and as it does not start it is impossible to retreive off that but i have another DL308 G4 here that is being used as another server for another function.


i need to know 2 things, can anyone suggest a way to extract the data that is on the drives in the failed server, if i was to swap the drives into the server that works would that work so that i could retreive the data off the drives, or would it wipe the drives from the other server and then wipe its own drives when i replace them into the bays?


any help would be greatly appreciated as soon as posible as the client is running on temp hardare and is wanting to get their data back as soon as possible.

Honored Contributor

Re: hp proliant 380 g4 raid

If you move the disks as a complete set, the new server will recognize them as an intact RAID set and won't wipe them.


So: power down the spare DL380 G4, remove its existing disks (making sure that you know which disk belongs to which slot, for the sake of completeness).


Then verify that the internal cabling of the spare server is configured the same as the failed server (I think the internal bays of the DL380 G4 could be configured as either one or two SCSI buses). If the configuration is different, record the existing configuration and take any required cables/terminators from the failed server if necessary.

(The RAID controller should accept the disks also in a different bus configuration, but doing it this way should ensure we can get the same I/O performance levels from the new server as from the old.)


Then move the disks from the failed server to the spare server, while it's powered down.

Then power up and hope that whatever is wrong with the failed server has not caused secondary damage to the disks too.

Occasional Visitor

Re: hp proliant 380 g4 raid

thankyou for your assistance there.


i just want to break it down


so i need to open the cover of the server and check and see if all the raid cables are connected to the same drive bays?


then while the server is shut down take out my drives and place them in the same bays on the working server


and then fire up the working server and all being well i should be able to view the data.


failing drive failure and if the cables are connected to the wrong spots is there any other reason that there coould be data loss using this method.


from what i can see they look identical, adn they are the same generation so we should be right in trying to recover the data?


i just want to make doubly sure as i cannot loose the data that is on these drives. there is alot of information that the client has kept on a non backed up server.


is there any support numbers for hp within australia for someone that i can talk to just to ensure piece of mind for this process?

Honored Contributor

Re: hp proliant 380 g4 raid

> so i need to open the cover of the server and check and see if all the raid cables are connected to the same drive bays?


There are no cables to individual drive bays. Instead, there is a drive backplane which can be configured in a number of ways. There are two cables connected to the drive backplane.


You should read the Maintenance and Service Guide for DL380 G4.

Look at the "Cabling" chapter, starting at page 54.


If your server has 2.5" SAS disks, then there is apparently only one possible configuration and you're done.

But if it has 3.5" SCSI disks, there is a total of five possible configurations.


The factory default configuration is "embedded simplex": there is one short ribbon cable from the system board to the drive backplane, and another that connects the two sections of the drive backplane together.


The second configuration is "embedded duplex": one end of the 2nd short cable is moved to a connector on the system board, and a small SCSI terminator board is installed to the free connector. This splits the drive backplane into two sections, allowing the disks to be driven by two independent SCSI buses. This improves performance with the internal disks, but the cost is that the external VHDCI SCSI connector cannot be used in this configuration.


The three other configurations are "PCI simplex", "PCI duplex", and "mixed duplex": these apply only if you have an optional add-on SmartArray controller installed. If the failed system has such an add-on controller but the replacement system hasn't, you might have to move the add-on controller from the failed system to the replacement system (hope it has not been damaged in the failure!). If the replacement system has an add-on controller but the failed one hasn't, you'll need to identify the controller model and make sure it's backwards-compatible with the integrated controller (I think most SmartArray controllers of similar ages are compatible to facilitate upgrades), and possibly take some OS recovery steps to replace the disk controller driver with an appropriate version. Or just remove the add-on controller to make the configuration of the replacement system match the failed system to eliminate hardware differences.


Having the cable configuration wrong should not be a data loss issue, but it might be a performance issue (if the failed system used a higher-performance configuration than the replacement) or a driver compatibility issue: replacing the SCSI controller driver that controls the system disk can be a rather complex procedure in some OSs, so you might want to avoid it if time is an issue.


> there is alot of information that the client has kept on a non backed up server.


<deep sigh>


I hope you're going to present these facts to your client with as much emphasis as possible:

"RAID alone is NOT a data backup solution. RAID only removes the need to have a service break when (not "if"!) a physical disk fails. Disk failure is the most common type of hardware failure in servers, but by no means the only one. A backup allows you to recover from more severe types of hardware failures, *and* it also protects you from human errors, like an accidental deletion of a critical file."


> is there any support numbers for hp within australia for someone that i can talk to just to ensure piece of mind for this process?


I'm neither a HP employee nor in Australia: I'm just a sysadmin trying to help a colleague.


But this page would seem to contain all the support phone numbers for Australia:



If you have a support agreement, you'll want the last item in the first section: "HP Carepack and Contract Support". If you don't have one for this server, you'll want the one before it: "Support for all HP Products
except those listed separately above".