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.

Last edited by shadowcliffs on Thu Mar 13, 2014 9:59 am, edited 1 time in total.

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.

shadowcliffs wrote: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:

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.

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.

Mijzelf wrote:

shadowcliffs wrote: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:

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.

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 wrote: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 wrote: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.

shadowcliffs wrote: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.