We have a machine that's a distro mirror - a *lot* of data, not just
CentOS. We had the data on /dev/sdc. I added another drive, /dev/sdd, and
created that as /dev/md4, with --missing, made an ext4 filesystem on it,
and rsync'd everything from /dev/sdc.
Note that we did this on *raw*, unpartitioned drives (not my idea). I then
umounted /dev/sdc, and mounted /dev/md4, and it looked fine; I added
/dev/sdc to /dev/md4, and it started rebuilding.
Then I was told to reboot it, right after the rebuild started. I don't
know if that was the problem. At any rate, it came back up... and /dev/sdc
is on as /dev/md127, and no /dev/md4, nothing in /etc/mdadm.conf, and, oh,
yes, mdadm -A /dev/md4 /dev/sdd
mdadm: Cannot assemble mbr metadata on /dev/sdd
mdadm: /dev/sdd has no superblock - assembly aborted
Oh, and
mdadm -E /dev/sdd
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
ee? A quick google says that indicates a legacy MBR, followed by an EFI....
I *REALLY* don't want to loose all that data. Any ideas?
mark
On 8/29/2014 14:26, m.roth at 5-cent.us wrote:> > Note that we did this on *raw*, unpartitioned drives (not my idea).Nothing wrong with that, particularly with big "midden" volumes like this one.> I added > /dev/sdc to /dev/md4, and it started rebuilding.*facepalm* You forgot the primary maxim of data integrity: two is one, one is none. When you overwrote your original copy with what you thought was a clone, you reduced yourself to a single copy again. If anything is wrong with that copy, you now have two copies of the error. What you *should* have done is buy two drives, set them up as a new mirror, copy the data over to them, then pull the old /dev/sdc and put it on a shelf as an offline archive mirror. /dev/sdc has probably already given you its rated service life, so it's not like you're really saving money here. The drive has already depreciated to zero. You're probably going to spend more in terms of your time (salary + benefits) to fix this than the extra drive would have cost you, and at the end of it, you still won't have the security of that offline archive mirror. I know this isn't the answer you wanted, but it's probably the answer a lot of people *wanted* to give, but chose not to, going by the crickets. (It's either that or the 3-day holiday weekend.) I don't know how much I can help you. I have always used hardware RAID on Linux, even for simple mirrors. I don't see why it matters that your /dev/sdd partitioning is different from your /dev/sdc. When you told it to blast /dev/sdc with the contents of /dev/sdd, it should have copied the partitioning, too. Are you certain /dev/sdc is partially overwritten now? What happens if you try to mount it? If it mounts, go buy that second fresh disk, then set the mirror up correctly this time.
On Aug 29, 2014, at 3:26 PM, m.roth at 5-cent.us wrote:> mdadm -E /dev/sddJust to confirm that /dev/sdd is the new disk after you rebooted, the right model and serial number, drive letters are assigned based on the order the block devices are detected so can change on reboot. ? Mark Tinberg mtinberg at wisc.edu
On 09/02/2014 04:16 PM, m.roth at 5-cent.us wrote:> > I know how to do this - it *is* how I started. Also, I guess you didn't > read the original post - these are 4TB drives, so no MBR, GPT only. > <snip> > And my manager has taken a fancy to raw drives; not sure why. > >Wait just a minute. How can you use the raw device but still have a GPT on it? That doesn't seem right, to have a GUID Partition Table but no partitions.