4

I'm trying to recover data from a 1TB drive removed from my NAS, but when I run fdisk -lu /dev/sdb I get a message saying that there's no valid partition table.

From what I understand the partition table resides within the first 512 bytes on the disk, so as there's no partition table there at the moment, will I do any damage by writing a new one?

Testdisk has found three partitions, I assume by scanning the sectors on the drive, surely if I write this partition table to disk it will only affect the first 512 bytes? If it turns out they aren't correct, I've lost nothing, all my data is still in tact on the rest of the disk isn't it?

Can I not re-write the partition table as much as I want so long as I don't change anything else on the disk? If I keep blatting the first 512 bytes and then run Testdisk again, it's scan should still find the three original partitions in their original locations on the disk?

I'm reluctant to continue by writing that partition table to disk if it's going to affect the actual data on the disk outside of those first 512 bytes.

Any guidance would be appreciated.

Regards Rich

  • 1
    It is wise that you are reluctant to write to the drive. First, save all files you can get with TestDisk to another drive. After that, feel free to experiment. Wrting a partition table itself should not harm the data. But as the saying goes: "It should work, unless it doesn't" ;) -- If the partition table is wrong, the OS could theoretically damage data by trying to access the affected partitions... – user274116 Dec 11 '13 at 13:01
  • After writing the new partition table perform just read-only operations first (file system check, mount). Only after you are sure that the system sees the file systems correctly (and ideally after full backup) you can switch to read-write mode. – pabouk Dec 11 '13 at 13:15
  • Ok, thanks guys, I think a test in a Virtual Machine might be in order here, I'll post the outcome afterwards before attempting it on the main disk – HuggieRich Dec 11 '13 at 13:40
2

After some brief testing and only with TestDisk and sfdisk in a virtual environment (I can't confirm that creating a new partition table in something like fdisk or gparted would leave it in tact) I'm inclined to say no, writing a partition table won't affect anything other than the first 512 bytes.

Below are the test steps...

I created a 100MB hard drive and partitioned it as follows:

My virtual second drive

I then mounted and added files to each of the partitions before wiping the first 512 bytes

sudo dd if=/dev/zero bs=1 count=512 conv=notrunc of=/dev/sdb

A quick check with fdisk has shown that this has been wiped

richard@mint14 ~/Disktests $ sudo fdisk -lu /dev/sdb

Disk /dev/sdb: 104 MB, 104857600 bytes
255 heads, 63 sectors/track, 12 cylinders, total 204800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

Disk /dev/sdb doesn't contain a valid partition table

So I ran TestDisk against it which successfully found the partitions by scanning the drive and I wrote them to the disk.

After this I dumped the partition table out using sfdisk

richard@mint14 ~/Disktests $ sudo sfdisk -d /dev/sdb > sdb_partitions.out
Warning: extended partition does not start at a cylinder boundary.
DOS and Linux will interpret the contents differently.

richard@mint14 ~/Disktests $ cat sdb_partitions.out 
# partition table of /dev/sdb
unit: sectors

/dev/sdb1 : start=     2048, size=    20480, Id=83, bootable
/dev/sdb2 : start=    22528, size=    61440, Id=83
/dev/sdb3 : start=    83968, size=    61440, Id= 5
/dev/sdb4 : start=   145408, size=    59392, Id= 7
/dev/sdb5 : start=    86016, size=    59392, Id=83

I made a copy of this file and edited it manually to create a single 20MB partition, so one that overlaps the second partition and then wrote it back to the drive

richard@mint14 ~/Disktests $ sudo sfdisk /dev/sdb < sdb_partitions.out_modified
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 12 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an MSDOS signature
 /dev/sdb: unrecognised partition table type
Old situation:
No partitions found
New situation:
Warning: The partition table looks like it was made
  for C/H/S=*/173/42 (instead of 12/255/63).
For this listing I'll assume that geometry.
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1   *      2048     43007      40960  83  Linux
        start: (c,h,s) expected (0,48,33) found (0,32,33)
        end: (c,h,s) expected (5,158,42) found (2,172,42)
/dev/sdb2             0         -          0   0  Empty
/dev/sdb3             0         -          0   0  Empty
/dev/sdb4             0         -          0   0  Empty
Warning: partition 1 does not end at a cylinder boundary
Successfully wrote the new partition table

Re-reading the partition table ...

Another quick check with fdisk shows that it's successfully written this partition table to disk

richard@mint14 ~/Disktests $ sudo fdisk -lu /dev/sdb

Disk /dev/sdb: 104 MB, 104857600 bytes
173 heads, 42 sectors/track, 28 cylinders, total 204800 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048       43007       20480   83  Linux

Finally using sfdisk to replace the original partition table

richard@mint14 ~/Disktests $ sudo sfdisk --force /dev/sdb < sdb_partitions.out 
Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 12 cylinders, 255 heads, 63 sectors/track

sfdisk: ERROR: sector 0 does not have an MSDOS signature
 /dev/sdb: unrecognised partition table type
Old situation:
No partitions found
New situation:
Units = sectors of 512 bytes, counting from 0

   Device Boot    Start       End   #sectors  Id  System
/dev/sdb1   *      2048     22527      20480  83  Linux
/dev/sdb2         22528     83967      61440  83  Linux
/dev/sdb3         83968    145407      61440   5  Extended
/dev/sdb4        145408    204799      59392   7  HPFS/NTFS/exFAT
/dev/sdb5         86016    145407      59392  83  Linux

I then mounted each of these again and verified that the files were there and in tact.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.