Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

The computer that this is occurring in, has a 40GB boot drive (Debian) and two non-boot drives.

I have two identical 1.5TB drives (one partition on each), and one of them had data on it (other was empty). So I ran 'dd' to clone the one to the other, and then I had two identical drives. I wanted then, to build a software RAID array in Debian, and so I created it with one disk and labeled the other one as 'missing.' Added the second disk, and let it sync. And now, mounting and running 'ls' on the new array, I get:

# ls
lost+found

Using fdisk /dev/md0 I get:

Disk /dev/md0: 1500.2 GB, 1500164849664 bytes
2 heads, 4 sectors/track, 366251184 cylinders, total 2930009472 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/md0 doesn't contain a valid partition table

Now, I don't entirely believe that all my data is "gone" since I never formatted the array, but I am saving my "panic" for tomorrow if nothing can be done.

How should I proceed?

share|improve this question
    
You're severely lacking of basic understanding what RAID is and how to use it. (Why would ya use fdisk /dev/RAID(?) — it's Linux software RAID, not hardware one). No one can put understanding in your head until you want it. So go and read the manual. –  poige Jul 31 '13 at 4:15
    
@poige - using fdisk is supposed to give "doesn't contain a valid partition table" on a software array. I was posting that to show that it was indeed an array of 1.5TB. –  ionFish Jul 31 '13 at 4:26
    
I can look into your issue provided with SSH access, but rather not waste my time guessing what you meant here. –  poige Jul 31 '13 at 5:00

2 Answers 2

up vote 3 down vote accepted

Sorry to say, but it's likely that you've hosed both disks because it looks like you created a filesystem on md0.

Just in case, give this a try:

mdadm --stop /dev/md0

Then mount each member partition (e.g. sdb1, sdc1) individually and see if you have your original filesystem on either disk.

I know it's a little late, but the correct procedure is:

0) BACKUP

1) Double check that the backup was successful and data integrity was preserved

2) Create RAID using empty (or destructible) disk (or partition) + missing. Data on this disk or partition will be destroyed.

3) Create file system on new RAID volume.

4) Copy existing files to RAID volume from original disk.

5) Add original disk or partition to RAID volume in place of missing. Data on original disk or partition will be destroyed.

Since you had cloned the partitions before hand, in the above steps it wouldn't have mattered which disk you used as the "original" or the "empty".

share|improve this answer
    
Running 'testdisk' and other tools now, but it doesn't look good. I forgot to mention that the power failed while I was building the array at first, which is because it was late at night when I posted this. Either way, my fault if it doesn't work. Thanks for the help though. –  ionFish Jul 31 '13 at 13:47

If you wanted to use RAID, you would have needed to format the disks for it at the beginning. You haven't said how you created the RAID array, but if you instantiated it with a disk that already had data on it you've lost the data.

Since you used ls on the array somehow (did you mount the entire RAID device as an ext3 partition perhaps?), there is a filesystem on it. This would not be the case if you didn't format it.

RAID1 (as any RAID level) contains metadata in addition to the mirrored data on the volumes. Simply having two identical volumes is not sufficient to create a RAID array.

share|improve this answer
    
You don't have to format the disks to use them as RAID members. They can be raw disks, raw partitions, LVs, partitions will filesystems on them, etc. Also, simply creating a RAID device does not destroy the disk that's the source of the sync. (I wasn't sure and just tested it on a couple of loop disks -- I created an ext3 filesystem on loop0, then created md0 with loop1 missing, and then added loop0 in place of the missing member. After letting it sync and then stopping the array, loop0 was still mountable with my existing data). loop0 only got hosed by mkfs.et3 /dev/md0. –  s.co.tt Jul 31 '13 at 5:02
    
If you initialize them as part of a RAID array and do anything at all on the array, it will overwrite things. If you were doing this with a hardware raid controller, merely creating an array with them will usually overwrite their MBR, but not necessarily format them. –  Falcon Momot Jul 31 '13 at 5:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.