Broken partitions on drives

English Install/Boot/Login
#1

Edit: This is on an Ubuntu system of which the version is not specified by the OP.

So i was “smart” enough to run the following command:

dd if=/dev/zero of=/dev/sda bs=8k count=10k

And I didnt stop there, I also ran

dd if=/dev/zero of=/dev/sdb bs=8k count=10k

dd if=/dev/zero of=/dev/sdc bs=8k count=10k

84 Mb of writing to the start of the disks

There are a total of 4 drives on my computer.

  1. sda, a 256 GB ssd hosts the boot info and Ubuntu 14.04 OS
  2. sdb, a 512 GB ssd, ntfs formated, data drive
  3. sdc, a 2 TB hdd, ntfs formated, data drive
  4. sdd, a 2 TB hdd, ntfs formated, data drive

If you must know, I got a bit side tracked while testing write speeds of the drives; and i guess i didn’t really understand what I was doing.

So didn’t realise anything at the time and restarted computer and was shown the grub rescue… ofcourse I had ruined all my partiitons tables in the 3 out of 4 drives.

Booted the system with livecd and trying to follow suggestions given in this post.
https://forums.opensuse.org/showthread.php/499894-please-help!-messed-up-boot-sector-dev-sda

sdb is my least important drive as I had just installed it a couple of days ago, so I decided to try recover that first with testdisk.

After a deep search, testdisk kept complaining about things (more info to come on exact details as I run it again) and although at the end a /dev/sdb1 partition was made, I couldn’t mount it.

For now I would greatly appreciate any advice - and i’ll keep updating this post as i try more things with testdisk. Leaving /dev/sdc to last as that is my most previous drive with 1.5Tb of research; half of which is not currently backed up :’(

#2

I have no idea what you are trying to “recover”. But when only data after the 84 Mb addresses are untouched, I would guess that only data from partitions starting after that is recoverable. And as your explanation about what disks with what partions you originaly had is correct, all contain only one partition, and thus they are gone.

BTW, I see only an Ubuntu system mentioned in your explanation about what was on the disks. Where comes the openSUSE 13.2 you post thus under, into play.

#3

Thanks for your reply;

No luck with testdisk for now. It fails to find anything meaningful.

Sorry not using OpenSUSE but saw a post here before on a similar problem and liked the feedback people were giving.

So to bring my drive knowledge up to scratch, typically the information on the folder/file structure is stored at the start of the partition - And therefore if I have written onto the start of it, I have lost it for ever? If so, do ntfs drives automatically keep a backup near the end or somewhere else?

#4

What partitioning? If GPT then yes there are duplicates at the end usually

If you know exactly what partition and the exact sector starts and sops you could rebuild the table. testdisk should allow for that may give clues to where the partitions start and stop.

Note when you do low level partitioning stuff you should always have backup of important data.

#5

Then why are you telling us that you use openSUSE 13.2?
People here are willing to help when they can, but only on the basis of true information.

I will change the prefix of this thread to OTHER VERSION. And add info to yout first thread about it being an Ubuntu system.

#6

Infomtation aboout the files (and thus directories) on a file system are kept in inodes. They are spread all over the filesystem. This is of course about Linux file systems. My knowledge of Microsoft Windows is next to none, thus I can not help you with NTFS.

#7

NTFS stores two copies of the Master File Table to aid recovery in case of corruption (seethis, for instance).
AFAIK the first is near the beginning of a partition, the second often near the middle but its position is up to the system software that created the partition in the first instance. Locations for both files are stored in the boot sector: unfortunately you appear to have wiped that boot sector as well in three of your disks.

testdisk might be able to guess where the second copy of the MFT is recorded and might offer to recover some files, but that is tricky business and generally you should have some prior knowledge of the partitions you are trying to recover, since you might be asked to “educate” testdisk about its guesses. For instance, if the disks were repartitioned during their lifetime, they might still contain old copies of MFTs related to old partitions and testdisk in general is not able to guess which sequence of bits looking like an MFT are indeed related to the actual MFT of the current partition to be recovered.

And testdisk might be able to locate and recover files still existing on the disk, but generally is not able to recreate overwritten files or recover partitions to a “mountable” state after an 80MB damage. That might possibly be done if only the partition tables were destroyed, but files were all still sitting on their original place.

So I think that some files might be recovered from your disks, but this might involve guesses, trial-and-error, a lot of work and a bit of luck.

#8

I have experience formatting and partioning, so I would recommend you use “fdisk” tool. Fisrt of all verify that for each FS that you will be able to port will support the format …

fdisk -u=sectors /device/sdX

Use GParted to check it as well.
Try it!

#9

What information do you guess that fdisk will find in a completely zeroed partition tabel?

#10

Well if the main problem is restore the info, I would recommend i.e.


#Save:
sfdisk -d /dev/sda > partition_table

#Restore:
sfdisk /dev/sda < partition_table

However, the best would be create a signature backup file:


wipefs --all --backup /dev/sdX
dd  if=~/wipefs-sdb-(offset).bak  of=/dev/sdX  seek=XX bs=XX conv=XX

…and avoid risks