Contenidos
Una reflexión para responsables de sistemas, CTOs, directores de producto y administradores con responsabilidad sobre la infraestructura crítica.
Introducción
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.
Caso 1: Desastre en Servidor cPanel con CentOS 7
El Contexto del Problema
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.
La Realidad del Panorama Español
A día de hoy, en España hay miles de sitios web funcionando con:
- PHP 5.4, 5.6, 7.0, 7.2
- Distribuciones CentOS sin soporte
- Versiones Ubuntu fuera de mantenimiento
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.
El Problema del Software Legacy
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.
Cuando llega el desastre: la trampa de la restauración
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.
Opinión
Esto ya supone de entrada 2 horas perdidas.La Solución de Emergencia
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:
- Instalar CloudLinux para permitir versiones antiguas de PHP
- Configurar excepciones en MySQL para soportar sintaxis obsoleta
- Realizar recuperación cuenta por cuenta, sin modo Recovery automático
> 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.
El coste real del descuido
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.
Caso 2: Plan de Recuperación de Desastres sin Panel
El Nuevo reto
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.
El proceso fallido incluso con soporte IA
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 Problema Subyacente
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**
- Repositorio Ondrej para Nginx y para PHP
- PostgreSQL
- Y varios más
Mi Error de Análisis
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.
Lecciones Aprendidas y Recomendaciones
Para Responsables de Sistemas
- El software DEBE actualizarse regularmente
- Clientes con software obsoleto = riesgo para todos: Considera moverlos a servidores aislados
- Sistema obsoleto = sistema vulnerable: Los riesgos de seguridad se multiplican exponencialmente
- Los backups fallan sin mantenimiento: Un sistema obsoleto anula la eficacia de las copias de seguridad
Protocolo de Testing DRP (Disaster Recovery Plan) Obligatorio
Repitamos en castellano: Plan de Recuperación de Desastres.
- Test inicial: Siempre al implementar
- Testing semestral: Mínimo anual, preferible cada 6 meses
- Test post-cambios: Tras cualquier actualización de software o sistema
- Plan estructurado: No es «un backup», sino un conjunto de procedimientos duplicados y verificados
La Inversión Necesaria
Sabemos que esto cuesta dinero y requiere:
- Eficacia operacional
- Organización dispuesta a invertir en mantenimiento
- Planificación a medio y largo plazo
- Capacidad de venta del producto necesario: mantenimiento
Reflexión Final: El Contraste Español
Es curioso que en España (y el mundo occidental en general) se invierta dinero en:
- Seguros y mantenimiento de edificios y maquinaria
- Oficinas elegantes y mobiliario moderno
- Espacios de trabajo «cool»
Pero en el área de sistemas y seguridad, seguimos años luz atrasados.
Opinión
Hablamos de metodologías ágiles, Scrum of Scrums, SAFe, DevSecOps, GitOps, arquitecturas cloud-native serverless, service mesh, observability, chaos engineering, platform engineering… pero olvidamos lo básico de la ingeniería de sistemas.Cuando el desastre ocurre
- Lloran los clientes
- Lloran los de marketing y relaciones con el cliente
- Lloran los responsables de sistemas
- Lloramos los administradores que estamos en la última parte del escalafón
- Se muere un pajarito…
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.
Conclusión
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.
Reflexión
La pregunta no es si puedes permitirte actualizar tus sistemas. La pregunta es si puedes permitirte NO hacerlo.¿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.