Respaldo y continuidad operativa para pymes: qué pasa si se cae tu sistema un lunes

Son las 9 de la mañana de un lunes. El sistema con el que facturas, despachas o atiendes no responde: el servidor murió, alguien borró la tabla equivocada, o el proveedor de la nube tuvo un mal día. La pregunta no es de quién es la culpa — es cuánto rato puede tu empresa seguir funcionando así, y qué pierdes por cada hora. Si no sabes responder eso con un número, esta guía es para ti.

Trabajo con empresas del Biobío y el patrón se repite: la operación depende de un sistema, pero nadie sabe qué pasa el día que falla. Hay "respaldos", sí — pero nadie los probó nunca, o están en el mismo servidor que se cayó. La continuidad operativa no es comprar un disco más grande: es decidir, antes de la emergencia, cuánto puedes perder y cuánto puedes esperar.

Dos preguntas que ordenan todo: RTO y RPO

Toda la conversación de continuidad cabe en dos preguntas. No necesitas la jerga, pero conviene conocerla porque es la que usará cualquier proveedor serio.

¿Cuánto tiempo puedes estar caído? (RTO — Recovery Time Objective). Si tu sistema de despacho se cae, ¿aguantas 5 minutos, 4 horas, dos días? Una distribuidora que factura todo el día no tolera lo mismo que una constructora que liquida a fin de mes. El RTO define cuánto vas a invertir: bajar de "un día" a "cinco minutos" cuesta plata, y solo vale la pena donde el minuto caído duele de verdad.

¿Cuánta información puedes perder? (RPO — Recovery Point Objective). Si recuperas el sistema desde el respaldo de anoche, pierdes todo lo que pasó hoy. ¿Es aceptable perder un día de datos? ¿Una hora? ¿Nada? Esa respuesta define cada cuánto respaldas. Un negocio que toma pocos pedidos grandes quizás tolere perder unas horas; uno con cientos de transacciones diarias, no.

Con esos dos números —uno de tiempo, uno de datos— ya tienes el 80% de la decisión tomada. Todo lo demás (qué herramienta, qué nube, cuánto gastar) sale de ahí.

La regla 3-2-1, sin misterio

La buena práctica de respaldo cabe en tres dígitos: 3 copias de tus datos, en 2 medios distintos, con 1 copia fuera del lugar físico. En la práctica significa: los datos en el sistema, una copia en otro disco o servicio, y una copia en otra ubicación (otra nube, otra ciudad). El error más común que veo es tener "respaldo" en el mismo servidor o la misma oficina: el día que se inunda la bodega, se incendia el rack o un ransomware cifra la red, se va todo junto — original y copia.

Y el segundo error, más silencioso: el respaldo que nunca se restauró. Un backup que no probaste no sabes si sirve. Restaurar de prueba, al menos cada cierto tiempo, es lo que separa la continuidad real del autoengaño. La pregunta de control es simple: ¿cuándo fue la última vez que alguien recuperó un dato desde el respaldo, de verdad? Si la respuesta es "nunca", no tienes respaldo.

Continuidad no es solo datos: son procesos y personas

Recuperar la base de datos es la mitad. La otra mitad es que la gente sepa qué hacer mientras el sistema vuelve. Esto conecta con algo que ya escribí en digitalización de pymes en el Biobío: si la operación vive en la cabeza de una sola persona, ningún respaldo te salva.

Un plan de continuidad mínimo responde, por escrito y antes de la emergencia:

• ¿Quién se entera primero de que algo se cayó, y a quién avisa?
• ¿Cómo seguimos despachando, facturando o atendiendo en modo manual mientras vuelve el sistema? (papel, planilla, lo que sea — pero definido)
• ¿Quién tiene los accesos para restaurar, y qué pasa si esa persona está de vacaciones?
• ¿Cómo recuperamos lo que se hizo a mano cuando el sistema vuelve?

No necesita ser un manual de cien páginas. Una hoja, conocida por el equipo, vale más que un plan perfecto guardado en un cajón.

¿Y la nube me salva de esto?

En parte. Mover tu sistema a la nube —tema que tratamos en migración a la nube para pymes— resuelve la infraestructura física: ya no dependes de un servidor bajo el escritorio que cualquiera puede apagar. Pero la nube no respalda tus datos por ti por defecto, y esa es la confusión más cara que veo.

Dos matices que el vendedor suele omitir: que el servicio "esté disponible" no significa que tus datos estén respaldados —si borras una tabla por error, la nube la borra obedientemente en todas sus copias—; y la responsabilidad es compartida: el proveedor responde por su infraestructura, pero la configuración, los respaldos lógicos y los accesos son tuyos. La nube bien usada mejora muchísimo tu continuidad. Mal entendida, te da una falsa sensación de seguridad.

Un plan realista para una pyme, sin sobre-ingeniería

No necesitas el esquema de un banco. Necesitas algo proporcional a lo que pierdes si paras. Un arranque sensato:

• Semana 1 — Pon números. Define el RTO y el RPO de tu proceso más crítico (el que, si para, para la empresa). Un solo proceso, para empezar.
• Semana 2 — Audita lo que tienes. ¿Existe respaldo? ¿Dónde vive? ¿Cumple 3-2-1? ¿Alguien lo restauró alguna vez?
• Semana 3 — Cierra la brecha más grande. Casi siempre es sacar una copia fuera del sitio y automatizar la frecuencia según tu RPO.
• Semana 4 — Prueba de fuego. Simula una caída y restaura de verdad. Mide cuánto tardaste: ese es tu RTO real, no el que te gustaría.

Lo importante no es el calendario exacto sino la lógica: mide lo que pierdes → revisa lo que tienes → cierra la brecha → prueba que funciona. Repetir esa prueba una o dos veces al año es lo que mantiene el plan vivo.

El costo de no hacerlo

Es fácil postergar esto porque "nunca ha pasado". Pero el cálculo es directo: multiplica lo que factura tu empresa en un día por los días que estarías caído sin un plan, y súmale el costo de reconstruir a mano la información perdida y la confianza del cliente que no atendiste. Para casi cualquier pyme, ese número supera con holgura lo que cuesta montar una continuidad decente. La continuidad operativa no es un gasto de TI: es un seguro que tú mismo administras, y de los más baratos que vas a contratar.