I would like to rescue data on my software raid-6 array. I did some stupid actions (described bellow) with this original array.
Main Question:
I need to know if original data stored on raid-6 array are definitely lost (or not) after the following actions have been prepared upon this array (executed in the order listed bellow):
zeroing super-blocks of all the active disks/partitions registered in the array
executing the "mdadm --create ..." command using different options (see bellow for list) than have been used when array have been created originally: -> different chunk size -> different layout -> different disks order
resync-ing the array
Note: Specific values of mdadm parameters should not be relevant here, since this is about the principle how mdadm works ...
I think points 1) & 2) should not even touch the original data since they are supposed to manipulate just superblocks
I see the 3) point as most critical from data lost point of view: I'm not sure what exactly is happening with array during resync, but based on heavy activity of all involved hard drives (for ~7 hours) I assume the data storage area is completely re-processed ...
Sub-questions:
Does ordering of hard drives/partitions (as they are ordered on mdadm command line) play role for raid6 creation & initial resync?
What everything is necessary to backup after array creation to be able to safely re-create the array in similar situation as my is (e.g. backup superblocks informations & partition table info for each disk involved in the array ...)?
Comment:
The mdadm wiki article (http://en.wikipedia.org/wiki/Mdadm) should be revised and author should be kicked in to ass a little bit, or more then just a little bit ...
The article mentions the zeroing superblocks & subsequent array re-creation as solution for getting rid of the "mdadm: Cannot open ...: Device or resource busy" issue.
Author somehow forgot to mention important step - to backup the parameters the original array (superblocks) as the first step ... and also my investigation seems to point out that the ordering of the involved disks/partitions plays role as well ...
Thanks for answers,
Peter