Recuperación de Datos con MBR, GPT o BIOS/UEFI Dañado
Un disco que no arranca por tener el MBR, GPT o la partición EFI dañados no significa necesariamente que los datos estén perdidos. En la mayoría de casos, el sistema de archivos y los datos permanecen intactos: solo las estructuras de arranque y la tabla de particiones están comprometidas. Saber distinguir ambos escenarios es clave para una recuperación exitosa.
Estructura del MBR: qué hay en el primer sector del disco
El Master Boot Record ocupa exactamente los primeros 512 bytes del disco (sector LBA 0). Su estructura es:
| Bytes | Contenido | Importancia |
|---|---|---|
| 0–445 | Código bootstrap (bootloader stage 1) | Ejecuta el gestor de arranque (GRUB, Windows Boot Manager) |
| 446–509 | Tabla de particiones MBR (4 entradas de 16 bytes) | Define hasta 4 particiones primarias o 3 primarias + 1 extendida |
| 510–511 | Firma de arranque: 0x55 0xAA | El BIOS verifica esta firma para confirmar que es un dispositivo arrancable |
Cada entrada de partición en la tabla MBR contiene: estado (activa/inactiva), tipo de partición (0x07 NTFS, 0x0B FAT32, 0x83 Linux ext4...), LBA de inicio, LBA de fin y tamaño en sectores. Cuando esta tabla se corrompe, el sistema operativo no puede encontrar las particiones, aunque estas y sus datos estén perfectamente intactos.
Estructura del GPT: el sucesor de MBR
GUID Partition Table (GPT), definida por el estándar UEFI, resuelve las limitaciones del MBR (máximo 2 TB por partición, solo 4 particiones primarias). Su diseño es más robusto frente a la corrupción:
- Protective MBR (LBA 0): Contiene una entrada MBR que marca todo el disco como tipo 0xEE (GPT protective), impidiendo que herramientas que no entienden GPT destruyan el disco.
- GPT Header primario (LBA 1): Incluye un UUID del disco, tamaño del header, CRC32 de integridad, localización del array de entradas de partición, y la localización del GPT Header de backup.
- Array de particiones (LBA 2–33): Hasta 128 entradas de partición de 128 bytes cada una. Cada entrada incluye UUID de tipo de partición, UUID único de la partición, LBA de inicio y fin, atributos y nombre Unicode.
- GPT Header de backup (LBA −1, último sector): Cópia exacta del header primario con las referencias invertidas. Permite la reconstrucción completa si el header primario se daña.
- Array de particiones de backup (LBA −33 a −2): Cópia del array de particiones junto al header de backup.
Esta redundancia hace que la corrupción GPT pura sea menos común: si solo se daña el header primario, el backup permite la restauración completa. La corrupción simultánea de ambos headers es posible si un malware o un proceso errado escribe sobre toda la zona de inicio y fin del disco.
MBR dañado vs datos perdidos: diferencias clave
Este es el punto de confusión más frecuente. Un MBR o GPT dañado provoca que el disco no sea arrancable o que las particiones no sean visibles, pero los datos en las particiones están intactos. La corrupción del MBR/GPT no borra ni modifica los datos del sistema de archivos.
Analógicamente: si se arranca el disco como unidad secundaria en otro sistema (o desde un Live USB de Linux), en muchos casos el sistema operativo es capaz de encontrar y montar las particiones usando su propio escaneado de firmas de sistema de archivos, sin depender de la tabla de particiones.
Los síntomas que sugieren corrupción de MBR/GPT y no corrupción de datos:
- El disco arranca con mensaje «Operating System Not Found» o «MBR Error»
- El disco aparece como «No inicializado» en Administración de discos de Windows
- Linux detecta el disco pero no encuentra ninguna partición
- El disco fue formateado con una herramienta que sobrescribió el MBR
Implicaciones de UEFI vs BIOS Legacy en la recuperación
El tipo de firmware de la placa base determina cómo arranca el sistema y, por tanto, qué estructuras son críticas para el arranque:
| Aspecto | BIOS Legacy + MBR | UEFI + GPT |
|---|---|---|
| Sector de arranque | MBR (LBA 0) | GPT Header (LBA 1) + Partición ESP |
| Gestor de arranque | En el MBR y en el VBR de la partición activa | Archivo .efi en la partición EFI System (ESP, FAT32) |
| Límite de tamaño | 2 TB máximo por disco | Sin límite práctico (>8 ZB) |
| Reparación de arranque | bootrec /fixmbr, bootrec /fixboot | bcdboot, bootrec /rebuildbcd, reparación de ESP |
| Impacto de la corrupción | Solo afecta al arranque; datos intactos | Si ESP se corrompe, los datos en otras particiones no se ven afectados |
En sistemas UEFI, la partición EFI System (ESP) es crítica para el arranque pero no contiene datos de usuario. Su corrupción puede repararse recreando la ESP desde el entorno de recuperación de Windows o desde un Live USB Linux con grub-install.
Enfoques de reconstrucción: bootrec vs TestDisk
bootrec /fixmbr (Windows)
Esta herramienta del entorno de recuperación de Windows reescribe únicamente el código bootstrap de los bytes 0-445 del MBR, sin tocar la tabla de particiones (bytes 446-509). Es útil cuando el código de arranque ha sido sobreescrito por malware (algunos virus de sector de arranque), pero la tabla de particiones sigue intacta.
Limitación importante: Si la tabla de particiones también está dañada, bootrec /fixmbr no resuelve el problema. En ese caso hay que reconstruir la tabla de particiones antes de intentar arrancar.
TestDisk
TestDisk es la herramienta de facto para la reconstrucción de tablas de particiones. Su funcionamiento se basa en el escaneado del disco buscando firmas de inicio de sistemas de archivos conocidos (NTFS, FAT32, ext4, HFS+, etc.) para inferir los límites de cada partición. El proceso es no destructivo en modo análisis: no escribe nada hasta que el usuario confirma explicitamente la escritura de la nueva tabla de particiones.
TestDisk es especialmente eficaz cuando:
- Las particiones nunca se han redimensionado tras su creación original
- No ha habido reparticionado después de la corrupción
- El sistema de archivos en la partición tiene sus propias estructuras internas intactas (superbloque, boot sector NTFS)
Cuándo la partición está intacta pero invisible
Hay escenarios en los que la tabla de particiones está intacta pero una partición concreta no es visible o no monta:
- Partición marcada como inactiva/oculta: El byte de atributos de una entrada GPT o MBR puede marcarse como oculto. Algunas herramientas de particionado hacen esto accidentalmente.
- UUID de sistema de archivos duplicado: En Linux, si se clona un disco sin cambiar los UUIDs, el sistema puede montar la partición incorrecta. La original parece «desaparecida».
- Partición extendida MBR dañada: En esquemas MBR con particiones lógicas dentro de una extendida, si la entrada de la partición extendida se corrompe, todas las particiones lógicas dentro de ella desaparecen aunque sus datos estén intactos.
- Superbloque NTFS dañado: NTFS almacena el boot sector tanto al inicio como al final de la partición. Si ambos están dañados, Windows no puede montar la partición aunque la tabla de particiones sea correcta. El MFT puede estar completamente íntegro.
En RecuperaTusDatos.es abordamos cada caso de forma individualizada. La mayoría de corrupciones de MBR, GPT y sector de arranque tienen solución sin pérdida de datos. La clave es no intentar reparaciones a ciegas (especialmente no reinstalar Windows sobre un disco con datos que se quieren recuperar) y trabajar siempre sobre clones del disco original.