Raid drives pulled, now need to fire then up again

Reaction score
13
Location
Richmond Va
I consult with a doctor's office that has their own on staff IT guy. He unfortunately isn't an IT guy by trade, just kind of fell into it and does his best to get by. Most of the time he can handle daily support rather well, and brings me in for specialty or large problems.
He recently retired (by unplugging) their old sbs 2003 server when it wasn't really needed anymore. Now he realizes that they need a little data that is on it. I told him to fire it up and pull the data to a flash drive. However, he's informed me that he pulled the drives out of the tower. I'm not sure why, but he did say that he didn't put them into another system or anything, just sat them on a desk.
The problem is that he doesn't know which drive is which, nor is he even sure what the raid array configuration was. I think it was a three drive raid 5, but I'd only worked briefly on it a few months back, so I'm not sure.
If it was just a three drive system, does it matter which sata port they are plugged back into? As long as all of them are plugged back into the raid board/mother board where they were before, will the raid array fire back up? Are raid arrays sensitive to needing what was drive 0 back in drive 0's spot?
Thanks, Kevin
 
Hey Kevin,

From what I have worked with, the RAID controller is usually indifferent as to where the drive is placed physically. The RAID descriptors identify which drive is which. At the very worst it just won't work and will prompt a RAID error at boot time. Shouldn't cause any corruption or data loss.
 
What type of RAID controller? If I remember correctly if it's a real RAID card, like a PERC, it does matter which port it is plugged into. But, based on the description, it sounds like one of those software based controllers, like Intel. Maybe even a pure software solution since you can do that within SBS. In that case it may not matter depending on the type of RAID configuration. As Aaron mentioned if it's not correct you will get a RAID error so you can just shut it down and swap around. Three drives is most likely RAID 5.

If the information is critical I'd image the drives before doing anything. And if you are doing that you can recreate the array with something like R-Tools. If they do not need the OS to boot and are just looking for some files then you could just grab the files from the mounted, reconstructed array.
 
Thanks Aaron and Mark, this pretty much confirms what i thought. But I've never had a situation like this, so i just wanted reassurance.
I'm not sure if raid 5 as i haven't seen it yet. I'm heading there tomorrow to take a look.

Aaron, i sent you an email yesterday, if you didn't get it, please let me know.
 
Kevin,

You got thrown in Spam.. Bayes filter stinks.. I gotta turn it off. I'm shooting you an email..

Content analysis details: (6.4 points, 5.0 required)

pts rule name description
---- ---------------------- --------------------------------------------------
2.7 DNS_FROM_AHBL_RHSBL RBL: Envelope sender listed in dnsbl.ahbl.org
2.1 HTML_IMAGE_ONLY_12 BODY: HTML: images with 800-1200 bytes of words
0.0 HTML_MESSAGE BODY: HTML included in message
0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60%
[score: 0.4962]
0.8 RDNS_NONE Delivered to internal network by a host with no rDNS
0.0 T_REMOTE_IMAGE Message contains an external image
 
Last edited:
By the time i got there the it guy had already been swapping does apps trying to make it work, even though i told him not to touch it.
It is two arrays, a raid 1 and raid five. We were able to figure out the order, but drive 4, part of the raid 5 was screwing up and needed to be reconstructed. So we did that and then tried to boot. It failed and wanted a chkdsk, so we started that and let it cooking.
 
By the time i got there the it guy had already been swapping does apps trying to make it work, even though i told him not to touch it.
It is two arrays, a raid 1 and raid five. We were able to figure out the order, but drive 4, part of the raid 5 was screwing up and needed to be reconstructed. So we did that and then tried to boot. It failed and wanted a chkdsk, so we started that and let it cooking.
If the process fails, the damage potentially caused cannot be reversed. Hopefully that won't be the case. If so, you would probably want to send to a data recovery pro for best chance of recovering the data without risking making it worse.
 
Well, all I can say is it's good that you were not the one that started fiddling around with it to begin with. Based on your description it sound like chances of data recovery are not going to be good. Especially if it is some kind of monolithic database.
 
I'm not sure what kind of data it is, but likely a database of old medical records. Apparently all scripts, which is the company behind the original server. migration and who manages the current server/database was supposed to have migrated this missing data, but didn't. So there could be a big problem in their end...?
I did find out that they are backing up with backup exec to tape. We do not have a recovery boot cd to easily recover the entire server, but if this chkdsk fails then we're going to work that angle. I've never had to do a full restore from backuo exec, so i may be asking for guidance soon.
 
I'm not sure what kind of data it is, but likely a database of old medical records. Apparently all scripts, which is the company behind the original server. migration and who manages the current server/database was supposed to have migrated this missing data, but didn't. So there could be a big problem in their end...?
I did find out that they are backing up with backup exec to tape. We do not have a recovery boot cd to easily recover the entire server, but if this chkdsk fails then we're going to work that angle. I've never had to do a full restore from backuo exec, so i may be asking for guidance soon.

Set the original drives aside before you make it worse...or hope that everyone's insurance is up to date.
 
Back
Top