Re: recover data from linear raid
On Jun 27, 2006 11:23 +1000, Neil Brown wrote: You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.60 ef53 ' Compile the findsuper tool from e2fsprogs - it was made for this. Also possible to use gpart. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
On Tue, 27 Jun 2006, Neil Brown wrote: On Monday June 26, [EMAIL PROTECTED] wrote: This is what I get now, after creating with fdisk /dev/hdb1 and /dev/hdc1 as linux raid autodetect partitions So I'm totally confused now. You said it was 'linear', but the boot log showed 'raid0'. You aire absolutely right. Me bad The drives didn't have a partition table on them, yet it is clear from the old boot log that the did. Are you sure they are the same drives, 'cause it doesn't seem like it. That's the root of my problem...when I moved the disks to the new system the disks showed up as unpartitioned. You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.60 ef53 ' should find them. Once you have this information we might be able to make something work. But I feel the chances are dwindling. Me too. In any case the data was not that critical, so I will play around a little more before I give up. Thank you all for your help:) -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
As Christian said, specific error message help a lot. Assume the two devices are hdc and hde, fdisk -l /dev/hdc fdisk -l /dev/hde mdadm -E /dev/hdc mdadm -E /dev/hde and my best guess mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde fsck -n /dev/md0 (and linux-raid@vger.kernel.org might be a better mailing list for this particular sort of problem). Disk /dev/hdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# fdisk -l /dev/hdc Disk /dev/hdc: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# mdadm -E /dev/hdb /dev/hdb: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e07f - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 0 3 640 active sync /dev/hdb 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm -E /dev/hdc /dev/hdc: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e054 - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 1 2201 active sync /dev/hdc 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdb /dev/hdc mdadm: array /dev/md0 built and started. fsck -n /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) Couldn't find ext2 superblock, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device fsck -b 8193 /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device During a recovery attemp today by mistake I created a mirror array with hdb as the primary and hdc as the secondary. I interrupted the array creation almost immediately, but part of the hdc was overwritten. However the array never held more than 70 gbytes of data, so I hope everything is intact on hdb :/ Thank you all for your kind help:) -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
I managed to get the hard disk of the retired system and this is its raid-related boot log: md: Autodetecting RAID arrays. [events: 004d] [events: 004d] md: autorun ... md: considering hdb1 ... md: adding hdb1 ... md: adding hdc1 ... md: created md0 md: bindhdc1,1 md: bindhdb1,2 md: running: hdb1hdc1 md: hdb1's event counter: 004d md: hdc1's event counter: 004d md0: max total readahead window set to 512k md0: 2 data-disks, max readahead per data-disk: 256k raid0: looking at hdb1 raid0: comparing hdb1(244195904) with hdb1(244195904) raid0: END raid0: == UNIQUE raid0: 1 zones raid0: looking at hdc1 raid0: comparing hdc1(293049600) with hdb1(244195904) raid0: NOT EQUAL raid0: comparing hdc1(293049600) with hdc1(293049600) raid0: END raid0: == UNIQUE raid0: 2 zones raid0: FINAL 2 zones raid0: zone 0 raid0: checking hdb1 ... contained as device 0 (244195904) is smallest!. raid0: checking hdc1 ... contained as device 1 raid0: zone-nb_dev: 2, size: 488391808 raid0: current zone offset: 244195904 raid0: zone 1 raid0: checking hdb1 ... nope. raid0: checking hdc1 ... contained as device 0 (293049600) is smallest!. raid0: zone-nb_dev: 1, size: 48853696 raid0: current zone offset: 293049600 raid0: done. raid0 : md_size is 537245504 blocks. raid0 : conf-smallest-size is 48853696 blocks. raid0 : nb_zone is 11. raid0 : Allocating 88 bytes for hash. md: ... autorun DONE. As Christian said, specific error message help a lot. Assume the two devices are hdc and hde, fdisk -l /dev/hdc fdisk -l /dev/hde mdadm -E /dev/hdc mdadm -E /dev/hde and my best guess mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdc /dev/hde fsck -n /dev/md0 (and linux-raid@vger.kernel.org might be a better mailing list for this particular sort of problem). Disk /dev/hdb: 250.0 GB, 250059350016 bytes 255 heads, 63 sectors/track, 30401 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# fdisk -l /dev/hdc Disk /dev/hdc: 300.0 GB, 300090728448 bytes 255 heads, 63 sectors/track, 36483 cylinders Units = cylinders of 16065 * 512 = 8225280 bytes Device BootStart EndBlocks Id System [EMAIL PROTECTED] root]# mdadm -E /dev/hdb /dev/hdb: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e07f - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 0 3 640 active sync /dev/hdb 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm -E /dev/hdc /dev/hdc: Magic : a92b4efc Version : 00.90.00 UUID : 293be3e8:5a7ac6e7:adefc469:84f8aefb Creation Time : Fri Jun 23 15:47:10 2006 Raid Level : linear Device Size : 244198464 (232.89 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Fri Jun 23 15:48:43 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : f790e054 - correct Events : 0.2 Rounding : 32K Number Major Minor RaidDevice State this 1 2201 active sync /dev/hdc 0 0 3 640 active sync /dev/hdb 1 1 2201 active sync /dev/hdc [EMAIL PROTECTED] root]# mdadm --build /dev/md0 --level linear --raid-disks 2 /dev/hdb /dev/hdc mdadm: array /dev/md0 built and started. fsck -n /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) Couldn't find ext2 superblock, trying backup blocks... fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device fsck -b 8193 /dev/md0 fsck 1.32 (09-Nov-2002) e2fsck 1.32 (09-Nov-2002) fsck.ext2: Bad magic number in super-block while trying to open /dev/md0 The superblock could not be read or does not describe a correct ext2 filesystem. If the device is valid and it really contains an ext2 filesystem (and not swap or ufs or something else), then the superblock is corrupt, and you might try running e2fsck with an alternate superblock: e2fsck -b 8193 device During a recovery attemp today by
Re: recover data from linear raid
This is what I get now, after creating with fdisk /dev/hdb1 and /dev/hdc1 as linux raid autodetect partitions mdadm -E /dev/hdb1 /dev/hdb1: Magic : a92b4efc Version : 00.90.00 UUID : a7e90d4b:f347bd0e:07ebf941:e718f695 Creation Time : Wed Mar 16 18:14:25 2005 Raid Level : raid0 Device Size : 244195904 (232.88 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Wed Jun 21 21:57:37 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : c8c21ed8 - correct Events : 0.82 Chunk Size : 64K Number Major Minor RaidDevice State this 0 3 650 active sync /dev/hdb1 0 0 3 650 active sync /dev/hdb1 1 1 2211 active sync /dev/hdc1 [EMAIL PROTECTED] root]# mdadm -E /dev/hdc1 /dev/hdc1: Magic : a92b4efc Version : 00.90.00 UUID : a7e90d4b:f347bd0e:07ebf941:e718f695 Creation Time : Wed Mar 16 18:14:25 2005 Raid Level : raid0 Device Size : 244195904 (232.88 GiB 250.06 GB) Raid Devices : 2 Total Devices : 2 Preferred Minor : 0 Update Time : Wed Jun 21 21:57:37 2006 State : clean, no-errors Active Devices : 2 Working Devices : 2 Failed Devices : 0 Spare Devices : 0 Checksum : c8c21ead - correct Events : 0.82 Chunk Size : 64K Number Major Minor RaidDevice State this 1 2211 active sync /dev/hdc1 0 0 3 650 active sync /dev/hdb1 1 1 2211 active sync /dev/hdc1 -- Dimitris Zilaskos Department of Physics @ Aristotle University of Thessaloniki , Greece PGP key : http://tassadar.physics.auth.gr/~dzila/pgp_public_key.asc http://egnatia.ee.auth.gr/~dzila/pgp_public_key.asc MD5sum : de2bd8f73d545f0e4caf3096894ad83f pgp_public_key.asc - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
On Monday June 26, [EMAIL PROTECTED] wrote: This is what I get now, after creating with fdisk /dev/hdb1 and /dev/hdc1 as linux raid autodetect partitions So I'm totally confused now. You said it was 'linear', but the boot log showed 'raid0'. The drives didn't have a partition table on them, yet it is clear from the old boot log that the did. Are you sure they are the same drives, 'cause it doesn't seem like it. You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.60 ef53 ' should find them. Once you have this information we might be able to make something work. But I feel the chances are dwindling. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: recover data from linear raid
On Monday June 26, [EMAIL PROTECTED] wrote: This is what I get now, after creating with fdisk /dev/hdb1 and /dev/hdc1 as linux raid autodetect partitions So I'm totally confused now. You said it was 'linear', but the boot log showed 'raid0'. The drives didn't have a partition table on them, yet it is clear from the old boot log that the did. Are you sure they are the same drives, 'cause it doesn't seem like it. You could try hunting for ext3 superblocks on the device. There might be an easier way but od -x /dev/hdb | grep '^.60 ef53 ' should find them. Once you have this information we might be able to make something work. But I feel the chances are dwindling. NeilBrown - To unsubscribe from this list: send the line unsubscribe linux-raid in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
