Corrupted encrypted disk - please help!

The partition map is messed up. It is unlikely that you will be able to recover any data without resorting to third party data recovery software or services. They are expensive and success is far from guaranteed.

Edit: I missed the encrypted part as KiltedTim wrote. Forget any third party data recovery software or service.

You get your data back by erasing the disk, re-installing macOS from recovery mode, and then restoring the data from your backup.

You do have a backup, right?

If you encrypted the disk with filevault, no 3rd party data recovery application or service will be able to recover it. It's gone. That's what backups are for.

What do you get from running these two Terminal commands (Terminal is located in /Applications/Utilities):

diskutil list

diskutil cs list

As far as the drive goes, the First Aid diagnosis says it's a problem with the partition map, which is something that might be able to be fixed. This does not mean that it is fixable, only that it might be. Encrypted drives are core storage drives, so there is a level of abstraction involved that is over and above a normal non-core-storage drive. There are other steps that occur after the partition info verification that might fail even if you do repair the partition table itself, so fixing the partition table issues does not mean you hare home free.

If I were you, and didn't have a backup and the data on the disk is very important to recover, then what I would do would be to get a second model of this WD Elements 25A2 drive (same exact model) and do the same thing you did to the first one (make it an encrypted drive and this is the important part - you have to give it the exact same parameters for partition size and formatting it as you did for the other drive including the partition style (GUID or ???) as those values are crucial to creating the same partition table information on the new drive as the first one had. Once that is done you can can try and do a hex dump on the partition table info and compare that to a hex dump of the partition table info on the corrupted drive and try to determine what is different. That MIGHT allow you past the point of trying to run first aid, but you might also run into corrupted contents of the drive contents, which might make things unrecoverable. I'm not an expert, so perhaps you might consult one and ask them if they think the drive is possibly fixable. John Galt and KiltedTim are very likely correct about the unrecoverable nature of the drive, if the corruption included some of the encrypted contents. But if it only corrupted the partition table, then, it might be something that can be repaired. There is no way to tell however, so what you do next depends on how important recovery is.

This assumes that encrypted volumes have a normal partition table that does not depend on the encryption. If this is not the case then my method suggested above will be pointless. I don't know the answer for certain so perhaps someone else on this forum does?

In any event best of luck...

The output of the "diskutil cs list" command only shows the 499GB Macintosh HD volume, not the 999GB external disk, probably because it's not mounted due to the partition table corruption. But it does show the 999GB drive in the "diskutil list" output as disk2 but does not show the volume name, again I'm guessing due to the the partition table corruption and the internal name not being available.

Since you also posted an output of a previous Disk Utility repair effort under Yosemite, it's not clear which partition it's actually checking since it shows a name of "disk1s3" and then "disk1s2" which don't exist in the output of "diskutil list". I think these "disk0", etc names can change depending on what disk is being booted from, so it's hard sometimes to tell which one is being referred to without other clues like sizes or other info.

There is also a "diskutil cs info diskx" and "diskutil info disk" commands (substitute disk0 or whatever is appropriate for the diskx) and you can get some other information.

I don't think that until you are able to fix the partition table, or at least try to, there isn't much more that can be done, other than gather information you may need in the event you do get it repaired. Best of luck...

Don't think you can copy partition tables from one drive to another, but have to do a bit of research to be sure.

So to make sure I understand which is good and which is bad and how system is configured (please point out any errors):

System has two drives, both are GUID partition schemes composed of:

One 500GB internal drive split into three partitions, first is EFI of 314.6MB, second is 499.3GB and named "Macintosh HD" and is your boot volume and is an encrypted core storage volume, and third is 650MB Recovery partition.

One 1TB external drive split into three partitions, first is EFI of 209.7MB, second is 999.8GB and currently has no name, third is 134.2MB and is named "Boot OS X". This is the problem disk, correct?

Do you have any notes about what exactly you did when you first created the external disk that is now bad? Was it a bootable volume at any time? Since it has a name of "Boot OS X" that is what makes me wonder? But the partition that is named "Boot OS X" is only 134.2MB which makes no sense as OS X needs way more than that. Perhaps this 134.2 number is bogus and a side effect of the corrupted partition table?

Can you explain in as much detail as possible how you created the "bad" disk? Did you originally create just the one partition on it, with the full 1TB maximum, and did you ever run FileVault on it? Please explain as much as you can recall so can understand how to try and reproduce on the new volume.

Remember, there is no guarantee this is gonna work, but will try...that's all I can promise.

Also would like you to do the following so can confirm existing info and get as much additional info as possible before proceeding (don't post images - post the text as images are hard to read sometimes and fuzzy and can't afford any mistakes), and do have the new drive on the system also:

1. Run the "Etrecheck" program and post the report - ask if you want help

downloading program or how to post report

2. Post the output of these Terminal commands:

df -kt

diskutil info disk0

diskutil info disk1

diskutil info disk2

diskutil info disk3

There will be other commands later but need to see the results of this first.

Good luck...

Well, just discovered something that might make this a whole lot easier. "gpt" is a command that deals exclusively with GPT partition tables and has a "recover" mode due to the fact that there is a "backup" copy of the partition table that is maintained by the filesystem at the end of the disk. So please try this: (the -r option prevents anything from being written to disk or opens the drive in read-only mode - but when the real change is attempted the -r option will not be used). Take a look at the wikipedia article at https://en.wikipedia.org/wiki/GUID_Partition_Table for some background information.

Remember if anything goes wrong, this is possible to ruin the entire drive, so this really should be the last resort. By the way, do you happen to have program called DiskWarrior or have a friend who has it? This is exactly the sort of stuff that this program is meant to help solve.

Anyway please do a "man gpt" and read all about it if you have any questions. I've never used it before, and am going by what the man page says as well as an article I found (link is below). If the man page is incorrect, then, there might be problems, but I've typed these commands on my computer to test before writing this reply - but of course "your mileage may vary" as they say, so be very careful and please confirm with your own reading what I attempt to explain.

So, to look at a GPT partition on the /dev/disk2 device (the one having problems) info we use the command - make double sure that this name has not changed (you will be prompted for the admin password):

sudo gpt -r show disk2

And you should get something like (some of your numbers will of course likely be different, but some will be the same):

sudo gpt -r show disk2

Password:

start size index contents

0 1 PMBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

40 409600 1 GPT part - C12A7328-F81F-11D2-BA4B-00A0C93EC93B

409640 936023872 2 GPT part - 48465300-0000-11AA-AA11-00306543ECAC

936433512 1269536 3 GPT part - 426F6F74-0000-11AA-AA11-00306543ECAC

937703048 7

937703055 32 Sec GPT table

937703087 1 Sec GPT header

If you don't want to see the narly hex type codes you can use the "-l" switch to get the partition names/types:

sudo gpt -r show -l disk0

Password:

start size index contents

0 1 PMBR

1 1 Pri GPT header

2 32 Pri GPT table

34 6

40 409600 1 GPT part - "EFI System Partition"

409640 936023872 2 GPT part - "Macintosh 480SSD"

936433512 1269536 3 GPT part - "Recovery HD"

937703048 7

937703055 32 Sec GPT table

937703087 1 Sec GPT header

So, this tells us the primary GPT header starts at block 1, the GPT table (where all the partitions are enumerated) starts at block 2, and the secondary GPT header is the last block on the disk at block 937703087, and the secondary GPT table is at block 937703055.

But before attempting the copy, lets now experiment on the new drive you got and see if we can create it so that it's easier to see what the bad partition table would look like if it were OK. So how do we use Disk Utility to layout the new drive as a GUID type partition with an EFI partition of 209.7MB, a core storage partition of 999.8GB and a third partition of 134.2MB? To know this will need to see what you post as the results of the "sudo got -r show disk2" command (and hope there is no error).

So, if we use the "gpt" command, later on to recover the partition table (overwrite the primary table information with the secondary information), you should be back in business, IF THE SECONDARY PARTITION INFORMATION IS STILL INTACT. I found this article that talks about using "gpt" that you should also look at before proceeding to get a better idea of what someone experienced at http://apple.stackexchange.com/questions/221114/how-to-fix-broken-gpt-guid-and-u nmountable-no-type-volumes

One of the things mentioned in the above link is that they did the mods after booting in recovery mode, but don't think this is needed in this case as the boot volume does not need changing, just your external 1TB drive.

So please read this over and let me know the info you find out. Ask questions and understand the process before doing anything that is not undoable. And don't make any typo mistakes (like leave off -r).

One more thing that just popped out after looking over your last reply...was this bad disk2 drive used as a Time Machine backup or what? The etrecheck report seems to say you have 21 backups on a 1TB drive, most recent backup on April 9, 2017 and oldest on April 7, 2017 (if I read the dates correctly), but that the output from the command "df -kt" shows you have a /Volumes/MobileBackups mounted that is 487GB in size (think this is a result of doing local snapshots on your boot volume to a folder named "/.mobilebackups" ). Please confirm or explain if this is not correct.

Good luck...

Very sorry to hear, it doesn't seems like it gets a format and erase your data but it seems somehow bad sector or some thing blocked to read partition, pls use Wd sync in this link and let us know https://support.wdc.com/downloads.aspx?lang=en

What does the WD sync utility have to do with poster's corrupted partition table? It won't even mount, plus it appears that the WD sync utility is only for the "Cloud" NAS type drives that are attached via ethernet to computers. This is not the situation here I don't think.

Perhaps you left something out? Or you misunderstood the problem or ???

How would the new disk have the same partition info that the old disk has? Did you already copy partition info from bad disk to new disk? Like I already mentioned you really should keep that new disk as new - copying a corrupt partition table to it isn't gonna make this any easier. I would detach both of these WD 25A2 disks and only attach one at a time so that you are certain of which disk you're getting the information from, because at the moment it would appear they are the same, but only one of them has your files that you need to recover. Did you clone the bad to the good or something like that?

When you ran the "diskutil repairDisk disk2" command - look at what it says in the first line "might erase disk2s1" and gives you a chance to abort - but yet you proceeded? Messages like this would give me pause and reluctant to proceed.

And then later on it says that "The volume disk2s2+disk0s2 cannot be repaired when it is in use" -- this tells me that the these two partitions are tied together in a logical core storage volume and you can't repair it unless you reboot in recovery mode and run that command from there (the "diskutil repairDisk disk2") because you can't repair a currently mounted volume that the computer is running the operating system from (the disk0s2 is on your main internal SSD disk). I have no idea if that will even work if you boot into recovery mode, as you run the risk of possibly corrupting your boot volume (since it's now tied together with a partition on the second disk that appears to have a corrupted partition table). I think you need to sever the connection between these two volumes before you try and repair the disk2 external disk - perhaps this severing might even fix the problem with disk2?

How did you get these two tied together in a logical core storage volume to begin with? The answer to that is probably the original source of all your problems - maybe it's OK to do this but I simply don't know. And now the two filesystems are tied together in a way that may have corrupted the disk2s2 volume - perhaps thats why you get the errors you see above. Notice that the repair output you posted on the original post that you ran on Yosemite leaves out this bit of information about "disk2s2+disk0s2" being tied together. No idea how that wouldn't have been noticed. But you've got the encrypted virtual disk1 tied into the physical disk0 in another core-storage volume which is fine. But now all three entities seem to be tied together somehow (internal physical SSD disk0, virtual encrypted disk1 and external physical disk2) and the question becomes how to extract them from each other without loosing anything?

Plus, it turns out you have yet another 1TB backup disk (it is a different disk, right?) from which I assume you could restore everything from. But perhaps you can't do that as there are some things on the corrupted disk2 that are not backed up? Please answer this important question!!!!!

You failed to mention that you've already tried DiskWarrior, and if had known that would not have even started down this path. Maybe you forgot, but you should mention this sort of information as it's just as important knowing what doesn't work as what does. Since you have DiskWarrior, have you contacted their tech support and see if they have any ideas how to fix things?

Maybe it's as simple as separating the two volumes by removing the core storage logical volume that now is tying them together and keeping the encrypted logical volume intact? Maybe the "diskutil repairDisk disk2" or "diskutil repairDisk disk0" will work once the partition info is fixed (it won't until it is fixed according to the man page for diskutil).

And to answer your question about using the link I sent that gave some examples of using got, the answer is no - was just some info to see how someone else has used gpt to query partition info. The problem they were trying to repair had to do with a corrupted Windows partition I think.

Good luck...