A las 08:12, el servidor que gestiona facturación, inventario y pedidos deja de responder. El equipo de TI confirma que no se trata de una caída de red: los archivos están cifrados y aparece una nota de rescate. Este ejemplo de recuperación de un servidor crítico muestra lo que realmente determina el resultado de un incidente: no solo disponer de una copia de seguridad, sino saber qué restaurar, en qué orden, dónde hacerlo y quién toma cada decisión.
Cuando un servidor crítico se detiene, el impacto se extiende rápido. Ventas no puede confirmar existencias, almacén pierde trazabilidad, finanzas no factura y dirección se queda sin información fiable para decidir. La recuperación ante desastres no es una tarea exclusivamente técnica. Es un proceso de continuidad operativa que debe estar preparado antes de que aparezca la urgencia.
El escenario: ransomware en el servidor de operaciones
Pensemos en una empresa de distribución con 180 equipos y una operación dependiente de un servidor virtual. En ese servidor se ejecutan la base de datos del ERP, las carpetas compartidas de pedidos y un servicio de impresión para etiquetas de almacén. A las 07:50, un usuario abre un archivo adjunto malicioso que consigue credenciales con permisos elevados. El atacante se mueve por la red, cifra el servidor de operaciones y también intenta borrar los respaldos accesibles desde la misma infraestructura.
El primer error habitual sería restaurar inmediatamente la última copia disponible sobre el servidor afectado. Esa acción puede devolver archivos cifrados, reintroducir malware o destruir evidencias necesarias para entender el alcance del incidente. Antes de restaurar, hay que contener.
El responsable de TI aísla el servidor comprometido de la red, deshabilita las cuentas sospechosas y preserva registros de actividad. Al mismo tiempo, informa a dirección de dos datos que importan más que una explicación técnica: qué servicios están detenidos y cuál es la estimación realista para recuperarlos. La comunicación debe ser clara y periódica, sin ocultar incertidumbres ni prometer plazos que aún no se han validado.
Ejemplo de recuperación de un servidor crítico paso a paso
En este caso, la empresa cuenta con respaldos diarios cifrados con AES-256, copias inmutables fuera del entorno de producción y una réplica de máquina virtual preparada para contingencia. También dispone de un inventario de activos donde el servidor de operaciones está clasificado como crítico, con un objetivo de tiempo de recuperación, o RTO, de cuatro horas y un objetivo de punto de recuperación, o RPO, de una hora.
La recuperación se realiza en cinco fases.
1. Contener y delimitar el incidente
El equipo desconecta el servidor afectado y segmenta los equipos relacionados. No se apagan sistemas indiscriminadamente, porque podría perderse información de diagnóstico. Se revisan alertas del EDR, eventos de autenticación, conexiones remotas y cambios recientes en privilegios para comprobar si el atacante alcanzó otros servidores, equipos o repositorios de respaldo.
Esta fase tiene una consecuencia de negocio directa: si el incidente no está contenido, cada minuto de recuperación puede convertirse en una nueva ventana para que el atacante cifre el entorno restaurado. Recuperar rápido importa, pero recuperar en un entorno todavía comprometido aumenta el riesgo.
2. Validar el punto de restauración
No basta con elegir la copia más reciente. El administrador identifica cuándo comenzó el comportamiento anómalo y selecciona un respaldo anterior a esa hora. En este ejemplo, el análisis indica actividad sospechosa desde las 02:40. La copia de las 02:00 parece íntegra, mientras que la de las 03:00 contiene archivos ya alterados.
La diferencia de 40 minutos de datos debe comunicarse al área operativa. Quizá haya que reconstruir manualmente algunos pedidos o movimientos de inventario. Es una pérdida controlada y visible, mucho más manejable que restaurar un sistema contaminado. Aquí se ve por qué el RPO no es un número decorativo: define cuánta información está dispuesta a perder la empresa en un incidente real.
3. Restaurar en un entorno aislado
La máquina virtual no se publica de inmediato en producción. Se restaura primero en una red aislada, sin acceso abierto a usuarios ni a internet. Allí se comprueba la integridad de la base de datos, se analizan los archivos con herramientas de seguridad, se aplican actualizaciones pendientes y se rotan las credenciales de servicio.
También se verifica que las tareas programadas, los accesos administrativos y las integraciones del ERP no contengan mecanismos de persistencia. Un ransomware moderno puede dejar cuentas adicionales, scripts o reglas de ejecución para volver a entrar tras la recuperación. Por eso, una restauración técnica sin revisión de seguridad es incompleta.
4. Recuperar primero los servicios que sostienen la operación
Con la restauración validada, el equipo define el orden de puesta en marcha. Primero se recupera la base de datos del ERP; después, el servicio de pedidos y facturación; por último, los recursos secundarios, como carpetas históricas o servicios de impresión no esenciales. El orden cambia según la empresa. Una fábrica puede priorizar la planificación de producción; una firma de servicios, el sistema de atención a clientes; una clínica, el acceso seguro a información operativa autorizada.
La prioridad debe decidirse antes del incidente y documentarse con las áreas de negocio. Si TI tiene que averiguar en plena crisis qué aplicación es más importante, el tiempo de recuperación se alarga y las decisiones quedan expuestas a la presión del momento.
5. Validar con usuarios y monitorizar el regreso a producción
A las 11:35, el servidor restaurado se incorpora de forma controlada. Un grupo reducido de usuarios valida que se pueden consultar existencias, registrar pedidos, emitir facturas y generar etiquetas. Después se habilita el acceso general. Durante las siguientes horas, el equipo monitoriza eventos de seguridad, rendimiento de la máquina virtual, conexiones privilegiadas y posibles fallos en integraciones.
La recuperación no termina cuando el servidor responde a un ping. Termina cuando los procesos críticos funcionan, los usuarios confirman resultados correctos y el entorno ha vuelto a un nivel de seguridad aceptable. En este caso, la operación principal se recuperó dentro del RTO de cuatro horas, aunque algunos movimientos tuvieron que registrarse de nuevo desde documentos de contingencia.
Lo que este caso revela sobre los respaldos
Muchas organizaciones descubren demasiado tarde que tienen copias de seguridad, pero no una capacidad probada de recuperación. Un respaldo puede fallar por permisos mal configurados, capacidad insuficiente, archivos corruptos, tiempos de descarga demasiado largos o dependencia del mismo dominio comprometido.
La política útil no se mide por el número de copias, sino por su capacidad de restaurarse bajo presión. Una estrategia madura suele combinar copias locales para recuperación rápida, almacenamiento externo o inmutable para resistir ransomware y una ubicación separada para incidentes físicos o fallos mayores. La regla 3-2-1 sigue siendo una referencia válida, siempre que se adapte a la criticidad real de las aplicaciones.
Conviene proteger especialmente los respaldos frente a accesos administrativos. Si una única cuenta puede borrar producción y copias de seguridad, el riesgo está concentrado. La autenticación multifactor, la separación de privilegios, la inmutabilidad y la supervisión de cambios reducen esa exposición.
Qué debe estar decidido antes de una caída
Un plan de recuperación eficaz no es un documento extenso que nadie revisa. Es una secuencia operativa que permite actuar con claridad. Debe identificar propietarios de cada aplicación, dependencias técnicas, contactos de escalado, RTO y RPO aprobados por dirección, y el procedimiento para comunicar el estado del incidente.
También necesita pruebas. Restaurar una carpeta de prueba una vez al año no demuestra que el ERP, sus bases de datos, sus integraciones y sus permisos puedan volver a funcionar. Las pruebas deben simular escenarios razonables: borrado accidental, fallo de almacenamiento, ransomware, indisponibilidad de una sede o pérdida de una máquina virtual.
Hay cinco preguntas que dirección y TI deberían poder responder sin improvisar:
- ¿Qué servidores y aplicaciones detendrían la operación en menos de una hora?
- ¿Cuánto tiempo puede estar caída cada aplicación sin causar un impacto inaceptable?
- ¿Cuántos datos se pueden perder como máximo y quién acepta ese riesgo?
- ¿Dónde están las copias protegidas y quién puede borrarlas o restaurarlas?
- ¿Cuándo fue la última prueba completa de recuperación con usuarios de negocio?
Recuperar es una decisión de negocio respaldada por tecnología
El ejemplo no implica que todas las empresas necesiten la misma arquitectura. Una organización con pocos sistemas puede requerir un esquema de respaldo cifrado y restauración priorizada. Otra, con operaciones continuas, puede necesitar réplica de máquinas virtuales, monitorización 24/7, EDR o MDR y un plan de recuperación ante desastres más exigente. La inversión adecuada depende de la dependencia operativa, el coste de la interrupción y las obligaciones de cada sector.
RealNet trabaja este proceso desde el diagnóstico del entorno hasta las pruebas y revisiones periódicas, porque la continuidad no se resuelve instalando una herramienta y olvidándola. Se construye al conocer los activos críticos, proteger sus copias y ensayar las decisiones antes de que una caída obligue a tomarlas con el negocio detenido.
La pregunta útil no es si su empresa tiene respaldos. Es si, mañana a primera hora, podría demostrar que el servidor que sostiene su operación puede volver a funcionar de forma segura, dentro del tiempo que su negocio realmente puede tolerar.
