All of lore.kernel.org
 help / color / mirror / Atom feed
* restoring array after zeroing superblocks
@ 2012-03-23  9:13 Alexander Peganz
  0 siblings, 0 replies; only message in thread
From: Alexander Peganz @ 2012-03-23  9:13 UTC (permalink / raw)
  To: linux-raid

Hello,

Due to a spontaneous case of major brainfart I am now the proud owner
of a mdadm raid6 array with zeroed superblocks. As in I zeroed the
superblocks on each and every component device. I'm really hoping
there is still a way to recover from this since there are about 6TB of
data on there I cannot afford to loose.
The data itself should still be ok since nothing was written to the
components. I think I just need a way to restore the superblocks.



So first question: does mdadm create "backup-superblocks" that should
have survived the zeroing and that can be restored somehow?
If yes: That would save my day. I'd be eternally grateful for any
instructions as to how to do that.



If no: That means I'll have to recreate the array in a way that
doesn't destroy the data on it. Here's the whole story of the array:

I'm using Ubuntu 10.04 Server. Initially the array was a raid5 created
with the mdadm version that comes with that (2.6.7.1 according to
packages.ubuntu.com). It had the following parameters:
Metadata format 0.90, chunksize 1M, parity I don't remember but I'm
guessing the default left-symmetric
Later I added some drives and wanted to reshape to raid6. That wasn't
possible with that mdadm version. So I installed a Debian package with
version 3.1.4. With that I successfully reshaped the array. Strangely
the metadata version ended up being 0.91 after that, but it worked
perfectly fine for years since then, even through -G operations.
Components are the partitions /dev/sd[c-h]4.

I did some initial research and
mdadm -C /dev/md6 -e 0.90 -n 6 -c 1M -l 6 --assume-clean -a md /dev/sd[c-h]4
should at least not destroy the stored data. After doing a mdadm -o
/dev/md6 for safety e2fsck -fnv /dev/md6 should then tell me if the
file system is still ok without writing to the disks. mount with -r -o
ro,noload should safely mount it so I can check if everything is still
there. If the new metadata matches the old one everything should be
fine. Is this correct? Or could I end up destroying data with one of
the commands?

If it doesn't work that could mean that the layout is not correct. So
I'd probably have to try every possible sequence for the partitions
till each one is in it's correct place. Oh well, that's just 720
possible combinations, or 1440 if I have to try right-symmetric as
well :(
Is there some way to find out the correct sequence? If I take a look
at 6 locations on each partition that are 1M apart from each other (so
the parity chunks are on different drives for each location) it should
be possible to find out which ones contain data and which ones contain
the p- and the q-parity data and derive the layout from that. To do
that I'd need to know how the parity is calculated. The p-parity is
just xor as far as I know, but I don't know about the q-parity.
Incidentally, is there a simple way to print a single byte that was
read with dd to the console in binary?



Assuming all of this works and I get the array to start with the data
intact: the array size was smaller than the components. So I don't
know if the parity data in the area that was unused is correct. If I
get the array working again, will this be a problem? Or will the
parity information just get recalculated for those chunks?



I really hope someone here will be able to help me with this! I'm
grateful for any assistance you can provide!
Sincerely,
Alexander Peganz
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2012-03-23  9:13 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-03-23  9:13 restoring array after zeroing superblocks Alexander Peganz

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.