Recuperación de bases de datos corruptas para empresas en Panamá

¿Qué es la recuperación de una base de datos corrupta?

Una base de datos no es un archivo más: es un sistema vivo de páginas, índices, registros de transacción y metadatos que tienen que ser coherentes entre sí. Cuando esa coherencia se rompe —porque el disco devolvió una página equivocada, porque el servidor se apagó a media escritura o porque un proceso dañó una estructura interna—, el motor deja de confiar en sus propios datos y bloquea el acceso para no empeorar las cosas. Recuperar la base es devolverla a un estado consistente con la menor pérdida posible.

Conviene decir desde el principio que esto no es lo mismo que recuperar fotos de una memoria. Aquí hay reglas de integridad —las propiedades ACID que el motor defiende por encima de todo— y un orden de trabajo que, si se respeta, recupera mucho, y si se ignora, puede destruir lo que quedaba. Por eso la primera decisión no es qué comando ejecutar, sino en qué orden actuar.

Lo primero, aunque no siempre se quiera oír: restaurar un backup limpio

La vía más segura para recuperar una base corrupta es restaurar una copia de seguridad íntegra. Si tu base aparece en SUSPECT o no abre, vemos qué hacer paso a paso en SQL Server en modo SUSPECT o corrupta. No es la respuesta espectacular que muchos esperan, pero es la que recomienda el propio fabricante: ante errores de consistencia, restaurar desde un backup conocido como bueno es preferible a cualquier reparación. Si además existe el registro de transacciones, se puede llevar la base a un punto en el tiempo concreto —justo antes del incidente— y perder solo los segundos finales en lugar de horas o días.

El problema aparece cuando no hay backup, cuando el backup más reciente también está corrupto o cuando nadie probó nunca restaurarlo y resulta inservible el día que hace falta. Ahí empieza el trabajo de recuperación propiamente dicho, con sus técnicas y sus riesgos. Y ahí es donde la diferencia entre hacerlo con método o improvisar se mide en datos perdidos.

El registro de transacciones: cómo perder lo mínimo

Si hay una pieza que marca la diferencia entre perder horas de trabajo o perder solo segundos, es el registro de transacciones. En SQL Server, una estrategia bien armada combina copias completas, diferenciales y, sobre todo, del log; esa cadena permite restaurar a un punto en el tiempo exacto, por ejemplo el instante anterior a que un proceso dañara los datos. La misma idea existe en otros motores a través de sus registros de cambios: el binary log de MySQL, que se aplica sobre una copia base con las herramientas del propio motor, o el WAL de PostgreSQL. Sin ese registro, la recuperación se limita a la última copia completa, con todo lo que se haya hecho después convertido en pérdida.

De ahí un error que vemos repetirse y que conviene evitar a toda costa: borrar o truncar el log de transacciones «para liberar espacio» en plena crisis. Ese archivo, que parece estorbar, es justo lo que habría permitido recuperar hasta el último minuto. Cuando llega una base dañada, una de las primeras preguntas que hacemos es qué pasó con su registro de transacciones, porque su presencia o ausencia cambia por completo cuánto se puede salvar y define el verdadero objetivo de punto de recuperación del caso.

¿Por qué se corrompe una base de datos?

La intuición dice que la culpa es del motor de base de datos, pero casi nunca lo es. La corrupción se origina, en la gran mayoría de los casos, fuera del motor y en la ruta de entrada/salida: discos con sectores defectuosos, una controladora RAID cuya caché perdió escrituras en un corte de luz, memoria RAM con errores que altera una página antes de grabarla, una SAN o un NAS inestables, drivers desactualizados o una virtualización mal configurada que provoca escrituras a medias. El motor escribe lo correcto; el hardware, por debajo, entrega algo distinto.

Esto tiene una consecuencia práctica que muchos pasan por alto: si se repara la base pero no se resuelve el problema de hardware que la corrompió, la corrupción vuelve. Por eso, antes de tocar la base, miramos el almacenamiento. Y si detrás del síntoma lógico hay un disco o un arreglo dañado, el caso deja de ser solo de base de datos y pasa a ser también de recuperación de servidor y almacenamiento. Arreglar el orden de las causas es la mitad del trabajo.

SQL Server: modo SUSPECT, EMERGENCY y DBCC CHECKDB

En SQL Server, el síntoma más temido es la base marcada como SUSPECT: significa que el proceso de recuperación al arrancar empezó pero no pudo terminar, y la base queda inaccesible. No siempre implica corrupción —a veces es un fichero de log que no se encuentra o un disco lleno—, así que el primer paso es leer el registro de errores de SQL Server y entender qué falló.

Cuando hay que diagnosticar la integridad, la herramienta es DBCC CHECKDB. Verifica la consistencia física y lógica de páginas, índices, estructuras de asignación y catálogos del sistema, y, muy importante, recomienda el nivel mínimo de reparación que cree necesario. La secuencia habitual para una base SUSPECT es ponerla en estado EMERGENCY, pasarla a usuario único y ejecutar CHECKDB para ver el alcance real antes de decidir nada. Las reparaciones hechas en EMERGENCY corren fuera de una transacción de usuario y no se pueden deshacer, de modo que esa fase se trabaja siempre sobre copias.

¿Qué hace —y qué no— REPAIR_ALLOW_DATA_LOSS?

Es la opción que aparece en cada foro como solución mágica, y es justo la que más cuidado exige. REPAIR_ALLOW_DATA_LOSS hace lo que su nombre advierte: para dejar la base consistente, puede eliminar páginas de datos enteras, es decir, puede borrar información de forma definitiva. No es un botón de «arreglar sin consecuencias»; es un bisturí que sacrifica lo dañado para salvar el conjunto. CHECKDB suele recomendar el nivel mínimo, y existe REPAIR_REBUILD, que corrige problemas menores sin pérdida; saltar directamente al de pérdida de datos sin haber agotado las alternativas es un error que vemos a menudo.

La forma responsable de usarlo, cuando no hay más remedio, es sobre una copia física de los ficheros, validando después las relaciones entre tablas —porque tras borrar páginas pueden quedar registros huérfanos sin su clave padre— y comparando totales con lo que el negocio espera. A veces se ejecuta más de una vez, porque al reparar un grupo de errores se destapan otros. Pero si el hardware sigue fallando por debajo, repetir la reparación no termina nunca: vuelve la causa, vuelve el daño.

Errores 824, 823 y compañía: qué te están diciendo

Los números que aparecen en el registro no son ruido; orientan el diagnóstico. El más revelador es el error 824, «error de E/S de consistencia lógica» por checksum incorrecto: dice que la página que se leyó no es la que se grabó, y huele a problema de disco. El 823 y el 825 hablan también de la ruta de E/S y de reintentos de lectura. Los 8905, 2533 y 8928 apuntan a inconsistencias de asignación o a estructuras de índice dañadas. Hay además un caso especialmente duro: la corrupción de la boot page, la única página que guarda los metadatos de toda la base; ni CHECKDB ni un restore de página individual la reparan, y su daño compromete la base entera.

Leer bien estos códigos permite separar lo que es reparable a nivel lógico de lo que exige restaurar o salvar, y, sobre todo, confirma que la causa suele estar en el almacenamiento. Por eso una buena práctica preventiva es configurar alertas para los errores 823, 824 y 825: avisan del problema cuando todavía es pequeño.

Cuando la reparación no basta: salvataje a una base nueva

Hay un camino intermedio, menos conocido y muchas veces mejor que forzar una reparación con pérdida: salvar los datos a una base nueva y limpia. La idea es no pelear con la base enferma, sino extraer de ella todo lo sano. Se genera el script del esquema —tablas, índices, restricciones— para crear una base vacía e íntegra, y luego se exportan los datos tabla a tabla con herramientas como BCP o el asistente de SSIS, saltando las tablas rotas y guardando todo lo demás. Exportar una tabla corrupta puede fallar; cuando pasa, se salta y se sigue con la siguiente, preservando lo recuperable.

Este enfoque tiene una ventaja grande: parte de una base sana de cero, sin arrastrar las cicatrices de una reparación agresiva, y deja claro qué se recuperó y qué no. Es la diferencia entre una base «consistente pero misteriosa» tras un repair y una base nueva con un inventario honesto de lo que contiene.

MySQL e InnoDB: reinicio, redo log y force recovery

En MySQL con InnoDB la lógica cambia de matices. Tras un cierre inesperado, muchas veces el único requisito es reiniciar el servidor: InnoDB lee su redo log, aplica hacia delante los cambios pendientes y revierte las transacciones que estaban a medias, todo de forma automática. Más aún, lo que parece corrupción de páginas a veces es solo la caché de archivos del sistema operativo, y reiniciar el equipo entero resuelve el falso positivo sin tocar nada.

Cuando InnoDB se niega a arrancar por inconsistencias reales, existe innodb_force_recovery, un parámetro con niveles del 1 al 6 pensado únicamente para arrancar en modo restringido y poder volcar las tablas. Aquí el cuidado es máximo: se empieza por el nivel 1 y se sube de uno en uno solo si hace falta, porque los niveles 4 o superiores pueden corromper los ficheros de forma permanente y dejan el motor en solo lectura. La estructura de almacenamiento también importa: con file-per-table —un fichero .ibd por tabla, el comportamiento por defecto desde hace años— se puede trabajar tabla a tabla, mientras que la corrupción del ibdata1, el tablespace del sistema, es bastante más grave porque afecta al diccionario de datos de toda la instancia.

¿Conviene usar innodb_force_recovery por tu cuenta?

Con prudencia y entendiendo el riesgo. Para un volcado rápido con nivel 1 sobre una copia, puede ser razonable. El peligro está en escalar a ciegas: subir a niveles altos sobre los ficheros de producción, sin copia previa, es la forma más rápida de convertir una base recuperable en una pérdida definitiva. La regla que aplicamos es invariable: copias físicas antes de nada, niveles bajos primero, y nunca experimentar sobre el único ejemplar de los datos. Si el volcado se logra con nivel 3 o menos, normalmente solo se pierde lo que había en páginas concretas dañadas; de ahí en adelante, el terreno es resbaladizo.

Otros motores: PostgreSQL, Exchange y el mismo principio

Aunque SQL Server y MySQL concentran la mayoría de los casos que llegan, el principio se repite en todos los motores transaccionales, y eso es lo que importa entender. En PostgreSQL, la recuperación se apoya en el WAL —el registro de escritura anticipada— aplicado sobre una copia base; existen parámetros de último recurso para arrancar saltando páginas dañadas, pero son tan destructivos como sus equivalentes en otros motores y se reservan para cuando ya no queda alternativa. En Microsoft Exchange, la base EDB puede quedar en estado de cierre sucio (dirty shutdown), y la herramienta del fabricante ofrece una recuperación suave que reproduce los registros frente a una reparación dura que descarta lo dañado y, por tanto, puede perder correo.

En los tres casos —y en cualquier otro— el orden que defendemos es el mismo: restaurar una copia limpia si existe, resolver primero el hardware que pudo causar el daño, trabajar siempre sobre copias y dejar las reparaciones destructivas para el final. Cambian los nombres de los comandos; no cambia el criterio. Por eso atendemos también motores menos habituales sin reinventar el método: lo que protege los datos no es una herramienta concreta, sino el orden con que se usan.

Cada motor, su herramienta: una vista rápida

A modo de mapa, así se ven los escenarios más frecuentes por motor. La tabla no sustituye al diagnóstico —cada caso tiene matices—, pero ayuda a ubicar de qué estamos hablando y cuál es el primer movimiento sensato.

El patrón salta a la vista: el primer paso casi nunca es «reparar», sino «poner a salvo y diagnosticar». La reparación, cuando llega, es una decisión informada y no un acto reflejo. Esa disciplina es la que separa una recuperación que devuelve datos consistentes de una intervención apresurada que, por querer resolver en cinco minutos, deja la base en un estado peor que el inicial y reduce lo que todavía se podía rescatar. En recuperación de datos, la prisa mal entendida es cara: casi siempre cuesta más datos de los que ahorra en tiempo.

¿Y si la base de datos vivía en un disco que falló?

Es un escenario que confunde a muchos, porque el síntoma se ve «de base de datos» pero la raíz es física. Si los ficheros de la base están en un disco con sectores defectuosos, en un SSD que empieza a fallar o en un arreglo RAID degradado, no tiene sentido reparar la base sobre un medio que no es fiable: cada lectura puede traer datos distintos y cada escritura puede empeorar el daño. El orden correcto es al revés. Primero estabilizamos y recuperamos el almacenamiento en laboratorio —con las técnicas de recuperación de RAID o de disco según el caso—, obtenemos una imagen fiable de los ficheros, y solo entonces trabajamos la base sobre esa copia sana. Saltarse este orden es la causa número uno de recuperaciones que «no terminan de cuajar».

Nuestro proceso de recuperación de bases de datos

Por encima de las particularidades de cada motor, el método sigue una misma columna vertebral: nunca trabajar sobre el original, entender la causa antes de actuar y preferir siempre la vía con menos pérdida.

1. Asegurar copias y la ruta de E/S

Copias físicas de los ficheros de la base y revisión del almacenamiento: si el disco o el RAID fallan, la corrupción reaparecerá hasta resolver el hardware.

2. Diagnóstico de integridad

Ejecutamos las comprobaciones del motor —DBCC CHECKDB en SQL Server, verificación de InnoDB en MySQL— sin reparar aún, para conocer el alcance y el nivel mínimo necesario.

3. Restaurar backup limpio si existe

Si hay un backup íntegro, restaurarlo es lo más seguro; con registro de transacciones, lo llevamos a un punto en el tiempo justo antes del incidente.

4. Reparar o salvar

Sin backup utilizable, reparamos con criterio sobre copias; si reparar implicaría pérdida, salvamos los datos a una base nueva con su esquema y exportación tabla a tabla.

5. Validar y entregar

Validamos la consistencia lógica y las relaciones, comprobamos la integridad y entregamos, con cadena de custodia cuando el caso lo exige.

DBCC CHECKDB (Ventas) WITH NO_INFOMSGS, ALL_ERRORMSGS
Msg 824: error de E/S de consistencia lógica (checksum incorrecto)
         página (1:47623), archivo 'D:\Data\Ventas.mdf'   # huele a disco
Nivel mínimo de reparación: repair_allow_data_loss   # = posible PÉRDIDA

# Plan, en este orden:
  1) Arreglar el I/O (disco / controladora) ANTES de tocar la base
  2) Restaurar último backup íntegro + log  -> punto en el tiempo
  3) Sin backup: EMERGENCY -> salvar a base nueva (esquema + BCP)
  4) repair_allow_data_loss SOLO como último recurso, sobre copia

Ese registro resume el criterio: el error apunta al disco, el nivel de reparación que sugiere el motor implica pérdida, y por eso el plan empieza por el hardware y por el backup, dejando la reparación destructiva para el final y siempre sobre una copia.

¿Qué no debes hacer con una base de datos corrupta?

Las decisiones de los primeros minutos pesan mucho. Conviene evitar:

• No ejecutes REPAIR_ALLOW_DATA_LOSS «a ver si arregla» sobre la base de producción: puede borrar datos sin vuelta atrás.
• No borres ni muevas el log de transacciones para «liberar espacio»: es la pieza que permite llevar la base a un punto en el tiempo.
• No subas innodb_force_recovery a niveles altos sin una copia previa de los ficheros.
• No sigas escribiendo en una base que ya dio errores de E/S: cada operación puede ampliar el daño.
• No descartes el hardware: si no investigas el disco o el RAID, la corrupción volverá tras la reparación.

¿Cuánto cuesta y cuánto tarda recuperar una base de datos?

Depende del motor, del tamaño, del tipo de corrupción y de si existe un backup aprovechable. Una restauración desde una copia íntegra puede resolverse en poco tiempo; un salvataje a una base nueva con tablas dañadas lleva más, porque hay que exportar, validar y reconstruir relaciones. Por eso, como en todo lo que hacemos, primero diagnosticamos —sin tocar el original— y entonces fijamos por escrito el alcance y el precio antes de empezar. Para una caída que detiene la operación, la línea de emergencia 24/7 arranca de inmediato. No prometemos cifras «desde» sin ver la base, porque en recuperación de bases de datos un número sin diagnóstico es una promesa que no se puede sostener.

La forma de no repetir el susto: respaldo transaccional

Toda recuperación de base de datos termina con la misma conversación: cómo evitar la próxima. Y la respuesta es un respaldo pensado para bases de datos, no una simple copia de ficheros. Un respaldo transaccional —con copias completas, diferenciales y del registro de transacciones— permite restaurar a un punto en el tiempo y convierte un incidente grave en una restauración de minutos. Sumar a eso comprobaciones de integridad programadas y pruebas reales de restauración cierra el círculo: el backup que nunca se probó no es un backup, es una ilusión. Por eso ligamos esta recuperación con el respaldo de bases de datos y, en lo que toca a amenazas, con la defensa frente a ransomware, que hoy ataca primero a las bases y sus copias.

Preguntas frecuentes