LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Server (https://www.linuxquestions.org/questions/linux-server-73/)
-   -   mdadm & raid6: does re-create(with different chunk size) + resync destroy orig. data? (https://www.linuxquestions.org/questions/linux-server-73/mdadm-and-raid6-does-re-create-with-different-chunk-size-resync-destroy-orig-data-837920/)

schanhorst 10-13-2010 08:57 PM

mdadm & raid6: does re-create(with different chunk size) + resync destroy orig. data?
 
Hi all,
I would like to rescue data on my software raid-6 array. I did some stupid actions (described bellow) with this original array.

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):

1) zeoring superlocks of all the active disks/partitions registered in the array
2) 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
3) resync-ing the array

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:
a) Does ordering of hard drives/partitions (as they are ordered on mdadm command line) play role for raid6 creation & initial resync?
b) 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

rweaver 10-15-2010 03:50 PM

If memory serves me using --create doesn't necessarily destroy the data on the partitions, but if you change the raid type it would be bad (tm)... from what you said you've changed the chunk, layout, and disk order... and in all likelihood if that didn't destroy your data it exponentially increased the difficulty of recovery. If you zero'd the super block your raid isn't going to work right until the raid is recreated on it, which is what you appeared to do except you didn't use similar options. Without additional information, if your data isn't visible or mountable at this point, it's probably effectively gone, although you could attempt to use a data recovery tool to pull some of it off (ext3grep, tsk, etc.) The main thing is, no matter what kind of raid you're using-- backup, backup, backup. Before you do or change anything, backup. Before you leave for the weekend, backup. Before you sneeze backup. Backups are the simple most important operation any sysadmin can ever perform if the data has any value at all.

schanhorst 10-15-2010 04:31 PM

Thank a lot for answer ...

we are talking about raid-6 assembled from 6 1TB drives => it results in to the ~4TB capacity of that raid ...
The array was supposed to serve for home usage purposes - mostly garbage like movies and music () but also all the important personal/family photos & document data ...
Array have been working with NO issues until I zeroed superblocks by "mdadm --zero-superblock /dev/sd[...]1" ...

Then I was playing with array with effort to rescue data, I used the "mdadm --create --assume-clean ..." to make sure that only superblocks will be operated and NO resync will be triggered automatically ...
... but once, the last one, I forgot to specify the "--assume-clean" and resync has been triggered automatically ... that is my story.

In effort to recover array superblocks, I tried to call the "mdadm --create --assume-clean ..." with different values of chunk size, layout and mainly ordering of disks, then "mdadm --assemble ..." and then try to mount the assembled array to test whether I hit the right configuration of the array ...
... the last one, I forgot to specify the "--assume-clean" ...

Specific numbers and configuration of the array should not be relevant for this case ...

I fully understand your point about backup whenever it is possible - it is typical paranoia of all the admins and it seems I will need remove dust off my paranoia remaining from my old admin times ...

But anyway, it would be still handy for many of us to know answers to sub-questions from my initial post ...

Thanks & Best Regard,
Peter


All times are GMT -5. The time now is 03:10 PM.