1

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

  1. zeroing super-blocks 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

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:

  1. Does ordering of hard drives/partitions (as they are ordered on mdadm command line) play role for raid6 creation & initial resync?

  2. 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

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
schanhorst
  • 11
  • 6

3 Answers3

1

I looked at the wikipedia article, and the bit about deleting the superblock etc. is right, but it's supposed to be used for solving a different problem than what you were apparently trying to solve. The intention in the article is to "clean out" a drive that has old RAID settings on it so that you can use it in a new array.

You should, of course, never clear the superblock on a drive that currently contains data that you want to preserve. The superblock contains critical information regarding how the data on that drive is organized, so erasing or changing the superblock it is unhelpful unless you intend to throw away the data with it.

tylerl
  • 15,055
  • 7
  • 51
  • 72
0

You're probably right about only affecting the superblocks until the drives began to re-sync, but at this point that's hardly a significant detail. By now your data is in an unknown state if it's even there at all.

I don't think you'll be helped any further by advice you read on the Internet, even from this site. Simply trying out things you read online is only a valid course of action if failure is not a problem.

If the data is very important to you, I'd recommend turning the drives over to a data recovery lab and letting them work on it. If your data is still intact in some form, they'll have the experience to know how to fix your problem without causing any further damage.

Edit
Luckily, since rebuilding your parity data should ONLY affect the parity data, you theoretically may still have just enough information left untouched to reconstruct your original content, assuming you started out with a clean and healthy array before this mess happened.

However, reconstructing it would be non-trivial and require a lot of work building a profile of the array by hand, especially if you changed some of the dimensions of your array when you overwrote the superblocks.

It would almost definitely not survive doing this sort of thing twice, though.

tylerl
  • 15,055
  • 7
  • 51
  • 72
  • I have been re-creating the array with "--assume-clean" option (e.g. "mdadm --create --assume-clean ...") in effort to find out the right superblocks configuration to avoid automatic trigger of resync -> this should ensure that just superblocks will be affect and data storage area will remain untouched ... But the last time I have been playing with --create command I forgot to specify the "--assume-clean" option and I it was to late when I recognized, that "resync" has been triggered automatically and running long enough to destroy data ... – schanhorst Oct 19 '10 at 03:08
  • Edit w/ more info – tylerl Oct 19 '10 at 05:59
0

The confusing part is:

create and then resynced for 7 hours.

When an array is created, the filesystem is generally created on top and there is no resyncing. Zeroing the superblocks makes it difficult for the raid set to figure out which order the drives were in when the raidset tries to assemble itself automatically. What did you do with the create? create it with 2 drives, missing 2, then grow it and add the others? or did you create it as a raid-6 set and add all drives at the same time.

If the latter, it should not have resynced. IF you didn't grow the array and the drives resynced, it sounds almost like it detected a portion of the array. After the resync, did you have to make a filesystem or did a filesystem already exist?

If the chunk size changed, that's not good. If the alignment of the partitions changed, again, not good. Order of the drives changed, again, not good. You have a number of things that probably have made it extremely difficult to recover the data if at all.

The one thing that I find very curious is the resync. Raid-6 can take two drive failures and still have the ability to recover. But, some of the things you did almost make me think you're in a situation that is going to be almost unrecoverable except by experts.

karmawhore
  • 3,865
  • 18
  • 9
  • The array is raid-6 assembled from 6 1TB disks, what gives ~4TB array data space. I created have been re-creating the array using the same number of disks (partitions) as the original array was created, executing the "mdadm --create --assume-clean ... /dev/md0 /dev/sd[abcdefg]1". I varied chunk size, layout and disk order from execution to execution. I tried to mount the /dev/md0 after each execution of "mdadm --create --assume-clean ..." & "mdadm --assemble ...". I have been trying until it once happened that I forgot to specify "--assume-clean" option, what autom. triggered resync. – schanhorst Oct 19 '10 at 03:54
  • Basically I did following steps – schanhorst Oct 19 '10 at 04:21
  • (the original array has been working without any issues ... ) "mdadm --misc --zero-superblock /dev/sd[abcdef]1" (then x-times following set of commands with different chunk, layout and disks order) "mdadm --create --assume-clean ... /dev/md0 /dev/sd[abcdef]1" "mdadm --assemble /dev/md0 /dev/sd[abcdef]1" "mount /dev/md0 /mnt/array" I executed the "mount ..." command to check if the array has been re-created correctly. – schanhorst Oct 19 '10 at 04:26
  • The issue about disk order is, that the /dev/sdxy block device filenames are paired to real devices automatically during each system startup by udev functionality of the linux kernel, what is by default enabled in Ubuntu distribution ... The result is, that once you zero array superblocks and then reboot, you don't have a glue how the real hard drives were mapped before to /dev/sdxy block device files ... (order changes each restart thanks to udev ... – schanhorst Oct 19 '10 at 04:37
  • Thanks for answer ... I also think the data are gone ... But I'm still curious what is happening during the resync procedure ... I also remember, that the the first time I created the original array, the resync procedure took also several hours ... – schanhorst Oct 19 '10 at 04:46
  • The order changes, but, is usually based on the order of the SATA ports. And since udev uses that order, they are probably in the same order. Missing the --assume-clean is probably the killer. At that point, two of those drives would then have gotten new chunks written and assembled from the existing config that was given at that point. All attempts to mount have failed, you haven't created a new filesystem over it? If so, grep through one of the drives to see if you can find any recognizable content. With the steps you describe, I think your chances are slim. – karmawhore Oct 19 '10 at 05:06
  • Because the RAID configuration was changed by creating a new superblock, the array would have started in an unclean state. Mdadm would therefore mark the array degraded and reconstruct its parity data. If the raid configuration matched exactly the way it was before, then it would simply be overwriting the old parity data with an identical copy. But otherwise, you'd be building a whole new array. – tylerl Oct 19 '10 at 05:52
  • Hi thanks for response ... You are right, the wikipedia article is completely about the different stuff than my current problem is... BUT my VERY FIRST problem with original array (when it was still working) was that some devices have been "captured" by some another part of kernel (module or whatever ...) and it caused that mdadm could not assemble the array. mdadm spilled out the error: "mdadm: Cannot open ...: Device or resource busy". And this was the reason why I followed wiki article in effort to get rid of this issue. I uninstalled the dmraid, since it was one of reason of busy devices. – schanhorst Oct 20 '10 at 02:05
  • Basically, my initial problem was just & only that mdadm could not assemble the array because of "... Device or resource busy." error. After some googling, I found that the "dmraid" kernel module + affiliated software package is one of possible reasons of the issue and how to fix it (see the http://www.righteoushack.net/?p=197 link). After that everything worked a few days, but then the same issue popped up again ... so I started investigation once again ... and I ended up with the mentioned wiki article ... – schanhorst Oct 20 '10 at 02:18
  • But, interesting is, that the "palimpsest" tool from RedHat (perhaps more widely known under the "Disk Utility" symbolic name) has been able to assemble the array with no issues anytime I had an issues to do so with the "mdadm --assemble ..." directly in command line or during system startup managed from from mdadm.conf (ending up with the "... device or resource busy." error ...). BTW: the 'palimpsest' tool is really well made, it has simple but highly effective GUI + really rich functionality including SMART. – schanhorst Oct 20 '10 at 02:25
  • Regarding udev & disks pairing to /dev/sdxy device files: Definitely I can say, that on my system, each single time (each system restart) I got different pairing ... I have been surprised why this is happening ... I didn't touch default Ubuntu udev configuration in /etc/udev/... I even checked this several time but I didn't find anything suspicious, what could cause such massive re-shaking of devices pairing at each boot time ... – schanhorst Oct 20 '10 at 02:40
  • QUESTION: Does I understand it correctly, that chunk size is the size of the strip (elementary unit of the raid-5&6 array)? – schanhorst Oct 20 '10 at 02:56
  • If so, the I think there is just one logical answer to may main question whether the original data are lost or not after resync: ====> Definitely YES, they ARE LOLST ===> IF <=== chunk size of the original array DIFFERS to new chunk size used for the last resync. This is my understanding. – schanhorst Oct 20 '10 at 02:57
  • The reason is that once the chunk size differs, new strips will NOT match the strips from original array (the original and new strips are not aligned any more) and so when resync will try to re-calculate and overwrite "JUST" parity strips, the original data strips will be affected too (some of data strips will be overridden just partially some of them completely and some not at all, but in general, data are lost definitelly ...) – schanhorst Oct 20 '10 at 02:57