Help - Recover data after partition table overwritten

[shadowcliffs]

Dear all,

I really need some help recovering data on an EZ Media & Backup Center 2TB version after partition table being overwritten in mistake.

I have two EZ Media & Backup Center boxes 2TB version. One day one of them start to have trouble logging in to management. It seems some part of the hard drive is corrupted, so I took the drive out, did a full format, and tried to reinstall firmware to this hard drive. I followed what says here viewtopic.php?f=279&t=8317 step by step, but it didn't work after many tries. Before I found out it's the USB stick that caused all the trouble (firmware installed later on after using another USB stick), I thought I can copy the partition table of the hard drive from another working EZ Media & Back Center to this hard drive, so I played with sgdisk -R=/dev/sdY /dev/sdX after googling it. The trouble it, I took the order wrong. I thought it means copy partition table from /dev/sdY to /dev/sdX, Actually it's the other way round.

In summary, the partition of a fully working EZ M&B hard drive is overwritten with the one from another hard drive fully for mated and treated with
sudo dd if=/home/username*/ez/zImage of=/dev/sdb bs=512 seek=2048
sudo dd if=/home/username*/ez/initrd of=/dev/sdb bs=512 seek=8192

Any chance the data can still be recovered?

I tried using testdisk in Ubuntu. After going through deep search, some data seems recoverable at file level, meaning files are list not in their original name, but in name like 0001.jpg, 0002.jpg. I really want files can be recovered at directory level.

Is it still possible to recover data at directory level?

I know that there are virus that can corrupt partition table. Once the virus is cleaned and partition table recovered, the data is still there as long as no addition data is written to the drive afterwards. I'm not sure if it's the case for GPT partition table.

[Mijzelf]

And now your 2nd EZ is up&running again? In that case I guess you can just copy the partition table back:
Connect the sourcedisk (your newly installed EZ)

Code: Select all

dd if=/dev/<sourcedisk> of=/tmp/copy_of_partititon_table bs=512 count=2048

Connect the target disk (the 'unreadable' disk)

Code: Select all

dd if=/tmp/copy_of_partititon_table  of=/dev/<targetdisk>

[shadowcliffs]

I followed all these steps and did a reboot, but that huge partition is still not seen in Ubuntu. The same partition is seen on the second drive once connected to Ubuntu.

And now your 2nd EZ is up&running again? In that case I guess you can just copy the partition table back:
Connect the sourcedisk (your newly installed EZ)

Code: Select all

dd if=/dev/<sourcedisk> of=/tmp/copy_of_partititon_table bs=512 count=2048

Connect the target disk (the 'unreadable' disk)

Code: Select all

dd if=/tmp/copy_of_partititon_table  of=/dev/<targetdisk>

[Mijzelf]

The data partitions cannot simply be mounted from any linux system. Maybe it's a single disk raid1 array, which first has to be assembled, but at least the are a few 'logical volumes'.

Here you can find directions to mount the logical volumes.

[shadowcliffs]

After putting this drive back to the box and accessing it through the management page, it says "Lenovo EZ not ready. You must authorize overwriting existing data to start using this device". The good thing is I can log in with putty now, but there is nothing listed under /mnt/pools/, so A is not mounted.

There is some tips at http://ix2-200.wikidot.com/recover, but ix2-200 has 2 bays, so the mounting command must be different.

Code: Select all

# parted /dev/sda
GNU Parted 1.8.8
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) check 2
Error: Could not detect file system.
(parted) print all partition
Model: Seagate ST2000DM001-9YN1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      33.6MB  21.5GB  21.5GB               primary
 2      21.5GB  2000GB  1979GB               primary


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-vol1: 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  17.2GB  17.2GB  xfs


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-BFDlv: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  4295MB  4295MB  ext2


Error: /dev/mtdblock0: unrecognised disk label

Error: /dev/mtdblock1: unrecognised disk label

Error: /dev/mtdblock2: unrecognised disk label

Error: /dev/md0: unrecognised disk label

Error: /dev/md127: unrecognised disk label

The data partitions cannot simply be mounted from any linux system. Maybe it's a single disk raid1 array, which first has to be assembled, but at least the are a few 'logical volumes'.

Here you can find directions to mount the logical volumes.

[Mijzelf]

Did you actually try the instructions?

[shadowcliffs]

Sorry, yes, I did. lvdisplay only see those two small partition but not the big data partition. The big partition can only be seen with parted as mentioned above.

Code: Select all

# mdadm --assemble --scan
mdadm main: failed to get exclusive lock on mapfile
mdadm: /dev/md/meng-Z87-D3HP:1 has been started with 1 drive.

# vgchange -ay
  2 logical volume(s) in volume group "md0_vg" now active

# pvs
  PV         VG     Fmt  Attr PSize  PFree
  /dev/md0   md0_vg lvm2 a-   20.00G    0

/# lvdisplay
  --- Logical volume ---
  LV Name                /dev/md0_vg/BFDlv
  VG Name                md0_vg
  LV UUID                1ukPOC-koB3-lFfy-7mCg-XBuT-3363-z65t9g
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                4.00 GB
  Current LE             1024
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:0

  --- Logical volume ---
  LV Name                /dev/md0_vg/vol1
  VG Name                md0_vg
  LV UUID                bz0HIu-lSq2-t8yr-erow-s3kl-aPJv-jV0cSO
  LV Write Access        read/write
  LV Status              available
  # open                 1
  LV Size                16.00 GB
  Current LE             4095
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           253:1

Did you actually try the instructions?

[Mijzelf]

Right. If you look at the Stock Configuration, you can see that both LV's you found are in md0/sda1, while md1 is not assembled.

Code: Select all

mdadm main: failed to get exclusive lock on mapfile

Don't know what that means (other than the obvious meaning). Maybe that is the reason md1 is not assembled. You can try it manually.

Code: Select all

mdadm --assemble /dev/md1 /dev/sda2 --run

If that works, repeat the LV instructions to get the internal LV.

If that doesn't work... Is the disk which donated the partition table identical? Same brand, same size?

[shadowcliffs]

Code: Select all

# mdadm --assemble /dev/md1 /dev/sda2 --run
mdadm: no recogniseable superblock on /dev/sda2
mdadm: /dev/sda2 has no superblock - assembly aborted

Yes, these two drives are identical: Seagate ST2000DM001, PN: 9YN164.

The only difference is that bad sectors was found on that drive after fw was copied to it and started normally once. Just received RMA and I'm waiting for a replacement device.

Right. If you look at the Stock Configuration, you can see that both LV's you found are in md0/sda1, while md1 is not assembled.

Code: Select all

mdadm main: failed to get exclusive lock on mapfile

Don't know what that means (other than the obvious meaning). Maybe that is the reason md1 is not assembled. You can try it manually.

Code: Select all

mdadm --assemble /dev/md1 /dev/sda2 --run

If that works, repeat the LV instructions to get the internal LV.

If that doesn't work... Is the disk which donated the partition table identical? Same brand, same size?

[Mijzelf]

The only difference is that bad sectors was found on that drive after fw was copied to it and started normally once.

'That drive'. Which one? The one you are trying to recover now, or the 'donor disk'?

Your partition table is restored, as proven by the ability to assemble md0, and find the two logical volumes on it. Yet md1 is missing a superblock. That can be caused by data damage, or by bad sectors (which is also data damage, of course), or by a wrong partition size. About the last possibility: Depending on the version of raid metadata, the superblock is stored at the end of the partition -64k, at the beginning of the partition, or at the beginning of the partition +4k. For the first possibility it's important that the partition has exact the right size. That's why I asked about it.
Assuming that the partition has the right size, then the superblock is damaged. It is possible to rewrite it, but you'll need to know which metadata version. You want to write the new superblock on the same position. We can ask the metadata version of the donor disk:

Code: Select all

mdadm --examine /dev/sda2

where of course sda2 has to be exchange by the rigth value for the 2nd partition of the donor disk.

If the damage of the superblock is caused by bad sectors, it's may be not possible (and is not recommended) to write a new superblock to the same disk. In that case you first have to create a low-level copy of the whole disk (using dd_rescue) and rewrite the superblock on the copy.

[shadowcliffs]

It's the "donor one" that has been found having bad sectors. This donor is the trouble maker. If it's not for the attempt to fix it at the first place (I didn't know there was bad sector), the other drive wont get messed up accidentally.

Now the one with bad sector has been completely dead.

Maybe I should wait for the replacement drive to arrive and copy the partition table over again?

Thanks so much for all the help.

The only difference is that bad sectors was found on that drive after fw was copied to it and started normally once.

'That drive'. Which one? The one you are trying to recover now, or the 'donor disk'?

Your partition table is restored, as proven by the ability to assemble md0, and find the two logical volumes on it. Yet md1 is missing a superblock. That can be caused by data damage, or by bad sectors (which is also data damage, of course), or by a wrong partition size. About the last possibility: Depending on the version of raid metadata, the superblock is stored at the end of the partition -64k, at the beginning of the partition, or at the beginning of the partition +4k. For the first possibility it's important that the partition has exact the right size. That's why I asked about it.
Assuming that the partition has the right size, then the superblock is damaged. It is possible to rewrite it, but you'll need to know which metadata version. You want to write the new superblock on the same position. We can ask the metadata version of the donor disk:

Code: Select all

mdadm --examine /dev/sda2

where of course sda2 has to be exchange by the rigth value for the 2nd partition of the donor disk.

If the damage of the superblock is caused by bad sectors, it's may be not possible (and is not recommended) to write a new superblock to the same disk. In that case you first have to create a low-level copy of the whole disk (using dd_rescue) and rewrite the superblock on the copy.

[Mijzelf]

Yes, I think it's a good idea to wait for the new disk. Your current partition table seems fine, yet it won't hurt to compare it to a known good one. If your perception of what happened to this disk is right, the superblock shouldn't be damaged. A slighty wrong partition table could explain that.
And if indeed the superblock is hurt, we still need a sane one, to know which metadata version to use for a replacement.

[shadowcliffs]

The replacement device arrived with the same ST2000DM001 but different PN of 1CH162, while the receiver drive is 9YN164. Does it matter?

Edit: I still proceeded ahead. After copied over the partition info, I got the same result as before.

Code: Select all

#mdadm --examine /dev/sda2
mdadm: No md superblock detected on /dev/sda2

Compared with the working drive, I noticed that 2 RAID arrays are not there. There should be 3 RAID Arrays in total:
21 GB RAID Array: /dev/md0
2.0TB RAID Array: /dev/md127 (currently missing)
21 GB RAID Array: /dev/md126 (currently missing)

Yes, I think it's a good idea to wait for the new disk. Your current partition table seems fine, yet it won't hurt to compare it to a known good one. If your perception of what happened to this disk is right, the superblock shouldn't be damaged. A slighty wrong partition table could explain that.
And if indeed the superblock is hurt, we still need a sane one, to know which metadata version to use for a replacement.

[Mijzelf]

The replacement device arrived with the same ST2000DM001 but different PN of 1CH162, while the receiver drive is 9YN164. Does it matter?

I don't think so. The only thing what actually matters is the total number of sectors on that disk. Although it might matter if the new disk has 'advanced format' sectors, and the old doesn't, or vice versa.

Can you post the output of

Code: Select all

parted -l /dev/sda
mdadm --examine /dev/sda1
mdadm --examine /dev/sda2

of both disks?

[shadowcliffs]

Donor (working) drive:

Code: Select all

# parted -l /dev/sda
Model: Seagate ST2000DM001-1CH1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      33.6MB  21.5GB  21.5GB               primary
 2      21.5GB  2000GB  1979GB               primary


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/6690d340_vg-lv31dd0603: 1979GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  1979GB  1979GB  ext3


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-vol1: 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  17.2GB  17.2GB  ext3


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-BFDlv: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  4295MB  4295MB  ext2


Error: /dev/mtdblock0: unrecognised disk label

Error: /dev/mtdblock1: unrecognised disk label

Error: /dev/mtdblock2: unrecognised disk label

Error: /dev/md0: unrecognised disk label

Error: /dev/md1: unrecognised disk label

# mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x0
     Array UUID : dc3db93b:b7a5ad00:9a6add76:b9486bdd
           Name : (none):0
  Creation Time : Tue Jul  9 10:42:04 2013
     Raid Level : linear
   Raid Devices : 1

 Avail Dev Size : 41943025 (20.00 GiB 21.47 GB)
  Used Dev Size : 0
    Data Offset : 16 sectors
   Super Offset : 8 sectors
          State : clean
    Device UUID : cca33522:c3500860:55d718bc:c2e657f3

    Update Time : Tue Jul  9 10:42:04 2013
       Checksum : b06ac77e - correct
         Events : 0

       Rounding : 0K

   Device Role : Active device 0
   Array State : A ('A' == active, '.' == missing)
# mdadm --examine /dev/sda2
/dev/sda2:
          Magic : a92b4efc
        Version : 1.1
    Feature Map : 0x0
     Array UUID : 9643abe4:f1d1fe01:dd60bba4:c2a5f988
           Name : LenovoEZ-2:1
  Creation Time : Tue Jul  9 10:47:00 2013
     Raid Level : raid1
   Raid Devices : 1

 Avail Dev Size : 3864756224 (1842.86 GiB 1978.76 GB)
     Array Size : 1932377920 (1842.86 GiB 1978.75 GB)
  Used Dev Size : 3864755840 (1842.86 GiB 1978.75 GB)
    Data Offset : 262144 sectors
   Super Offset : 0 sectors
          State : clean
    Device UUID : 74b147ac:51609de6:76980866:31ec78f0

    Update Time : Tue Mar 18 07:46:29 2014
       Checksum : 135db02a - correct
         Events : 6


   Device Role : Active device 0
   Array State : A ('A' == active, '.' == missing)

Drive waiting for recovery:

Code: Select all

/# parted -l /dev/sda
Model: Seagate ST2000DM001-9YN1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start   End     Size    File system  Name     Flags
 1      33.6MB  21.5GB  21.5GB               primary
 2      21.5GB  2000GB  1979GB               primary


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-vol1: 17.2GB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  17.2GB  17.2GB  xfs


Model: Linux device-mapper (linear) (dm)
Disk /dev/mapper/md0_vg-BFDlv: 4295MB
Sector size (logical/physical): 512B/512B
Partition Table: loop

Number  Start  End     Size    File system  Flags
 1      0.00B  4295MB  4295MB  ext2


Error: /dev/mtdblock0: unrecognised disk label

Error: /dev/mtdblock1: unrecognised disk label

Error: /dev/mtdblock2: unrecognised disk label

Error: /dev/md0: unrecognised disk label

/# mdadm --examine /dev/sda1
/dev/sda1:
          Magic : a92b4efc
        Version : 0.90.00
           UUID : 014ab0d0:a553a50e:35cf8e80:a58c75ef
  Creation Time : Wed Dec  5 15:01:20 2012
     Raid Level : linear
   Raid Devices : 1
  Total Devices : 1
Preferred Minor : 0

    Update Time : Wed Dec  5 15:01:20 2012
          State : active
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0
       Checksum : cca64e48 - correct
         Events : 1

       Rounding : 64K

      Number   Major   Minor   RaidDevice State
this     0       8        1        0      active sync   /dev/sda1

   0     0       8        1        0      active sync   /dev/sda1

# mdadm --examine /dev/sda2
mdadm: No md superblock detected on /dev/sda2.

The replacement device arrived with the same ST2000DM001 but different PN of 1CH162, while the receiver drive is 9YN164. Does it matter?

I don't think so. The only thing what actually matters is the total number of sectors on that disk. Although it might matter if the new disk has 'advanced format' sectors, and the old doesn't, or vice versa.

Can you post the output of

Code: Select all

parted -l /dev/sda
mdadm --examine /dev/sda1
mdadm --examine /dev/sda2

of both disks?