Will dropping/recreating the RAID endanger the data? (edit: RAID Recovered)

T

TheRealDarkphoX

n00b
Joined
Mar 2, 2016
Messages
29
Hey folks,

I'm working on recovering files from a lost RAID 10 partition, and am trying to do things slowly and deliberately so I don't make an unrecoverable 'oopsie.'

Background: This was a software RAID 10 built with 4x 3TB drives using IRST on an ICH10R (Intel X58) controller. I don’t know how, but when I installed a new video card in our home server/HTPC, the BIOS got reset and I lost the RAID configuration. It was file storage only, no OS. I disconnected the RAID drives, and reinstalled windows on my C: drive (I'd been wanting to do a clean install anyway, and at this point in time thought it was a windows problem. I hadn't realized the root issue yet, that the bios reset had reverted my drive from RAID to AHCI).

Dumb Question Up Front: Is there any long term danger posed to the old data by repeatedly dropping the member disks and recreating the raid via CTRL+I?

More info: I've since set the bios drive mode back to RAID and recreated the raid via CTRL+I with the same settings it originally had. I have not written to the drive, initialized it, or formatted it. Windows shows it as “unallocated” with no drive letter in disk manager. I'm using Testdisk, and have some early results finding the old partition. However, feedback from the Testdisk developer indicates I may have accidentally reconnected the disks in the wrong order, or I may have used the wrong settings when I recreated the RAID.

I'm planning to try swapping disk order first, but need to drop the member disks and recreate the raid again with the new drive order. I want to make sure I have the right understanding before beginning, though. Is there an increased risk to my data by repeatedly dropping disks/recreating the raid, or is it just the metadata at the start of the disk that gets affected? I know this is probably a very basic-level question, but I'm learning as I go and want to make sure I understand the risks before I commit.

Thanks!

Full story with screen caps and stuff: https://forum.cgsecurity.org/phpBB3/viewtopic.php?f=5&t=8095
 
Based on your post, and your configuration.. Your data is most likely toast at this point. If windows shows it unallocated, you're already in a bad spot. You can try playing around with reconnecting the drives in a different order but I don't think that should help much. Most raid cards, and raid softwares these days are smart enough to put the volume back together based on header information on the volume regardless of the order things were plugged into. If it didn't just pop online, then there is a good chance you are SOL.
 
Thanks for the insight. Believe me, I'm aware of the isht sandwhich I've given myself and am not trying to be overly-optimistic.

The way I screwed things up, I formatted Windows before it had a chance to see the RAID again, and it was already gone in the bios. Windows see's the re-created raid as a drive, but it's unallocated because I didn't let Win initialize it (preserving original data). Again, Testdisk does see the partition, but I'm getting some strange errors that may indicate something is out of order.

I just want to be aware of the potential impacts I may be making. If dropping member disks and recreating the raid again could damage bulk data, then I'll hold off and see about sending it in for professional work. But, if there's minimal risk...for example, if recreating the RAID only affects the first X blocks on each disk, then I'll keep trying things that are within my own reach.
 
If you were smart engough, then just re-create the RAID and restore all your data from backups. If you didn't back up then shame on you.
 
TheRealDarkphoX said:
Thanks for the insight. Believe me, I'm aware of the isht sandwhich I've given myself and am not trying to be overly-optimistic.

The way I screwed things up, I formatted Windows before it had a chance to see the RAID again, and it was already gone in the bios. Windows see's the re-created raid as a drive, but it's unallocated because I didn't let Win initialize it (preserving original data). Again, Testdisk does see the partition, but I'm getting some strange errors that may indicate something is out of order.

I just want to be aware of the potential impacts I may be making. If dropping member disks and recreating the raid again could damage bulk data, then I'll hold off and see about sending it in for professional work. But, if there's minimal risk...for example, if recreating the RAID only affects the first X blocks on each disk, then I'll keep trying things that are within my own reach.
Click to expand...

Dropping member disks and adding them back without any acknowledgment by the raid controller/application is not a good idea, given that fact that what happened should not have written anything to the drive. you should by all means, providing the array was intact beforehand, be able to configure the controller to raid and have it pick up the array, and you should not have to initialize anything. I've done this with both Intel and AMD based raid. does the controller show the array on boot?
 
zpackrat said:
Dropping member disks and adding them back without any acknowledgment by the raid controller/application is not a good idea, given that fact that what happened should not have written anything to the drive. you should by all means, providing the array was intact beforehand, be able to configure the controller to raid and have it pick up the array, and you should not have to initialize anything. I've done this with both Intel and AMD based raid. does the controller show the array on boot?
Click to expand...

Thanks, Zpackrat. The bios issue (reset, clear, whatever happened) caused the controller to lose the array. I rebuilt it using the CTRL+I interface during bootup so I could explore it with testdisk, and am looking at dropping the disks using the same interface.

I'm trying to figure out if doing this (dropping, re-creating in the RAID setup interface) writes configuration data to the drives in the same part of the drive each time, or if it eats data each time it's done.
 
TheRealDarkphoX said:
Thanks, Zpackrat. The bios issue (reset, clear, whatever happened) caused the controller to lose the array. I rebuilt it using the CTRL+I interface during bootup so I could explore it with testdisk, and am looking at dropping the disks using the same interface.

I'm trying to figure out if doing this (dropping, re-creating in the RAID setup interface) writes configuration data to the drives in the same part of the drive each time, or if it eats data each time it's done.
Click to expand...

It's likely the case, when you re-add to an array, the controller/software will want to rebuild the array if the parity data is available, I would assume a raid 10 would be no different as it would assume that data would be available from the good raid 0 set.
 
I've replaced entire arrays one drive at a time in a RAID10 by dropping and adding disks one at a time before - that works ok. It's some risk, but it's doable, and the process in and of itself shouldn't cause any harm. It's just if anything happens while you've got a disk out and it's rebuilding that something could go oops - but that could happen at any time. As far as doing it over and over again - as far as the hardware is concerned it's no different than any other READ/WRITE operation, so no harm there either.

Theoretically, even if you didn't manually drop a disk - you just yanked it from the array, it should still work. After all, that's what a RAID10 is built to do, remain online and recover through a disk fault. I just wouldn't advocate intentionally faulting your array if you don't have to.

In your situation.... you should attempt to get the array running before you do anything else. Once you've determined if you can do that, then you can go about swapping around hardware.
 
Thanks BB. Originally, I was just going to use Testdisk to extract the files I hadn't backed up yet. Which is why I ignored Motley's deuchey response earlier. But, as of this morning I have the ENTIRE ARRAY back!

I went ahead and tried swapping the order of the disks...they were def. in the wrong order. I had 13 top-level folders, and Testdisk was originally only able to show me folder #4. After swapping 2 drives it was able to show me the entire top-level structure with folders 1-13.

Seeing the immediate impact gave me hope, but I still didn't have the exact right drive order. I maximized my talent points in operator error, apparently, and am guessing I accidentally put my top and bottom sets of plugs in backward.

At this point, I ran ReclaiMe's reconstructor tool at the suggestion of a few other folks (http://www.freeraidrecovery.com/). This ID'd the right drive order in about 5 minutes and allowed me to copy the array to a separate disk. Took about 36 hours to complete, but I have everything back like nothing ever happened!
 
You must log in or register to reply here.
Back
Top