Recuperación de Datos de Base de Datos SQL Server Corrupta
La corrupción de una base de datos SQL Server puede manifestarse de formas muy diversas: desde una base de datos marcada como SUSPECT hasta errores 823 o 824 que impiden leer páginas concretas. La clave para una recuperación exitosa es identificar el tipo y extensión de la corrupción con DBCC CHECKDB antes de tomar ninguna acción, y elegir el método de recuperación apropiado para cada escenario.
Estructura de Ficheros SQL Server: MDF, NDF y LDF
Una base de datos SQL Server se compone de tres tipos de ficheros físicos, cada uno con un rol específico:
| Fichero | Extensión | Contenido |
|---|---|---|
| Primary data file | .mdf | Datos principales, system tables, boot page, Page Free Space (PFS), Global Allocation Map (GAM) |
| Secondary data file | .ndf | Datos adicionales, útil para distribuir en múltiples discos o filegroups |
| Log file | .ldf | Transaction log: registro secuencial de todas las transacciones para recuperación ACID |
Internamente, los datos se organizan en páginas de 8 KB, agrupadas en extensiones de 8 páginas (64 KB). La primera página de cada base de datos es la boot page (página 9 del fichero primario), que contiene metadatos críticos de la base de datos. Si esta página se corrompe, SQL Server no puede abrir la base de datos en absoluto.
Cada página de datos tiene una cabecera de 96 bytes que contiene: ID de página (archivo + número de página), LSN (Log Sequence Number) del último cambio, tipo de página, checksum de integridad y nivel de slot count. El checksum se activa con ALTER DATABASE ... SET PAGE_VERIFY CHECKSUM, que es el valor recomendado desde SQL Server 2005.
Errores de Corrupción: 823, 824 y 825
SQL Server tiene tres códigos de error específicos para problemas de integridad de páginas. Conocerlos permite diagnosticar la causa raíz sin necesidad de ejecutar DBCC CHECKDB completo:
- Error 823: El sistema operativo devolvió un error de I/O al intentar leer o escribir una página. Es un error de nivel de SO — el disco no pudo leer el sector. Indica problema de hardware: sectores defectuosos, cable SATA/SAS deteriorado, controladora RAID con problemas o fallo en la SAN. SQL Server no pudo ni siquiera obtener los bytes de la página.
- Error 824: SQL Server leyó la página correctamente desde el disco pero detectó corrupción al validar su checksum o sus metadatos internos. El hardware pudo leer el sector, pero el contenido es incorrecto. Causas: escritura incompleta por corte de alimentación, bit rot (inversión de bits en disco almacenado largo tiempo), bug de firmware en disco o controladora.
- Error 825: SQL Server tuvo que reintentar una operación de I/O hasta 4 veces antes de completarla con éxito. El éxito fue eventual, pero los reintentos indican inestabilidad en el hardware. Es una advertencia temprana de que errores 823 o 824 inminentes son probables. Aparece en el error log de SQL Server Agent y debe tratarse como alerta preventiva.
Los tres errores se registran en el SQL Server error log y en el visor de eventos de Windows. Un buen punto de partida es buscar en el error log con:
EXEC xp_readerrorlog 0, 1, N'823';
EXEC xp_readerrorlog 0, 1, N'824';
EXEC xp_readerrorlog 0, 1, N'825';DBCC CHECKDB: Diagnóstico Completo de Integridad
DBCC CHECKDB es la herramienta de diagnóstico definitiva de SQL Server. Analiza la consistencia de todas las páginas de la base de datos, verifica la integridad de índices, tablas, heap structures y metadatos del catálogo del sistema. Debe ejecutarse antes de cualquier intento de reparación.
DBCC CHECKDB ('NombreBaseDatos') WITH NO_INFOMSGS, ALL_ERRORMSGS;
-- Variante de solo lectura que no adquiere bloqueos de tabla:
DBCC CHECKDB ('NombreBaseDatos') WITH PHYSICAL_ONLY, NO_INFOMSGS;La opción PHYSICAL_ONLY es mucho más rápida (solo verifica checksums y estructura física, no lógica) y es adecuada para verificaciones periódicas. Para diagnóstico completo ante sospecha de corrupción, siempre usar sin PHYSICAL_ONLY.
El output de DBCC CHECKDB clasifica los errores por nivel de gravedad:
- Object Errors: problemas en tablas o índices de usuario — los menos graves
- Allocation Errors: problemas en las estructuras GAM/SGAM/PFS de asignación de espacio
- System Catalog Errors: problemas en tablas del sistema — muy graves, pueden impedir el acceso a la base de datos
- Database Consistency Errors: inconsistencias entre estructuras — los más graves
Las páginas corruptas identificadas quedan registradas en la tabla msdb.dbo.suspect_pages, que SQL Server actualiza automáticamente cuando detecta cualquier error de lectura.
Modo Emergencia y REPAIR_ALLOW_DATA_LOSS: Riesgos y Uso
Cuando una base de datos queda en estado SUSPECT y no existe backup válido, la última opción dentro de SQL Server es la reparación en modo emergencia. Este proceso tiene riesgos significativos que deben entenderse antes de ejecutarlo:
-- Paso 1: Poner la base de datos en modo emergencia (solo lectura)
ALTER DATABASE NombreDB SET EMERGENCY;
ALTER DATABASE NombreDB SET SINGLE_USER;
-- Paso 2: Ejecutar CHECKDB con reparación (DESTRUCTIVO)
DBCC CHECKDB ('NombreDB', REPAIR_ALLOW_DATA_LOSS) WITH NO_INFOMSGS;
-- Paso 3: Volver a multiusuario
ALTER DATABASE NombreDB SET MULTI_USER;REPAIR_ALLOW_DATA_LOSS es, tal como indica su nombre, una opción que permite pérdida de datos. SQL Server puede eliminar filas, páginas completas o incluso tablas enteras para resolver inconsistencias. Es el nivel de reparación más agresivo y debe usarse únicamente cuando:
- No existe ningún backup utilizable
- Se ha hecho una copia exacta de los ficheros .mdf/.ndf/.ldf antes de ejecutarlo
- Se acepta explícitamente la posible pérdida de datos
Antes de recurrir a REPAIR_ALLOW_DATA_LOSS, los especialistas en recuperación de datos pueden extraer información de las páginas legibles directamente de los ficheros .mdf, recuperando significativamente más datos que la reparación automática de SQL Server.
Corrupción del Transaction Log (.ldf): Escenarios y Soluciones
El fichero de log de transacciones (.ldf) registra todas las operaciones de la base de datos y es imprescindible para la recuperación ACID. Su corrupción o pérdida presenta escenarios distintos:
Log corrompido con la base de datos detenida limpiamente (clean shutdown): Si la base de datos se detuvo en un estado consistente (sin transacciones activas), es posible crear un nuevo log desde cero. Esto se hace mediante el proceso de log rebuild, que en versiones modernas de SQL Server requiere modo emergencia. La base de datos puede quedar en un estado funcional.
Log truncado o eliminado accidentalmente: Si el .ldf se borró mientras SQL Server estaba detenido, se puede intentar la recuperación adjuntando solo el .mdf con sp_attach_single_file_db (SQL Server 2014 y anteriores) o mediante CREATE DATABASE ... FOR ATTACH_REBUILD_LOG. El éxito depende de si la base de datos estaba en estado limpio.
Log corrompido con transacciones activas en el momento del fallo: Es la situación más compleja. Las transacciones incompletas no pueden deshacerse sin el log, lo que puede dejar la base de datos en estado inconsistente. En este caso, la recuperación forense de los datafiles (.mdf/.ndf) es la mejor opción para recuperar los datos consistentes.
SQL Server Always On: Recuperación de Grupos de Disponibilidad
SQL Server Always On Availability Groups proporciona alta disponibilidad mediante réplicas sincrónicas o asincrónicas de la base de datos en múltiples nodos. Cuando el grupo de disponibilidad entra en estado NOT SYNCHRONIZING o la base de datos secundaria queda en estado RECOVERY PENDING, la recuperación depende del tipo de fallo:
- Nodo primario caído, secundario sincrónico disponible: el failover automático promueve el secundario sin pérdida de datos. Requiere que el modo de failover esté configurado como automático
- Corrupción en el primario con réplica sincrónica: si la corrupción se repllicó antes de detectarse, ambas réplicas están corruptas. Requiere restauración desde backup
- Corrupción detectada antes de la replicación: si el secondary está íntegro, se puede hacer failover al secundario y reconstruir el primario desde una copia del secundario
- Fallo del listener o del cluster WSFC: requiere diagnóstico del Windows Server Failover Clustering antes de intervenir en SQL Server
Detach/Attach vs Backup/Restore para Migración y Recuperación
En escenarios de recuperación es frecuente necesitar mover una base de datos a otra instancia SQL Server. El método elegido tiene implicaciones importantes:
Backup/Restore es siempre el método recomendado por Microsoft. El backup es un proceso controlado que valida la integridad durante la lectura y crea un fichero portable que puede restaurarse en cualquier instancia compatible. El restore puede hacerse a un punto en el tiempo específico con backups diferenciales y de log.
Detach/Attach mueve los ficheros .mdf/.ndf/.ldf directamente. Es más rápido para bases de datos grandes pero no valida la integridad y requiere que el servicio SQL Server no esté accediendo a los ficheros. Una base de datos en estado SUSPECT no puede hacerse detach de forma normal, aunque se puede copiar los ficheros directamente con SQL Server detenido.
Recuperación Forense de Ficheros MDF: Extracción sin SQL Server
Cuando la instancia SQL Server no puede abrir la base de datos bajo ninguna circunstancia, la recuperación forense directa sobre los ficheros .mdf y .ndf es el camino alternativo. Los ficheros MDF tienen una estructura binária documentada: cada página de 8 KB comienza en un offset calculable, y las filas de datos dentro de cada página siguen el formato de slot array con offsets variables.
Los especialistas en recuperación pueden leer páginas individuales de los ficheros .mdf sin pasar por el motor SQL Server, identificar las páginas legibles de cada tabla y reconstruir los datos en formato exportable (CSV, INSERT scripts, volcado a una nueva base de datos limpia). Este proceso permite recuperar entre el 70% y el 99% de los datos incluso en bases de datos que SQL Server rechaza completamente, dependiendo de la extensión real de la corrupción.
WhatsApp