Tener backups es importante, pero no significa que tu empresa pueda recuperarse bien ante ransomware.
Un respaldo es una copia. La recuperación es la capacidad real de volver a operar con datos confiables, sistemas limpios, accesos controlados y una ruta de restauración que ya fue probada.
La diferencia parece pequeña hasta que ocurre un incidente.
Qué es un backup
Un backup es una copia de información, configuración o sistema que permite restaurar datos después de una pérdida, error o falla.
Puede incluir:
- bases de datos;
- archivos compartidos;
- máquinas virtuales;
- configuraciones de servidores;
- correo;
- sistemas administrativos;
- aplicaciones críticas;
- almacenamiento cloud.
El backup responde una pregunta básica: ¿existe una copia de lo que necesito?
Pero esa pregunta no basta durante ransomware.
Qué es recuperación
Recuperación es el proceso completo para volver a operar después de un incidente.
Incluye saber:
- qué restaurar primero;
- desde qué fecha restaurar;
- dónde restaurar;
- con qué credenciales;
- qué sistemas dependen de otros;
- qué evidencia debe preservarse;
- qué controles deben validarse antes de reconectar;
- quién aprueba que un servicio vuelva a producción.
La recuperación responde otra pregunta: ¿podemos volver a operar sin reactivar el problema?
Por qué un backup puede fallar en ransomware
Durante ransomware, los respaldos pueden fallar por razones muy concretas:
- la copia también fue cifrada;
- el atacante borró snapshots o retenciones;
- las credenciales de backup estaban comprometidas;
- nunca se probó una restauración completa;
- solo se respaldaron archivos, pero no configuraciones;
- faltan dependencias como bases de datos, llaves, DNS o servicios de identidad;
- el respaldo más reciente ya contiene actividad comprometida;
- el tiempo de restauración es mayor al que la operación puede tolerar.
Por eso conviene tratar backups como parte de continuidad y respuesta, no como una tarea aislada de infraestructura.
RPO y RTO en términos prácticos
Dos conceptos ayudan a aterrizar el riesgo:
RPO define cuánta información puedes perder. Si haces respaldos diarios, podrías perder hasta un día de cambios, según el momento del incidente.
RTO define cuánto tiempo puedes estar detenido. Un respaldo que tarda tres días en restaurarse puede ser insuficiente para un proceso crítico que necesita volver el mismo día.
La pregunta útil no es solo “¿tenemos backup?”, sino:
- Cuánta información podemos perder sin afectar demasiado.
- Cuánto tiempo podemos estar detenidos.
- Qué sistemas deben regresar primero.
- Qué pruebas demuestran que la restauración funciona.
Backup no reemplaza contención
Restaurar sin contener puede devolver sistemas a una red todavía comprometida.
Antes de restaurar, conviene validar:
- cuentas privilegiadas;
- sesiones activas;
- acceso remoto;
- endpoints sospechosos;
- reglas de firewall o VPN;
- alertas de EDR;
- actividad de correo;
- indicadores de movimiento lateral.
La recuperación necesita coordinarse con respuesta a ransomware y gestión de incidentes, no ejecutarse como una restauración técnica aislada.
Backup no reemplaza evidencia
Otra reacción común es borrar, reinstalar y restaurar para volver rápido.
El problema es que esa urgencia puede destruir señales necesarias para entender:
- cómo entró el atacante;
- qué cuentas fueron usadas;
- qué equipos participaron;
- qué datos pudieron verse o extraerse;
- qué controles fallaron;
- qué se debe corregir antes de volver a operar.
Preservar evidencia mínima ayuda a evitar que la empresa repita el mismo incidente después de restaurar.
Qué debe probarse antes de un incidente
Una empresa debería probar al menos estos puntos:
- restauración de archivos críticos;
- restauración de una base de datos;
- recuperación de un servidor o máquina virtual;
- acceso a respaldos con cuentas separadas;
- retención protegida contra borrado accidental o malicioso;
- tiempos reales de restauración;
- dependencia entre sistemas;
- procedimiento de emergencia con responsables.
No todas las pruebas tienen que ser complejas. Una prueba parcial pero real aporta más que una política que nadie ha ejecutado.
Checklist rápido para evaluar tu capacidad
Responde con honestidad:
- ¿Sabes qué sistemas son críticos?
- ¿Sabes cuándo fue la última prueba de restauración?
- ¿Los respaldos están separados de las cuentas administrativas normales?
- ¿Hay retención que no pueda borrarse fácilmente?
- ¿Tienes una lista de sistemas por prioridad de recuperación?
- ¿Sabes cuánto tarda restaurar lo más importante?
- ¿El equipo sabe quién decide durante un incidente?
- ¿La restauración considera red, identidad, aplicaciones y datos?
Si varias respuestas son “no”, el problema no es solo de backups. Es de recuperación.
Cómo puede ayudarte Syscore
Syscore puede ayudarte a revisar respaldos, dependencias, accesos, prioridades de recuperación y playbooks de ransomware.
La meta no es prometer recuperación perfecta. La meta es reducir improvisación, validar controles y dejar una ruta de respuesta más clara antes de que exista presión real.
Preguntas frecuentes
¿Un backup offline resuelve ransomware?
Ayuda mucho, pero no resuelve todo. También necesitas saber qué restaurar, cómo validar integridad, qué cuentas usar, qué sistemas limpiar y cómo evitar reinfección.
¿Cada cuánto se deben probar respaldos?
Depende de criticidad y cambios. Como punto de partida, prueba restauraciones de sistemas críticos de forma periódica y después de cambios relevantes en infraestructura.
¿Qué es más importante: RPO o RTO?
Ambos importan. RPO define pérdida aceptable de datos. RTO define tiempo aceptable de interrupción. La prioridad depende del proceso de negocio.
¿Debo restaurar apenas detecto ransomware?
No sin validar alcance, contención y evidencia mínima. Restaurar demasiado pronto puede reactivar el problema o perder señales necesarias para corregir la causa.