Son las 8 de la mañana de un lunes. La primera administrativa llega, prende la computadora, abre el sistema de gestión. Error de conexión. Intenta de nuevo. Mismo error. Llama al encargado, que llama al técnico. El técnico llega a las 10:30. El servidor está apagado y, cuando lo enciende, no bootea.
A las 11:30 el diagnóstico es claro: falló el disco principal. Hay backup, pero está en un pendrive que alguien se llevó a su casa el viernes. Mientras se consigue el pendrive, se reemplaza el disco, se restaura y se levanta todo, van a ser las 16 hs. Ocho horas sin facturar, sin atender pedidos, sin imprimir remitos.
Ese día se pierde dinero, se pierde confianza del cliente y, muchas veces, se pierde información que no estaba en el último backup. Lo que se pierde no era inevitable. Lo evitable era escribir un plan antes de que pasara.
Qué es (y qué no es) un plan de continuidad
Un plan de continuidad no es un documento de 40 páginas ni un procedimiento de empresa con sistema 24/7. Para una PyME es un puñado de hojas que responden tres preguntas, antes de que haya un problema.
¿Cuánto aguanta el negocio sin el sistema? Una hora, una jornada, dos días. No es lo mismo una clínica que no puede ver agendas que una empresa que factura a fin de mes. La respuesta cambia qué inversión justifica cada solución.
¿Cómo se vuelve a operar cuando falla algo? Paso por paso: qué equipo se usa, de dónde se recupera la información, quién llama al proveedor, cómo se avisa a empleados y clientes.
¿Quién hace qué, y con qué contraseñas? La falla más común no es técnica: es que la persona que sabe dónde está todo está de licencia, se enfermó o ya no trabaja en la empresa.
Si las tres preguntas se pueden responder en voz alta sin dudar, hay plan. Si no, hay improvisación disfrazada.
Los escenarios que conviene pensar
No hay que escribir una novela. Alcanza con anticipar los tres o cuatro incidentes más probables.
Falla de hardware: se quema un disco, una fuente, un switch, una placa de red. Es el escenario más común y el que mejor se mitiga con redundancia básica (RAID, una fuente adicional, un switch de repuesto en el armario).
Corte de luz o internet prolongado: varias horas sin energía o sin conexión. Una UPS permite guardar y apagar ordenado, pero no sostiene la operación. La pregunta real es qué se puede seguir haciendo sin servidor y sin internet durante medio día.
Ransomware o ataque: un equipo infectado cifra archivos en red. Hoy es tan probable como una falla de disco y tiene un agravante: los backups también pueden quedar cifrados si están en la misma red sin protección.
Pérdida física: incendio, inundación, robo. Poco probable, pero con impacto total. Es el único escenario donde un backup en el mismo edificio no sirve.
Para cada uno conviene pensar cuatro cosas: cómo se detecta temprano, qué se hace en las primeras dos horas, cómo se opera mientras se resuelve y a partir de qué momento se activa un reemplazo definitivo.
El backup no es el plan
Mucha gente piensa que tener backups alcanza. No alcanza. El backup es una pieza del plan, no el plan entero.
Si el backup está en el mismo servidor que falla, no sirve. Si está en un disco externo que nadie saca de la oficina, no sirve contra un incendio ni un robo. Si nadie probó nunca cómo restaurar, el día del incidente se descubre que el backup estaba corrupto desde hace cuatro meses y nadie se enteró.
La regla conocida como 3-2-1 sigue vigente después de veinte años porque cubre los tres tipos de falla: tres copias de los datos, en dos soportes distintos, con una copia fuera del sitio. Disco local, NAS en la oficina y copia cifrada en la nube. O disco local, disco externo que rota semanalmente y copia en un servidor remoto. Las combinaciones cambian; el principio no.
A eso hay que sumar algo que casi siempre falta: probar la restauración. Una vez por trimestre, tomar una carpeta aleatoria del backup y recuperarla en un equipo de prueba. Si sale bien, se duerme mejor. Si falla, mejor enterarse un martes a la tarde que un lunes a las 8.
Lo que conviene tener escrito antes del incidente
Un plan de continuidad mínimo para una PyME incluye cinco cosas:
Un inventario simple de los sistemas críticos (sistema de gestión, correo, archivos compartidos) con el tiempo que cada uno tolera sin funcionar. La ubicación de los backups: qué se respalda, dónde, con qué frecuencia y quién controla que corran. Los contactos del proveedor IT, del proveedor de internet, del proveedor del ERP y el responsable interno que toma decisiones cuando aparece el problema. Las contraseñas críticas en un gestor (Bitwarden, 1Password, KeePassXC), no en un Word ni en un papel, con al menos dos personas con acceso. Un procedimiento de restauración probado, aunque sea en dos carillas.
Con eso, un incidente se resuelve en horas, no en días.
El costo de no tenerlo
La cuenta es simple. Si el negocio pierde cien mil pesos por hora cuando no hay sistema, cinco horas de caída son medio millón. Una caída seria con ransomware puede llevarse una semana. Escribir el plan cuesta algunas horas de consultoría y unas decisiones incómodas que se vienen postergando. No escribirlo cuesta cada vez que algo falla y se resuelve a los gritos.
Los planes aburridos se escriben los días buenos. Un lunes a las 8 de la mañana es un día malo para empezar a decidir dónde está el pendrive.
Si hoy a las 8 se apaga el servidor principal de tu empresa, ¿hay una respuesta clara de quién hace qué, dónde están los datos y cuánto tarda todo en volver? Si la respuesta demora más de un minuto, conviene revisarlo antes de que la pregunta sea en serio.