¿Por qué se daña una base de datos de contabilidad?
Conviene empezar por entender qué se rompió, porque casi nadie lo tiene claro. Tu programa de contabilidad o ERP es, en realidad, la cara visible de un motor de base de datos que vive por debajo y guarda toda la información en uno o varios archivos. En el mercado latinoamericano ese motor suele ser Firebird —muy común en software contable, con archivos .fdb o .gdb—, Microsoft SQL Server o, en sistemas más sencillos, Access. La corrupción, entonces, no es del «programa de contabilidad»: es del archivo de la base de datos. ¿Y por qué se corrompe? Las causas habituales son un apagado anormal o un corte de energía justo mientras la base escribía, un disco que empieza a fallar —basta con que algunos clústeres defectuosos coincidan con donde la base guarda datos—, un error del software, un disco que se llenó al 100%, o un ransomware que cifró los archivos. Saber esto cambia el enfoque: no buscas «arreglar el programa», sino rescatar y sanar un archivo de datos.
Lo primero: deja de usar el sistema y restaura del respaldo
La reacción instintiva —cerrar y volver a abrir el programa una y otra vez, o seguir trabajando «a ver si aguanta»— es justo la que empeora todo. La regla número uno es detener el sistema y el servidor de la base de datos, porque cada nuevo acceso y cada operación sobre una base dañada solo añade corrupción, nunca la quita. Con el sistema detenido, la mejor salida es también la más simple: restaurar desde un respaldo reciente y probado. Aquí hay una buena noticia que muchos pasan por alto: una parte importante del software de contabilidad genera copias automáticas —a menudo diarias—, así que antes de entrar en pánico vale la pena buscar esas copias en el servidor o en la carpeta del programa. Si encuentras un respaldo del día anterior y es válido, el problema se reduce a perder unas horas de trabajo, no toda tu contabilidad. Por eso un buen respaldo de bases de datos es la diferencia entre un susto y una crisis.
Si no hay respaldo: copia primero, repara después
Cuando no hay copia que restaurar, llega la tentación de bajar la primera herramienta de «reparar base de datos» y lanzarla sobre el archivo. Lo mismo vale para el correo: recuperar un buzón de Exchange o un PST exige copiar antes. Detente un momento, porque el orden importa. Lo primero, siempre, es hacer una copia del archivo original de la base, con el servidor detenido, y guardarla aparte; si la reparación falla o empeora las cosas, esa copia es tu única red de seguridad. Solo después se intenta la reparación con las herramientas propias de cada motor: en Firebird, las utilidades gfix y el ciclo de respaldo y restauración con gbak; en SQL Server, el comando DBCC CHECKDB; en Access, la opción de compactar y reparar. Estas herramientas resuelven muchos casos, pero conviene ser honesto: en archivos muy dañados fallan, y a veces «reparan» a costa de descartar lo que no pueden leer. Si tu caso es un SQL Server que quedó marcado como sospechoso, lo abordamos en detalle en SQL Server en estado SUSPECT.
¿Por qué reparar una base de contabilidad es delicado?
Aquí está el matiz que diferencia una base de contabilidad de cualquier otro archivo, y que pocos advierten a tiempo. Una base de datos no es una bolsa de registros sueltos: es un conjunto de tablas relacionadas que deben mantener integridad y consistencia entre sí. Cuando una reparación es parcial, puede devolverte una base que «abre» pero que por dentro quedó incoherente: claves duplicadas, asientos que no cuadran, saldos que no coinciden con los movimientos. Y ese escenario es más peligroso que la falta de datos, porque podrías seguir operando sobre libros incorrectos sin darte cuenta, con todas las implicaciones contables y fiscales que eso acarrea. Por eso una reparación nunca termina cuando el programa vuelve a abrir: termina cuando se ha verificado la integridad de la información, cruzando saldos y totales para confirmar que la contabilidad es fiable. Recuperar el archivo es la mitad del trabajo; garantizar que los números son correctos es la otra mitad.
¿Cuándo es trabajo de laboratorio?
Hay situaciones en las que insistir por cuenta propia hace más mal que bien. Acude a un laboratorio si el disco donde vive la base hace ruidos, va lentísimo o da errores de lectura: la corrupción puede ser el síntoma de un disco que está muriendo, y forzar el sistema lo acelera; ahí lo correcto es clonar el disco antes que nada. También si hubo un ransomware, porque ese es un problema distinto que requiere su propio manejo, o si la reparación con las herramientas del motor ya falló. Y, sobre todo, si los datos son críticos y no tienes respaldo: la contabilidad de una empresa no es un archivo con el que convenga experimentar. En todos esos casos, un laboratorio clona primero el soporte, trabaja la recuperación sobre la imagen y reconstruye la base sin arriesgar el único ejemplar que te queda. Cuando el origen es un ataque, conviene además leerlo en el contexto de ransomware en Panamá y las pymes.
Recuperar el archivo y los números
Una base de datos de contabilidad dañada asusta porque toca el corazón administrativo de la empresa, pero la mayoría de los casos tienen salida si se actúa con orden: detener, restaurar o copiar, reparar sobre la copia y verificar. Lo que casi nunca perdona es la prisa: seguir operando sobre la base dañada o lanzar reparaciones sobre el original. En Data Recovery Panama recuperamos bases de Firebird, SQL Server y otros motores, y entregamos el archivo abierto y, con él, la verificación de que los datos son consistentes. Y como la mejor recuperación es la que no hace falta, ayudamos a montar un respaldo empresarial que haga de un fallo así una anécdota. Porque el laboratorio que recupera también protege.
Preguntas frecuentes
Porque el programa guarda los datos en un motor de base de datos —a menudo Firebird, SQL Server o Access— y ese archivo puede corromperse. Las causas comunes son un apagado o corte de energía durante una escritura, un disco que empieza a fallar, un error del software o un ransomware. La corrupción ocurre en el motor, no en la aplicación que ves.
Dejar de usar el sistema y detener el servidor de la base, porque cada operación sobre una base dañada provoca más daño. Si tienes un respaldo reciente y probado, restaurarlo es la vía más rápida y segura. Muchos programas de contabilidad generan copias automáticas: búscalas antes de intentar cualquier reparación.
A veces, pero con una regla previa: haz una copia del archivo original antes de tocar nada, por si la reparación falla. Cada motor tiene sus herramientas (gfix y gbak en Firebird, DBCC CHECKDB en SQL Server, compactar y reparar en Access). Pueden funcionar, pero también fallar en archivos muy dañados, así que no trabajes nunca sobre el único ejemplar que tienes.
Porque una reparación parcial puede dejar los registros lógicamente inconsistentes —por ejemplo, claves duplicadas o saldos que no cuadran— y eso es más peligroso que la falta de datos: operarías con libros incorrectos. Por eso, tras cualquier reparación hay que verificar la integridad de la información antes de volver a usarla, sobre todo por las implicaciones contables y fiscales.
Cuando el disco donde vive la base hace ruidos o da errores, cuando hubo un ransomware, cuando la reparación con las herramientas del motor falló, o cuando los datos son críticos y no tienes respaldo. En esos casos conviene clonar primero el disco y trabajar sobre la copia, para no arriesgar el único ejemplar de tu contabilidad.