DRP Disaster recovery Plan y su importancia
Contenidos
Este verano ha sido una experiencia reveladora con dos casos que ilustran perfectamente por qué el mantenimiento de sistemas no es opcional. Como profesional del sector, he vivido en primera persona las consecuencias devastadoras de no invertir en mantenimiento preventivo.
Recientemente gestioné el mantenimiento de un servidor basado en CentOS 7 con cPanel para un cliente al que había explicado y reiterado múltiples veces la necesidad urgente de actualizar un sistema declarado oficialmente obsoleto.
Lamentablemente, existe una tendencia generalizada en el empresariado español de no invertir o no presupuestar gastos relacionados con operaciones de TI, ya sea de software o hardware. Esta mentalidad cortoplacista produce el uso continuado de servidores con versiones o distribuciones obsoletas y sin soporte.
A día de hoy, en España hay miles de sitios web funcionando con:
En este caso particular, mi cliente estaba más que avisado sobre los riesgos. Al final ocurrió lo inevitable: un desastre que requirió restauración completa de la máquina.
Mi cliente mantiene muchos servicios desarrollados por terceros o por el mismo, sin contratos de mantenimiento activos, ya sea porque es difícil venderlos al cliente final o porque este, se niega a pagarlos. Esta situación le obliga a mantener versiones de PHP extremadamente antiguas.
Al intentar la restauración nos encontramos con la primera trampa: cPanel no se instala en distribuciones obsoletas. Las versiones antiguas de PHP y MySQL tampoco están disponibles para instalación en distribuciones modernas.
Cuando intentamos usar JetBackup en modo Recovery, ¡¡nada funcionaba!! porque el servidor de destino no tenía el mismo SO ni la misma versión que el original.
Con 250 cuentas de clientes donde casi el 80% tenía problemas de compatibilidad, cuentas sin tan siquiera, con una base documental legible, la única solución viable fue:
> Nota importante: Estas excepciones MySQL tienen un límite. Llegará un momento en que los parámetros obsoletos no emitirán solo WARNING, sino que causarán FAIL directo.
Lo que debería haber sido una restauración de 24 horas (casi 2TB de información y más de 200 cuentas) se convirtió en casi dos semanas de problemas continuos, requiriendo habilidades avanzadas en sistemas (Level III Sistemas *nix + Programación PHP-JS-MySQL) y CloudLinux para resolver incidentes variados y complejos.
Recientemente me solicitaron crear un plan de recuperación de desastres basado en copias de seguridad, después de que fallara la restauración vía plugin de backup en Proxmox tras un fallo del disco.
Tras un día de trabajo exhaustivo para la creación de un documento de recuperación de desastres vía copias de seguridad nivel sistema + datos, donde incluso los modelos más potentes actualmente de IA (ChatGPT-5, Claude 4.1 Opus) fracasaron estrepitosamente en la creación de un sistema de restauración, opté por un enfoque diferente.
El servidor del cliente ejecuta Ubuntu 20.04 Focal, cuyo período de soporte terminó este año. Como consecuencia, se han desactivado múltiples repositorios críticos:- Repositorio **Ondrej** para **PHP**
Tras múltiples intentos fallidos con scripts de restauración, me di cuenta de mi error: había instalado Ubuntu 24.04 Noble Numbat en el servidor DRP de pruebas, mientras intentaba restaurar desde un backup de Ubuntu 20.04 Focal Fossa.
El problema real emergió al intentar el proceso manual: Problemas con firmas obsoletas, y extraños en la realización de algo que había realizado muchas veces. La realidad, más sencilla era que PHP y otros paquetes críticos ya no estaban disponibles porque la versión Focal está declarada obsoleta en los repositorios de Ondrej, Nginx y MySQL.
Repitamos en castellano: Plan de Recuperación de Desastres.
Sabemos que esto cuesta dinero y requiere:
Es curioso que en España (y el mundo occidental en general) se invierta dinero en:
Pero en el área de sistemas y seguridad, seguimos años luz atrasados.
Seremos nosotros, los responsables de sistemas, externo como yo, o internos, quienes pasaremos horas, días y semanas arreglando desaguisados que otros pudieron haber evitado con inversión preventiva.
Soy consultor externo, y no me gusta cobrar por cobrar. Me gusta la prevención, la organización, y estoy cansado de ser un bombero digital, apagando montes mal gestionados.
El mantenimiento de sistemas no es un gasto, es una inversión en continuidad de negocio. Los casos expuestos demuestran que postergar actualizaciones no ahorra dinero: lo multiplica exponencialmente cuando llega el desastre.
¿Tu organización tiene un plan de mantenimiento de sistemas actualizado? ¿Cuándo fue la última vez que probaste tu plan de recuperación de desastres? El tiempo para actuar es ahora, no cuando el sistema falle.
Estimada empresa: Les escribo para expresar mi profundo descontento con el servicio recibido tras contratar…
En el ecosistema de la lucha contra el spam, Spamhaus es una de las organizaciones…
¡Hola a todos! Vamos a sumergirnos en el fascinante mundo de Mod Security y aprender…
Ya son muchos años en el sector, muchos años pasando por varios paneles de control,…
La lista UCEPROTECT es una herramienta utilizada por muchos administradores de sistemas y proveedores de…
No es la primera vez que me encuentro con el agotamiento de la memoria en…