re-mount two old disk from raid0 setup to recover data
I had setup two 500gb disk in RAID0 on my server, but recently suffered a hard disk failure (saw a S.M.A.R.T error on the HDD at boot). My host has put 2 new disk in RAID-0 again (re-installed the OS) and re-attached the old drives on the same machine, so that I can recover the data.
My old drives are:
/dev/sdb
/dev/sdc
How can I mount these two disks back in RAID0, so that we can recover the data from our old drive? Or is this not possible any more? Have I lost all my data?
This is my /etc/fstab
and df -h
This is my fdisk -l:
[root@localhost ~]# fdisk -l
Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00040cf1
Device Boot Start End Blocks Id System
/dev/sda1 * 1 13 102400 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sda2 13 1288 10240000 83 Linux
/dev/sda3 1288 2333 8388608 82 Linux swap / Solaris
Disk /dev/sdc: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0005159c
Device Boot Start End Blocks Id System
/dev/sdc1 1 60802 488385536 fd Linux raid autodetect
Disk /dev/sdb: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x0006dd55
Device Boot Start End Blocks Id System
/dev/sdb1 * 1 26 204800 83 Linux
Partition 1 does not end on cylinder boundary.
/dev/sdb2 26 4106 32768000 82 Linux swap / Solaris
/dev/sdb3 4106 5380 10240000 83 Linux
/dev/sdb4 5380 60802 445172736 5 Extended
/dev/sdb5 5380 60802 445171712 fd Linux raid autodetect
Disk /dev/sdd: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x9f639f63
Device Boot Start End Blocks Id System
/dev/sdd1 1 60802 488385536 83 Linux
Disk /dev/md127: 956.0 GB, 955960524800 bytes
2 heads, 4 sectors/track, 233388800 cylinders
Units = cylinders of 8 * 512 = 4096 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 524288 bytes / 1048576 bytes
Disk identifier: 0x00000000
I read somewhere that you can do this with this command: mdadm -A --scan
however, it does not yield any result for me -> No arrays found in config file or automatically
First, determine the value of the data. If this is business-critical data that you have to have, evaluate your options with respect to sending the disks to a professional data recovery service. Self-recovery from dying disks and crashed RAID arrays is always a bit off the edge of the map. If you're already assuming that the data on the old drives is lost and you're just hoping for some recovery of data, and don't want to spend additional money, then proceed.
You will probably have to force the array together. This can result in silent corruption because the RAID knows that it's not clean, and you're telling it to put on a smile and pretend it is anyways. Just keep in mind you will need to manually verify integrity of any files you pull off of the RAID.
You can force an array together with:
mdadm --assemble --force /dev/md126 /dev/sdb5 /dev/sdc1
If /dev/md126
already exists on your system, pick the next one down (/dev/md125
) until you find a free (non-existent) device.
This should force the array into a working state. Let's mount the filesystem read-only so that we can pull data off of it without corrupting anything further
mkdir /mnt/oldData
mount /dev/md126 /mnt/oldData -o ro
At this point you should be able to copy data out of /mnt/oldData
and to a safe location.