Page 1 of 1

RAID 1 table overwrtitten

Posted: 20 Oct 2016, 21:30
by kwerner
Good evening,

accidentally the partition table of a disk holding a linux software RAID 1 was overwritten with one from an empty disk.
Trying to recover my data I already tried photorec but wasn't successful.
I used ddrescue to copy all data from the 'original' disk (/dev/sdb)

More info:
(after the partition table had been overwritten with the one from the empty disk and replayed via ddrescue to /dev/sda)
root@rescue ~ # sgdisk -p /dev/sda
Disk /dev/sda: 5860533168 sectors, 2.7 TiB
Logical sector size: 512 bytes
Disk identifier (GUID): 07DDD8A6-8937-4897-805C-7121D21009B6
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 5860533134
Partitions will be aligned on 2048-sector boundaries
Total free space is 5860533101 sectors (2.7 TiB)
-
root@rescue ~ # sfdisk -l /dev/sda

Disk /dev/sda: 364801 cylinders, 255 heads, 63 sectors/track
Units: cylinders of 8225280 bytes, blocks of 1024 bytes, counting from 0
-
When running testdisk at this stage it says:

Hint: Intel partition table type has been detected.

The table being copied was GPT, though.

Choosing Intel I get:

1 P EFI GPT 0 0 2 267349 89 4 4294967295

Warning: Bad ending head (CHS and LBA don't match)
No partition is bootable

and Quick search brings:

* Linux RAID 0 65 2 1044 19 63 16769024 [Debian-82-jessie-64-minimal:0]
P Linux RAID 1044 150 3 1109 219 6 1048576 [Debian-82-jessie-64-minimal:1]
P Linux RAID 1109 219 7 134768 55 7 2147221504 [Debian-82-jessie-64-minimal:2]
L Linux RAID 134784 136 9 364785 17 32 3694958592 [Debian-82-jessie-64-minimal:3]

with EFI/GPT:

Current partition structure:
Partition Start End Size in sectors

Trying alternate GPT

Quick search:

>P Linux Raid 4096 16772999 16768904 [Debian-82-jessie-64-minimal:0]
P Linux Raid 16781312 17829255 1047944 [Debian-82-jessie-64-minimal:1]
P Linux Raid 17829888 2165051015 2147221128 [Debian-82-jessie-64-minimal:2]
P Linux Raid 2165313536 5860270599 3694957064 [Debian-82-jessie-64-minimal:3]

I tried recovering both but would result in a mountable filesystem. mdadm can indeed reassemble the second array (md1, which is /boot) and I end up with a mountable fs.
But only this one. And only if I had chosen Intel instead of GPT.

results of deep search:

TestDisk 7.1-WIP:

Disk /dev/sda - 3000 GB / 2794 GiB - CHS 364801 255 63

The harddisk (3000 GB / 2794 GiB) seems too small! (< 3945 GB / 3674 GiB)
Check the harddisk size: HD jumper settings, BIOS detection...
-
TestDisk 6.14:

Disk /dev/sda - 3000 GB / 2794 GiB - CHS 364801 255 63

The harddisk (3000 GB / 2794 GiB) seems too small! (< 1779 TB / 1618 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...

My RAID partitions are also shown but I cannot list the files. Logfile - about 4MB in size - shows me that ext4 has also been detected (together with a warning about the superblock):

block_group_nr 1

recover_EXT2: "e2fsck -b 32768 -B 4096 device" may be needed
recover_EXT2: s_block_group_nr=1/8190, s_mnt_count=0/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 268402640
recover_EXT2: part_size 2147221120
Filesystem created: Tue Oct 6 13:05:05 2015
MS Data 18092030 2165313149 2147221120
ext4 blocksize=4096 Large_file Sparse_SB Backup_SB, 1099 GB / 1023 GiB

This partition (the one I am most interested in) appears several times in the log. Only one line is different:
MS Data 18092032 2165313151 2147221120

But no ext4 fs appears in the output of deep search.

Anything I could try?