Macos – External HDD (3TB) corrupted – possibly partition table damaged

data-recoveryhard drivelaciemacospartitioning

I've got a LaCie HDD (3TB) which I cannot mount because there seem to be issues with the partition table, according to disk utility. I'm on a mac (Sierra, up to date). Disk utility can't repair it, but it lists the hdd. When trying to repair, disk utility says: "Repairing damaged partition table. Operation can't be completed (com.apple.DiskManagement error -69874.) Operation failed…"

In Disk Utility it's listed as:
ST3000DM 001-1CH166 Media, 3TB, not initialized
Location: external
Connection: USB
Partition-table: not supported
SMART-status: not supported
Capacity: 3TB
Number of sub-partitions: 0
Type: Disk. Device: disk2

The disk itself is formatted as Mac Journaled (GUID). My other HDD's have 2 partitions (according to testdisk the damaged disk has a Linux [L] & LBA [E] partition). Tried quick search and deep search on testdisk (it said something like filesystem was OK, partition table damaged. Don't know exactly though).
Used testdisk to write a partition table, but that didn't change anything. Am hesitant to just press some options on testdisk, since I don't want to damage my files further and don't know what all those options do.

The disk has data on it that I really need (when I found out it was corrupted, I just wanted to back the data up to another HDD.. ironic isn't it?), so it would be great if I could retrieve it. The files on it are mainly .PNG, .JPEG, .PSD and .CR2, some video formats and older/mobile image formats too. Think there's a time machine backup on it too.

What should I do? Is there another option with teskdisk, or photorec?

PS: Yes, I know, back-up back-up back-up.
PPS: I've tried contacting specialized businesses but those services are way to expensive for a student like me. Currently a demo of Data Rescue 4 is running to check what can be recovered, but heard that software like that can't give you back files like .psd, and since it's kind of expensive too I'm kind of hesitant to pay this much for something if it can't restore most of my files.

Testdisk wrote a new partition table after analyzing, as well as GParted, but both of those didn't work. Heard about photorec, but would it give me back all the files I have, or only files with specific extensions?

Best Answer

We fixed it. This is in no way a canonical answer, but it may contain helpful information for future visitors.

Everybody had been suggesting to analyse the disk with testdisk.

What analyse does:

Analyzes a drive's current partition structure and finds partitions, making it possible to recover lost partitions.

The problem in our case was not that we were missing partitions, but that the partitions that were there could not be accessed.

We both didn't know anything about data recovery, partition tables, etc. so we started researching and came to a conclusion that there was not something wrong with the partitions, but with the way that they are "indexed" on the disk. We thought this was managed by the partition table.

We have analysed the disk with testdisk multiple times, with different options for the partition table type (we didn't know the type originally, but at the end it turned out to be EFI GPT), hoping that testdisk would be able to find some issues with the partition table that it could restore so that we might be able to access the data again. We let it rewrite the partition table after analysing several times, but it never helped.

Prior to trying different potential solutions we didn't know of yet, we decided not to take any risks and bought a new 3TB hdd and cloned the old one onto this.

A strange thing that we noticed was that when we analysed the clone, testdisk only took about a second to display the results, whereas with the old one it would take many many hours. It would also say that it detected the partition table type to be EFI GPT. The old one had been detected as Linux and at least one other type, but not EFI GPT.

This made us think that it was very possible that there was something wrong with the original disk that was hardware related. We thought How can a clone behave differently from the original if there is not?

So everything appeared to be correct, but this new disk could not be mounted either. It would say

wrong fs type, bad option, bad superblock on /dev/sdb,  
missing codepage or helper program, or other error  
In some cases useful info is found in syslog - try  
dmesg | tail  or so

and dmesg would say

hfs: unable to find HFS+ superblock

This error has been reported left and right, even here on SU, but none of the proposed solutions (e.g. "specify the size and offset while mounting") worked for us.

While looking for clues we found an option in testdisk's advanced menu called "Superblock" or something similar.

In this menu, there are options to compare the superblock structure to the backup, and to overwrite the backup. First thing we did was to compare the two to see if they were the same.

There was no data in the backup. The hex dump showed only zeroes. We figured what could go wrong by overwriting a bunch of nothing, and let testdisk overwrite the backup structure. It did so and told us to reboot for changes to take effect.

After the reboot, ubuntu showed the disk in the launcher (first time it did that) and when clicking on it, it would mount successfully, allowing us to read the data. ☺

Sidenote, as pointed out in the comments:

What many people do not know is that you should NEVER try and restore files to the same drive! Never. Always clone the disk first. More correctly: NEVER WRITE TO the disk you're trying to recover data from.

Related Question