Help - Recover data after partition table overwritten
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Help - Recover data after partition table overwritten
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.
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.
Re: Help - Recover data after partition table overwritten
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)
Connect the target disk (the 'unreadable' disk)
Connect the sourcedisk (your newly installed EZ)
Code: Select all
dd if=/dev/<sourcedisk> of=/tmp/copy_of_partititon_table bs=512 count=2048
Code: Select all
dd if=/tmp/copy_of_partititon_table of=/dev/<targetdisk>
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
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.
Mijzelf wrote: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)Connect the target disk (the 'unreadable' disk)Code: Select all
dd if=/dev/<sourcedisk> of=/tmp/copy_of_partititon_table bs=512 count=2048
Code: Select all
dd if=/tmp/copy_of_partititon_table of=/dev/<targetdisk>
You do not have the required permissions to view the files attached to this post.
Re: Help - Recover data after partition table overwritten
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.
Here you can find directions to mount the logical volumes.
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
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.
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
Mijzelf wrote: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.
Re: Help - Recover data after partition table overwritten
Did you actually try the instructions?
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
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
Mijzelf wrote:Did you actually try the instructions?
Re: Help - Recover data after partition table overwritten
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.
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.
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?
Code: Select all
mdadm main: failed to get exclusive lock on mapfile
Code: Select all
mdadm --assemble /dev/md1 /dev/sda2 --run
If that doesn't work... Is the disk which donated the partition table identical? Same brand, same size?
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
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
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.
Mijzelf wrote: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.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 main: failed to get exclusive lock on mapfile
If that works, repeat the LV instructions to get the internal LV.Code: Select all
mdadm --assemble /dev/md1 /dev/sda2 --run
If that doesn't work... Is the disk which donated the partition table identical? Same brand, same size?
Re: Help - Recover data after partition table overwritten
'That drive'. Which one? The one you are trying to recover now, or the 'donor disk'?shadowcliffs wrote:The only difference is that bad sectors was found on that drive after fw was copied to it and started normally once.
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
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.
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
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.
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:'That drive'. Which one? The one you are trying to recover now, or the 'donor disk'?shadowcliffs wrote:The only difference is that bad sectors was found on that drive after fw was copied to it and started normally once.
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.Code: Select all
mdadm --examine /dev/sda2
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.
Re: Help - Recover data after partition table overwritten
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.
And if indeed the superblock is hurt, we still need a sane one, to know which metadata version to use for a replacement.
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
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.
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)
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
21 GB RAID Array: /dev/md0
2.0TB RAID Array: /dev/md127 (currently missing)
21 GB RAID Array: /dev/md126 (currently missing)
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.
Re: Help - Recover data after partition table overwritten
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?
Can you post the output of
Code: Select all
parted -l /dev/sda
mdadm --examine /dev/sda1
mdadm --examine /dev/sda2
-
- Posts: 21
- Joined: Thu Aug 01, 2013 4:42 am
Re: Help - Recover data after partition table overwritten
Donor (working) drive:
Drive waiting for recovery:
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)
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.
Mijzelf wrote: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?
Can you post the output ofof both disks?Code: Select all
parted -l /dev/sda mdadm --examine /dev/sda1 mdadm --examine /dev/sda2