Por qué un backup sin prueba de recuperación es solo una ilusión

=a very tall building in the middle of a city

Tu backup existe. Pero ¿funciona?

Hay una empresa de contabilidad en Buenos Aires que durante tres años creyó tener sus datos respaldados. El sistema hacía el backup todas las noches. El disco externo parpadeaba. Todo parecía en orden.

Cuando necesitaron recuperar archivos de un cliente después de una falla en el servidor, descubrieron que el backup llevaba ocho meses fallando en silencio. Los logs de error iban a una casilla de correo que nadie revisaba. No había nada que restaurar.

Esto no es un caso extremo. En el backup para empresas en Argentina, es más común de lo que parece.


El backup sin prueba es solo un archivo que esperás que funcione

Hacer backup es relativamente fácil. Configurás una tarea, apuntás a un destino, programás un horario. Listo.

El problema es que ahí termina casi todo. Nadie prueba si eso que se guardó se puede restaurar. Nadie verifica cuánto tarda la recuperación. Nadie sabe si el backup incluye realmente los archivos críticos o solo una parte.

El resultado es una sensación de seguridad que no tiene respaldo real —valga la ironía.

Cuando hablamos de continuidad operativa en pymes, el backup es el primer ítem que todos marcan como «resuelto». Y es exactamente ahí donde más problemas encontramos.


Por qué pasa esto en empresas medianas

No es descuido. Es una combinación de factores que vemos repetirse.

Primero: el backup no duele hasta que falla. Durante meses o años funciona correctamente, o aparenta funcionar. No hay señales de alarma. Entonces deja de ser prioridad. Se asume que está bien.

Segundo: hay una sola persona que «sabe». En muchas empresas de 20 a 60 personas, el backup lo configuró alguien hace dos años —a veces un empleado interno, a veces un técnico externo que ya no trabaja con ellos. Nadie más sabe cómo está configurado, qué cubre, ni cómo restaurar algo si ese archivo lo tuviera que abrir otra persona.

Tercero: probar la recuperación se percibe como riesgo. «¿Y si toco algo y lo rompo?» Eso escuchamos. La prueba de restauración se pospone porque genera incertidumbre. Pero esa incertidumbre existe exactamente porque nunca se probó.


Qué significa «probar» un backup

No alcanza con ver que el archivo se copió. Probar un backup significa restaurarlo en un entorno real y verificar que los datos son utilizables.

En términos concretos:

– Tomás un backup de hace 48 horas.
– Lo restaurás en un servidor de prueba o en una máquina aislada.
– Verificás que los datos estén completos y coherentes.
– Medís cuánto tardó el proceso.

Ese último punto importa más de lo que parece. En la recuperación de datos en empresas, el tiempo es el verdadero problema. No es solo si podés recuperar —es cuándo.

Una empresa de logística con la que trabajamos tenía todo bien configurado en papel. Cuando simulamos una restauración completa del servidor, el proceso llevó 11 horas. Para ellos, 11 horas sin sistema operativo era inviable. Rediseñamos el esquema antes de que pasara algo real.


Los escenarios que más se subestiman

Hay tres situaciones que aparecen seguido y para las que el backup convencional no alcanza:

Ransomware. Si el equipo infectado tiene acceso al backup, el ransomware también lo tiene. Vimos casos donde el backup en red quedó cifrado junto con todo lo demás. Sin una copia aislada o con retención de versiones, no hay mucho para restaurar.

Falla silenciosa. El sistema de backup reporta éxito pero los archivos están corruptos o incompletos. Esto pasa más de lo que se cree, especialmente con bases de datos que no se cierran correctamente antes del backup.

Error humano. Un empleado borra una carpeta equivocada o sobreescribe un archivo. Si el backup se hace una vez por día y no se detecta en 24 horas, ya se pisó la versión buena. Acá entra en juego cuántas versiones se retienen y por cuánto tiempo.


Qué hacer con esto

Hay tres cosas concretas que podés implementar, independientemente del tamaño de tu empresa.

1. Programá una prueba de restauración trimestral. No tiene que ser de todo el servidor. Puede ser de una carpeta crítica, de una base de datos, de los archivos de un área específica. Lo importante es hacerlo en condiciones reales y registrar el resultado.

2. Documentá el proceso. ¿Dónde está el backup? ¿Cómo se accede? ¿Cuáles son los pasos para restaurar? Eso no puede vivir solo en la cabeza de una persona. Si esa persona no está el día que falla algo, el backup de nada sirve.

3. Revisá la cobertura real. ¿El backup incluye las bases de datos del sistema de gestión? ¿Los archivos de configuración del servidor? ¿Los correos? No es raro que el backup esté bien configurado para carpetas de documentos y no cubra nada más.


El backup como parte de un sistema, no como tarea aislada

En el Método WIT, el backup no es una casilla que se marca una vez. Es un proceso con verificación, prueba periódica y responsable definido. Cuando entramos como partner de una empresa, una de las primeras cosas que hacemos es auditar el esquema de backup existente —no para decir que está mal, sino para saber realmente cómo está.

El backup para empresas en Argentina muchas veces está configurado, pero no gestionado. Esa diferencia es la que define si, cuando algo falla, tenés con qué levantarte.

Un backup que nunca se probó no es un seguro. Es una esperanza.


Maxi Sandoval
Director · WIT Soluciones Tecnológicas
Conocé el Método WIT

Imagen de Maxi Sandoval

Maxi Sandoval

Director de WIT. Especialista en estrategia tecnologica para empresas medianas y grandes. Acompana a organizaciones en la planificacion, implementacion y gestion de su infraestructura IT.

Creemos que te puede interesar