Problems migrating root to ssd, RAID array degraded. Solved

[1clue]

Hi,

Got a Gentoo box, had it on a spinning rust device and now I installed an SSD. While I was in there I took out the dust bunnies, replaced a dead fan, removed a few things I don't want anymore and rearranged my SATA cables.

I had problems. Got a nonbootable situation, probably because I got creative with the sata cables. Since I had no idea how it all was in the first place, I got out an antique minimal install CD and messed with it that way.

Somewhere along the road my original / partition (using GPT on everything here) became type 0700 (Microsoft) but when I set the partition type back to 8300 I could mount it again.

I got my data copied to the SSD, but not sure if I have grub done right.

I'm back up, but I'm not good yet. I had a 2-drive raid1 setup, and half of the array is missing. That's the point of this thread. I'm not sure if it's something I did or if it's just because it's yet another WD green drive went to pot on me.

For the record, I have all the data that was on the array backed up, and I no longer have any of the partitions inside the raid volume group mounted. Actually I have most of it deleted so I can be sure what was backed up.

So with one partition left, I'm hoping to reassemble the array and get it all back together, or better yet first find out if it's a drive failure or a mess-up on my part.

Here's what I have:

[eccerr0r]

You probably somehow started the array and it couldn't find its friend for whatever reason, so the "cooperative" one is the one that's fresh. So yes, the "uncooperative" one actually was kicked from the array as "bad".

You can try reattaching the disk by treating as if that disk failed. Should be able to just re-add it and let it sync again, hoping that the "cooperative" disk contains the correct and latest data. Assuming you have the backup fresh and correct, if the disk isn't already failed/removed, do so, and then re-add mdadm --add /dev/md0 /dev/sdc1 it to the array. A resync will happen as it copies the working disk back and you should be good again.

Yes RAID is not backup. Shit like this happens and you never know what state your machine will end up being, but you do see all your data at least... up until you start messing with the disks or the "redundant" disk dies along with the first disk that died.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[1clue]

I'm crystal clear on the idea that raid is not backup.

People don't realize it but the fact of how raid works means that your array is more likely to have a failure of some sort than a single disk is.

And then, they're WD green drives. This was the last pair I bought, or will ever buy if I have any choice.

It's saying mdadm: /dev/sdc1 does not appear to be an md device when I try to add it, looking that up.

Thanks.

[eccerr0r]

The command args may be backwards... /dev/sdc1 isn't your md device, /dev/md0 is ...

hmm... a cheat sheet... heh http://www.ducea.com/2009/03/08/mdadm-cheat-sheet/

[1clue]

Fantastic!

I've got a bunch of bookmarks for mdadm but my eyes blur over before I get to the good parts. This one is really concise and easy.

Recovering right now, thanks a bunch.

[digifuzzy]

It may be academic since you're recovering data...

I couldn't see anything in the snippets you provided that indicate the vendor of the raid member drives.
Can you access the drive details with hdparm?
Does SMARTD say anything about the uncooperative raid member?

Only after verifying drive with SMARTD (and others) would I go all-in on sorting out array/mdadm issues.

Just a suggestion.

[1clue]

Um, yeah about that. It's not really academic and I'm dealing with near-death experiences with this box anyway.

The drives are WD green drives which I now know are junk for my purposes. I bought 10 or 11 of them of different sizes from 750g to 3t in 3 groups in a span of about a week, not nearly long enough ago. I have 4 working drives left and this array accounts for 2 of them.

I raided the 2 3-tb drives because I was getting failures already before I even got around to installing the big ones. I believe I have done the self-park BS but it wasn't with the WD tool, it was with the linux tool. Don't remember exactly how I did it, it was awhile back.

It occurs to me now that I could still pull these working drives, install some appropriate non-WD replacements and transfer data. Then I could use the green drives as backup media and since they would only be plugged in during a backup they would not die at the drop of a hat. I think that's what's going to happen, but I need money first. Which means a paycheck.

I'm really torn on this box. It's an i7 920, first-gen i7. It's sata2 and usb2 and pciev2, so it's slow by modern standards, but it's a box. Normally I'd have my drives start to go right about the time I'm ready to put the box in the trash due to its age. Now I have these green drives all over, they're failing and the other hardware is still useful but borderline not worth upgrading. I've never been able to really trust this box because of the greenness of it all, when I set it up it was a workstation so I thought green didn't matter. It's not really appropriate server hardware.

So my internal argument is whether to put a sata3 card in there maybe with raid support or to toss it now and get a new box with an i7 or e3 or e5, get decent disks including both ssd's and spinners (can't afford to put all my data on ssd's) and an ejectable sata bay for backups.

I think I'm going to start using server-class hardware for my workstations. Or at least good enough workstation hardware that they can be servers.

So about your requests:

I have these drives:

1. sda is a brand new SSD, 480g.
   
2. sdb is a green drive, 750g.
   
3. sdc is a green drive, 3t. This is the troublesome RAID member.
   
4. sdd is a green drive, 3t. This is the good RAID member.
   

I'm going to include statistics for all drives.