Wiped my whole hard drive with fdisk /dev/sda

How can i recover all my partitions and data. i meant to do this on my usb /dev/sdb but accidently did in on my main harddrive sda.
I went into: sudo fdisk /dev/sda
then i pressed g for a new gpt partition table
then i pressed n for a new partition
then i confirmed y
and i wrote w
i did not write anything, i did not format the partition, so i think the data is not lost. i only powered off my laptop.
Please help!!!

IIRC 'w' means save, so you did write something.

You can use the testdisk tool to recover the partitions.

yes i typed w to write the changes. i did not format it though.
how do i use testdisk ?

Install and follow the procedure, it's text-based menu driven.
I haven't used it in ages.

Just recovered a drive with wiped partition tables a few hours ago. Here's what I did:

DD usage and recovery procedure for a damaged GPT partition table (not suitable for MBR type disks):

First off, let me state I am not a data recovery expert and this is only my personal recovery method.

The best way to avoid this kind of a problem is to backup your partition tables before an accident occurs.

Unfortunately most people don't keep partition table backups on hand in case disaster strikes

I use the following method to recover a disk that has lost it's GPT partition tables and is unreadable (but the data is hopefully still intact).

The safest way to make any data recovery attempt is to not change anything on the damaged disk you wish to recover the data from.

The recovery drive that contains the copied data is the drive that should be used to perform any partition table manipulations.

Aside from the copy operation itself, the drive with the damaged partition tables should be left untouched.

The surest way to recover all data is to make a sector by sector copy from the damaged drive to a larger size recovery drive.

This can end up being a very time consuming procedure if the damaged drive is many terabytes in size.

The recovery effort could potentially take days depending on the size of drive, dd settings, and the capabilities of your hardware.

If you are in a rush, this is not the method for you.

There is recovery software such as testdisk that you could use to recover your partition tables much quicker than copying your drive in its entirety.

However, if you use testdisk directly on your damaged drive you risk permanently losing the data if something goes wrong.

If your data is critical to you, copying the desired data to a second hard drive first is your best bet for successful data recovery.

Only ever perform recovery operations on the copied data on the recovery drive (not the damaged drive).

The procedure I use to recover a lost partition table is as follows:

You must have a disk at least as large (preferably larger) than the damaged disk to copy all the contents to.

Using a drive that is listed as the same capacity on the label is no guarantee that the copied contents will fit on the recovery drive.

Using a larger drive will ensure you don't waste a ton of time on failed copy attempts to a drive that is a few sectors too small.

I recommend using the command line utility "dd" to copy the damaged disks contents onto a larger disk.

However, if you suspect the drive has bad sectors and may be failing ddrescue may be a better choice.

You must have gptfdisk installed for GPT disk partition table backup and recovery operations.

Use the command "lsblk" to find your devices identificafion, such as sdb, sdc, sdd, etc.

Using sgdisk you can create a binary backup of the protective MBR, the partition table, and the main and backup GPT headers.

Extensive informatjon on GPT Fdisk and sgdisk usage can be found by entering man sgdisk in your terminal, or at:

https://wiki.archlinux.org/index.php/GPT_fdisk

The example below will create a backup partition table for the recovery drive /dev/sdc to the file ~/sgdisk-sdc.bin:

sudo sgdisk -b=sgdisk-sdc.bin /dev/sdc

Once you have backed up your recovery drives partition table, delete the partition from the recovery drive and reboot.

Check that you can restore the partition table on the recovery drive before you begin the copying operation from the damaged drive.

Once you have confirmed you can successfully restore the backup partition table, delete the partition on the recovery drive once again, and reboot.

Before writing the data to the recovery drive it would be best to wipe all the partition table info.

The following command will erase all partitions on the destination disk:

sudo sgdisk --zap-all /dev/sdX

Substitute "c' for "X" in the above command if sdc is your recovery drives designation.


Now we can begin the copying process from the damaged drive to the recovery drive.

We are going to use dd to copy drive /dev/sdX to drive /dev/sdY.

The syntax is simple: if= defines the source drive, and of= defines the location where you want the data copied.

Assuming your damaged drive is sdb and your recovery drive is sdc, you could use any of the following commands:

sudo dd if=/dev/sdb of=/dev/sdc bs=4096 status=progress
sudo dd if=/dev/sdb of=/dev/sdc bs=8192 status=progress
sudo dd if=/dev/sdb of=/dev/sdc bs=1M status=progress

The larger a block size (bs) you allocate the quicker the transfer should complete. Although, if you keep increasing the block size at a certain point it will not gain you any more speed. Using too large a block size may over tax your system's capabilities. If you have older hardware and limited ram it may be best to keep these values lower. Testing throughput is really the only way to know what your hardware's optimal setting should be. I found a setting of bs=4096 to work well on my old hardware without maxing out my 4GB of RAM.

Once all the drive data has been copied to your recovery drive you can attempt to recover your data. Use testdisk to attempt recovery of all the data that should now be copied to the recovery drive. Testdisk usage is well documented, and I would not presume to be an expert in testdisk usage. See the following links for instructions on how to attempt to recover your partition data with testdisk.

https://www.cgsecurity.org/wiki/TestDisk_Step_By_Step

recover data and partitions for free with testdisk

Once you hopefully have recovered your data, backup your partition tables (as shown earlier). Then adjust the partitions to the way you want them on your drive using gparted.

4 Likes

https://www.cgsecurity.org/wiki/TestDisk_DE

be careful, more language on top.

If the only thing you changed was the partition table layout then all you need to do is re-create the old partition table layout.

Therefore, go through the same process again but this time re-create the old partition table layout, then write out to disk w.

Just as a follow up.

I did use testdisk on my original drive with the damaged partition tables just now. The recovery seemed more complicated than the one I performed on the recovered data. The file system was detected incorrectly for some reason on the original drive. I wasn't sure if it would be recovered properly but I wasn't worried because I'd already made a successful recovery on the other drive.

I'm just too much of a nervous Nellie to do the changes on the original drive with 3TB's of data in case something goes wrong. I always want a copy to work on instead of the original.

As I restored both drives to working condition I needed to perform one more operation. If you intend to recover the original damaged disk then you need to alter the new drive's identification numbers. The ID's will conflict if used in the same computer after a drive clone operation is complete. Sgdisk's "-G " option will randomize the disk's GUID and all partitions' unique GUIDs (but not their partition type code GUIDs). This function may be used after cloning a disk in order to render all GUIDs once again unique.

If both drives will be in the same computer afterwards, you should randomize the partition GUID:

sudo sgdisk -G /dev/sdX

Substitute "c' for "X" in the above command if sdc is your recovery drives designation.

2 Likes

@jonathon how do you mean to re-create the old partition table, with fdisk?

@tbg first thing i have to get a hold of another hdd (i dont want to risk it), it will take me a day surely, and then clone it with dd , then i will use test disk. thanks for the long post, very informative!

1 Like

https://wiki.archlinux.org/index.php/GUID_Partition_Table#Recover

If you have done more than just overwrite / damage your existing GPT partition table then file recovery will be required to rescue what you can before re-installing.

https://wiki.archlinux.org/index.php/File_Recovery

1 Like

This needs absolute accuracy AFAIK, which is too difficult if not having old partition "dimensions".

No "real" MBR on GPT drives. Only "fake", which I don't know what is. :stuck_out_tongue_winking_eye:

I suggest testdisk, as well.
Also, because GPT drives keep partiton table backups, you might get them easily (I've never done this on GPT drives, so I just assume...).

Ya I know, but that line is actually a quote from the archwiki.

And, I do agree with you knowing your partitions exact properties is important. In desperation I forced an outdated partition backup to get access to the data I really wanted back. It worked, but there was major data corruption anywhere near the partition boundaries and it was not usable (but I did get the data I wanted).

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.