¿Qué significa que la base esté en SUSPECT?
El estado de una base de datos SQL Server describe en qué punto de su ciclo está. Cuando ves SUSPECT, significa que el motor intentó recuperar la base al arrancar, pero el proceso no terminó con éxito; como resultado, la base queda inaccesible y las aplicaciones no pueden conectarse. No es el único estado posible: RECOVERY_PENDING indica que ni siquiera pudo iniciar la recuperación —a menudo por falta de un archivo o de recursos—; EMERGENCY es un modo de solo lectura que se fuerza para intentar leer una base dañada; y ONLINE es el estado normal. Puedes consultar el actual con SELECT state_desc FROM sys.databases. Saber en cuál estás es el primer paso, porque cada uno admite acciones distintas y, sobre todo, prohíbe otras.
Lo primero: copia los archivos y no improvises
Antes de buscar comandos en internet, haz lo que de verdad protege tus datos: detén el servicio si hace falta y copia los archivos de la base —el principal .mdf, los secundarios .ndf y el registro .ldf— tal como están, a un lugar seguro. A partir de ahí, cualquier intento se hace sobre las copias, no sobre los originales. Esto importa porque muchos de los caminos «rápidos» que circulan por foros escriben sobre la base y, si salen mal, dejan el caso peor que al principio. Dos errores frecuentes que conviene evitar: reiniciar el servicio de SQL Server una y otra vez con la esperanza de que «se arregle solo» —cada arranque puede consolidar la corrupción— y hacer un detach de una base en SUSPECT, porque luego puede negarse a volver a adjuntarse. Con una copia a salvo, tienes margen para equivocarte; sin ella, no.
La vía más segura: restaurar desde una copia válida
Si tienes una copia de seguridad reciente y verificada, ya tienes la mejor salida. Restaurar desde un respaldo bueno devuelve la base a su estado anterior a la corrupción sin arriesgar la integridad de los datos ni las relaciones entre objetos; es, con diferencia, lo que menos riesgo tiene y lo que Microsoft recomienda en primer lugar. La condición es que la copia sea válida: un .bak que también está corrupto, o uno tan viejo que perdiste medio día de operación, cambia el cálculo. Por eso un respaldo no comprobado no cuenta como respaldo; lo desarrollamos en por qué un backup que no se prueba no es un backup. Si manejas bases de datos críticas, la conversación importante no es cómo repararlas tras el desastre, sino cómo respaldarlas y probar la restauración antes, algo que cubre nuestro servicio de respaldo de bases de datos.
¿Qué hago si no tengo copia de seguridad?
Aquí es donde la tentación de «arreglarlo ya» causa más daño. Sin copia, el camino correcto empieza por un diagnóstico: con la base en un estado que lo permita, se ejecuta DBCC CHECKDB para conocer el alcance real de la corrupción. A partir de ahí hay opciones que no destruyen nada —poner la base en modo EMERGENCY para leerla y exportar lo que se pueda, o usar herramientas especializadas que extraen los datos de los .mdf/.ndf trabajando sobre una copia sin tocar el original—. Lo que no se hace a la ligera es ejecutar DBCC CHECKDB con REPAIR_ALLOW_DATA_LOSS: la propia Microsoft advierte que esa opción puede causar más pérdida de datos que restaurar desde una buena copia, porque elimina lo que no puede reparar para devolver consistencia. No es un botón mágico, sino un intercambio: cambia datos por estructura. Si la información es crítica, ese paso lo da un DBA con criterio, sobre una copia, y solo cuando se agotaron las demás vías.
¿Por qué importa de dónde viene la corrupción?
Una base no se corrompe porque sí. Las causas habituales y los pasos generales los vemos en base de datos de contabilidad dañada. Las causas habituales son cortes eléctricos durante una escritura, el disco lleno, un apagado forzado, el borrado o daño del archivo de registro (.ldf), y —la que más nos llega a un laboratorio— fallos de hardware: errores de E/S que SQL Server reporta como 823, 824 o 825 y que casi siempre delatan un disco o un RAID enfermo. Esta distinción es decisiva. Si la corrupción nace de un almacenamiento que falla, reparar la base una y otra vez es tratar el síntoma: el disco seguirá corrompiéndola, y cada intento sobre un disco moribundo lo acerca al fallo total. En esos casos el orden correcto se invierte: primero se recupera a nivel de almacenamiento —se clona o se imagina el RAID o el disco afectado—, y solo después se trabaja la base de datos sobre una imagen sana. Confundir un problema de base con un problema de disco es uno de los errores más caros que vemos.
Contabilidad y aplicaciones de negocio sobre SQL
Vale la pena recordar que muchas aplicaciones críticas de una empresa viven sobre una base de datos SQL Server sin que el usuario lo note: sistemas contables, ERP, software de facturación, puntos de venta. Cuando uno de ellos «no abre», «no conecta» o muestra errores de base de datos, debajo suele haber exactamente este problema. Las reglas son las mismas: no improvises, copia los archivos, busca la copia de seguridad y, si el proveedor del software no puede ayudarte, trata el caso como lo que es —una recuperación de base de datos— antes de que alguien intente «repararlo» y empeore el cuadro. Para una empresa, cada hora con el sistema contable o el ERP caído es tiempo de operación perdido, así que la rapidez con cabeza vale más que la rapidez a secas.
Cuándo llamar a un especialista
Conviene pasar el caso a manos expertas cuando: no hay copia de seguridad válida y la información es crítica; la copia existe pero el .bak también está dañado; la corrupción reaparece una y otra vez (señal de hardware); hay errores 823/824/825 o ruidos en los discos; la base quedó en SUSPECT tras un corte o un fallo del servidor; o sospechas que un ataque de ransomware tocó los archivos. En todos esos casos, lo que más datos salva es no seguir probando comandos sobre el original. En Data Recovery Panama abordamos las dos capas del problema: recuperamos el almacenamiento cuando el disco o el RAID es la causa, y trabajamos los archivos de la base sobre copias, sin arriesgar el original. Si no estás seguro de en qué punto está tu caso, cuéntanoslo en recuperación de datos antes de dar el siguiente paso.
Preguntas frecuentes
Significa que el proceso de recuperación de la base se inició pero no terminó con éxito, así que la base queda inaccesible: las aplicaciones no pueden conectarse. Suele deberse a corrupción del archivo de datos o del registro (.mdf/.ldf), a un corte eléctrico o a un problema de disco. Puedes ver el estado con SELECT state_desc FROM sys.databases.
Restaurar desde una copia de seguridad reciente y válida. Es lo que recomienda Microsoft y lo que menos riesgo de pérdida tiene. Antes de cualquier intento, copia los archivos .mdf, .ndf y .ldf tal como están y trabaja sobre las copias. Las reparaciones que pueden perder datos son el último recurso, no el primero.
Solo como último recurso y, idealmente, en manos de un DBA y sobre una copia. La propia Microsoft advierte que REPAIR_ALLOW_DATA_LOSS puede provocar más pérdida de datos que restaurar desde una buena copia, porque elimina lo que no puede reparar. No es un botón mágico: cambia consistencia por datos. Si los datos son críticos, primero agota la vía de la copia de seguridad.
No necesariamente. Aun sin copia, a menudo se puede extraer la información de los archivos .mdf y .ndf con herramientas especializadas que trabajan sobre una copia sin tocar el original, o poniendo la base en modo EMERGENCY para leerla. Lo importante es no ejecutar reparaciones destructivas a ciegas sobre el único archivo que tienes.
La corrupción recurrente casi siempre apunta a un problema de hardware debajo: un disco con sectores defectuosos, un RAID degradado o una controladora que falla. Reparar la base una y otra vez no resuelve la causa. Hay que revisar el almacenamiento; si un disco está fallando, primero se recupera a nivel de disco y luego se trabaja la base sobre una imagen sana.