Una mañana de lunes, la empresa entra en modo incidente: el ERP no responde, el ecommerce sigue recibiendo pedidos y el equipo de operaciones no sabe si debe parar o seguir. Todo el mundo asume que “hay backups”. Nadie tiene claro cuánto tardará la recuperación ni qué sistema debe volver primero.

Tener copias no es lo mismo que poder reanudar la operación.

Esa diferencia parece obvia hasta que ocurre un ransomware, una corrupción de datos o un fallo de proveedor cloud. Entonces aparece la pregunta incómoda: ¿estábamos protegiendo datos o continuidad de negocio?

El problema real no es guardar, es restaurar

Muchas arquitecturas de backup se diseñan para cumplir una casilla: copias diarias, retención de 30 días, almacenamiento fuera del servidor principal. Eso reduce el riesgo de pérdida permanente, pero no resuelve el tiempo de vuelta a la normalidad.

La recuperación falla por motivos muy concretos:

• No se ha probado restaurar un entorno completo, solo archivos sueltos.
• Las dependencias no están documentadas: base de datos, colas, credenciales, DNS, certificados, jobs programados.
• Se ha copiado la información, pero no la configuración.
• El orden de arranque no está definido.
• Nadie sabe qué datos son críticos para volver a facturar primero.

Si una empresa vende online, cobra por suscripciones o depende de atención al cliente, el objetivo no es “recuperar todo algún día”. El objetivo es recuperar primero lo que mantiene el negocio vivo.

Qué debería medirse antes de comprar otra solución

Antes de elegir una herramienta más, conviene responder a estas preguntas:

• ¿Cuál es el RTO real aceptable por sistema? No el teórico, el que la dirección tolera.
• ¿Cuál es el RPO aceptable para pedidos, contabilidad, CRM y documentos?
• ¿Qué sistemas deben restaurarse en secuencia y cuáles pueden esperar?
• ¿Qué dependencias externas romperían una restauración aunque el backup esté intacto?
• ¿Quién valida la integridad de los datos restaurados?

Un buen plan de backup para una pyme no necesita ser sofisticado, pero sí explícito. Debe incluir qué se copia, cada cuánto, dónde se guarda, cómo se cifra, quién puede borrar copias y cómo se prueban las restauraciones.

En la práctica, eso suele significar combinar varias capas:

• Backup inmutable o con protección contra borrado accidental.
• Copia separada por cuenta, región o proveedor cuando el riesgo lo justifica.
• Pruebas periódicas de restauración completas, no solo parciales.
• Versionado y retención alineados con necesidades legales y operativas.
• Un runbook claro para restauración priorizada.

El error incómodo: elegir el backup más barato y llamarlo estrategia

Aquí está la decisión que incomoda: muchas empresas compran backup como si fuera una póliza genérica. Comparan precio por gigabyte y olvidan el coste real de estar parados.

Eso suele llevar a tres errores:

1. Guardar demasiado durante demasiado tiempo sin saber por qué.
2. Confiar en una única capa de protección.
3. No presupuestar pruebas de restauración.

Las pruebas son la parte menos glamourosa y la más valiosa. A menudo descubren fallos que el proveedor no ve: permisos que impiden levantar una base de datos, credenciales caducadas, scripts que dependen de una ruta antigua o integraciones que no vuelven a conectarse después de restaurar.

En algunos casos, la mejor decisión no es mantener todo “siempre listo”, sino definir qué se puede reconstruir desde cero y qué necesita una recuperación rápida. No todo sistema merece el mismo nivel de criticidad.

Mini-caso: cuando el backup existía, pero la empresa no podía volver a operar

En una empresa mediana con ecommerce y logística interna, el equipo tenía copias automáticas en la nube y la sensación de estar cubiertos. El problema apareció al probar una recuperación real: la base de datos volvía, pero los trabajos automáticos, las claves de integración con el transportista y varios permisos de usuario no estaban en el plan.

Resultado: podían “ver datos”, pero no procesar pedidos.

La solución no fue comprar más almacenamiento. Fue rediseñar la continuidad con tres decisiones muy concretas: priorizar servicios, documentar dependencias y ejecutar simulacros de recuperación trimestrales. En menos de dos simulacros, descubrieron fallos que habrían costado horas de facturación y servicio.

Qué señales indican que tu backup no está preparado para un incidente

Hay síntomas fáciles de reconocer:

• Nadie ha hecho una restauración completa en los últimos 90 días.
• El plan de recuperación vive en un documento que nadie consulta.
• No existe orden de prioridades por proceso de negocio.
• Las copias dependen del mismo proveedor o credencial que la producción.
• El equipo asume que “si algún día pasa, ya veremos”.

Si ves dos o más de estas señales, no tienes solo una deuda técnica. Tienes una deuda operativa.

La conclusión es simple: un backup útil no es el que almacena más, sino el que reduce el tiempo y la incertidumbre para volver a operar. Si ese tema está afectando a ERP, ecommerce, cloud o DevOps en tu empresa, en Codefuente solemos empezar por la continuidad real, no por la herramienta.