Need Help to Retag Drives pn Dell PERC 5/i Integrated RAID card

Darlene

The big problem is the drive that went offline/foreign first. The data on that drive is not current with the rest of the array. If the array is showing up as foreign then I would recommend importing the foreign configuration. If you import then the controller will check all of the time stamps and attempt to bring the array back online.

If you don't have a foreign configuration listed anymore then these are the steps for retagging:

1. Create a new array using the same stripe, RAID level, and member disks as before. The caching options and size don't matter.
2. Do NOT intialize the array when you create it. An initialization is a low level format that will wipe the data
3. Before you leave the controller BIOS offline the first drive that went foreign. If you boot up the system with that drive online it will corrupt the array. If you can't remember which drive went offline/foreign first then review the logs. Remember that the drive numbering starts with 0.
4. Boot up the server and check to see if the data is present.
5. If the data is not present then stop and post back here. Do not attempt to recover the data. If anything is written to the drive it will start overwriting the old data and corrupt the old data.

Thanks

Let me know what to do next.

PERC 5/i

I did NOT choose to initialize when I create the array and it gave me a warning as a result.

DSET confirms controller:

I would like to review the controller log before we do anything further. Go to the controller page in OpenManage and in the task list choose to export the controller/TTY log. Post the text file somewhere and give me a link please. You should be able to attach files to your account here on the forums.

Thanks

I could never import the foreign drive because that option was always greyed out. That's what I meant.

Alright I went back and took the drive offline then booted. Windows can see the array but not the data.  Windows just sent two "event notifications": "Controller ID:0 0VD is now Degraded VD0" and "Controller D: 0 Background Initialization failed on VD:0"

Now what?

"Controller D: 0 Background Initialization failed on VD:0"

This tells me that an initialization was started on the array when it was created. When you offlined the drive it stopped the initialization.

Double check the RAID controller that you have. Find out if it is a PERC 5 or a SAS 5. Also, did you choose to initialize the drive when you created the array?

OpenManage? Where is that? I don't see anything on the computer named that and all links online seem to be dead.

OpenManage? Where is that?

If you don't have Openmanage installed then just run another DSET. Inside the DSET logs>RAID Controller is a .txt file. That is the controller log. Upload it to your forum account please.

Thanks

Okay. It takes a while.

For some reason it would not upload to the forum account. So I put the log here instead:

http://www.darlenecypser.com/103013Controllerlog.txt

Everything looks fine in the log provided, but that log only goes back to the last restart.

I think you are going to have to contact a data recovery company to get the data back. I suspect one of a few things happened:

#1 Since the array was brought back online with the first failed drive the array likely corrupted. A background initialization is a consistency check. When the controller runs a consistency check it makes sure everything matches across the array and repairs anything necessary. Since one of the drives had inconsistent data the controller would copy that data to all of the other drives and corrupt the array.

#2 The array may have been corrupted when the controller was replaced.

#3 The last possibility I can think of is that the stripe size or member disks may have been different than what we configured.

Whatever the reason the data is not accessible at this point without data recovery. The positive item of note is that the data can likely be recovered easily. If the data is not backed up and is important enough to pay for retrieval then I would recommend two things:

1. Boot into the controller BIOS and offline all of the drives while you wait for data recovery. You don't want the controller performing any further consistency checks, patrol reads, or anything else on the array. Any further writes to the array will just cause more corruption.
2. Contact a data recovery company like Drivesavers. They will provide instructions on how to proceed.

Thanks

I think #1 is what happened. That's why I was trying to get answers before I did anything.

I wish someone would have given me more precise information earlier. I tried the online chat but they won't do that without a number. I tried calling Dell Support. The first guy didn't seem to know that Dell sold anything but laptops and desktops. He had no idea what a RAID array was. He forwarded me to another guy who also had no idea what a drive array was. I asked if there was another person I could speak to or another number to call. He had no idea. I asked on Twitter who to contact. No response to that query for hours. I posted this thread (Someone or something moved it from one forum to another. I don't know if that delayed its visibility.) and after that I received a response on Twitter and was referred to a different Twitter account and started the conversation with that account. So it took hours to even get a conversation started with the right person.

I am certain the stripe size is correct. I don't know why the number of disks in the array would be different than the number of drives attached to the adapter.

I'm sorry that it took so long to reach the proper support personnel. If you have any old controller logs from previous DSETs I can review them to try to verify the old configuration.

Thanks

I called several local data recovery places and finally dropped it off at Colorado Data Recovery. They said they can look at it overnight and give me a status report and quote tomorrow. They said they have been doing this for 15 years and have some equipment that they say can destripe the array and tell which files may have been corrupted and which not.