Recuperación de GPT de una actualización fallida de Mojave

Antecedentes: Mi compañero decidió actualizar su iMac de trabajo a Mojave. Aparentemente, hacia el final del proceso, se colgó en una pantalla negra, dijo que había ocurrido un error y que intentaría recuperarse. Ciclo de este proceso varias veces antes de abortar y pedir restaurar desde una copia de seguridad de la máquina de tiempo o hacer una instalación nueva del sistema operativo.

Al no tener copia de seguridad de Time Machine, optó por la nueva instalación. La primera sugerencia de que algo salió mal con la unidad es que la única opción para instalarla fue su unidad externa (que no es de Time Machine), lo cual hizo. Esto instaló El Capitán, que no es compatible con APFS.

Teoría: Debido a que esta es una unidad Fusion, no se convirtió a APFS hasta ahora. Parte de este proceso debe haber salido mal y ahora el disco es irreconocible. Debido a que el sistema operativo de respaldo que se instaló en la unidad secundaria solo es El Capitán, no es capaz de identificar volúmenes APFS. diskutil mostró dos volúmenes SSD y HDD separados sin un grupo CoreStorage presente.

En mis torpes intentos por solucionar esto, no investigué antes de tiempo para averiguar sobre la conversión de APFS de Mojave. Intenté recrear una partición HFS +, luego ejecuté el Rescate en Disco en eso. Naturalmente, no encontró nada. Me llevé a casa una imagen de la unidad (estúpidamente después de el hecho ...) para intentar ejecutar pruebas forenses, pero como es probable que esté encriptada, parece poco probable que encuentre algo.

Sin embargo, noté lo que parece un encabezado de bloque APFS al principio de la partición:

1+0 records in
1+0 records out
512 bytes copied, 7.4092e-05 s, 6.9 MB/s
00000000  68 4b 56 14 14 fc fd 0c  01 00 00 00 00 00 00 00  |hKV.............|
00000010  04 00 00 00 00 00 00 00  01 00 00 80 00 00 00 00  |................|
00000020  4e 58 53 42 00 10 00 00  ac 45 8d 0e 00 00 00 00  |NXSB.....E......|
00000030  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000040  02 00 00 00 00 00 00 00  64 b8 83 b0 64 92 43 35  |........d...d.C5|
00000050  b9 07 a5 af d1 9d 31 78  06 04 00 00 00 00 00 00  |......1x........|
00000060  05 00 00 00 00 00 00 00  18 01 00 00 5c 6c 00 00  |............\l..|
00000070  01 00 00 00 00 00 00 00  19 01 00 00 00 00 00 00  |................|
00000080  08 00 00 00 0e 00 00 00  06 00 00 00 02 00 00 00  |................|
00000090  0a 00 00 00 04 00 00 00  00 04 00 00 00 00 00 00  |................|
000000a0  93 9a 28 00 00 00 00 00  01 04 00 00 00 00 00 00  |..(.............|
000000b0  00 00 00 00 64 00 00 00  02 04 00 00 00 00 00 00  |....d...........|
000000c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200

Por lo que puedo decir, ac 45 8d 0e 00 00 00 00 indicaría 244,139,436 bloques de 4096 bytes, con un rendimiento de 999,995,129,856 bytes, justo alrededor del tamaño de unidad de 1 TB.

Debido a que la partición todavía tiene algunos encabezados de bloque APFS aparentemente intactos, espero que sea posible sobrescribir el GPT para indicar que trate las particiones como APFS en su lugar.

Veo algunas trampas en esta teoría:

1. Fusion Drive: debido a que se trata de una unidad de fusión, es posible que pueda restaurar la unidad de disco duro por sí misma, pero eso no significa que vaya a ser funcional ...
2. Cifrado: debido a que la facultad requiere que las unidades estén cifradas, es probable que se haya cifrado HFS + antes de la actualización. No sé cómo funciona el cifrado APFS, pero este tipo de procedimiento suena como si pudiera meterse con eso.
3. Sobrescribiendo la tabla de particiones: en mi intento equivocado de recrear las particiones, me pregunto si podría haber hecho las cosas irrecuperables. Incluso si no escribimos nada en las particiones nuevas, seguirá creando el .DS_Store y los archivos relacionados.