Mantenimiento de servidores: un plan operativo para actualizaciones, copias y recuperación real

Cada tarea necesita un rol responsable

Un servidor puede estar supervisado técnicamente y aun así permanecer caído durante horas si nadie responde a la alerta. Por eso, el plan operativo empieza por las aplicaciones, los contactos y el horario empresarial. Registre quién atiende técnicamente un incidente, quién decide su prioridad y quién da la aceptación de negocio al servicio restaurado. Los sustitutos deben poder acceder a la misma información necesaria.

Una persona puede asumir varios roles. Lo importante es que ninguno quede sin asignar. Con un proveedor de servicios, acuerde por escrito las responsabilidades y la disponibilidad. Un tiempo de respuesta prometido significa inicialmente que comienza el trabajo; no garantiza automáticamente que la aplicación esté completamente restaurada dentro de ese mismo plazo. Separe estos objetivos en la especificación del servicio.

Un ritmo de mantenimiento con una finalidad justificada

El siguiente plan es nuestra plantilla inicial para un entorno pequeño. No es una norma universal. La frecuencia y la urgencia dependen del negocio, la exposición del sistema, los avisos del fabricante y los objetivos de recuperación acordados. La información crítica nueva se atiende fuera de las ventanas rutinarias cuando es necesario.

Para una aplicación con un objetivo de recuperación muy ajustado, una prueba trimestral puede ser demasiado infrecuente. A la inversa, no toda pequeña aplicación auxiliar sin cambios necesita una reconstrucción completa mensual. Elija el alcance según el riesgo y modifíquelo después de fallos, actualizaciones importantes o un cambio en las copias de seguridad. Un calendario rígido no sustituye una evaluación informada.

Las actualizaciones terminan con una comprobación funcional

NIST describe la gestión de parches como identificar, priorizar, obtener, instalar y verificar actualizaciones. La guía la clasifica como mantenimiento preventivo. En la práctica, una actualización solo está completa cuando se han comprobado la instalación y el servicio necesario. NIST SP 800-40 Rev. 4: Planificación de la gestión de parches ↗

Antes de la ventana, aclare dependencias, avisos del fabricante, copias de seguridad disponibles y vía de reversión. Para aplicaciones importantes, pruebe primero el cambio en un entorno de pruebas adecuado. El equipo define cuánto esperar a una actualización satisfactoria y cuándo pasar a la reversión preparada. Un esquema de base de datos puede no ser reversible simplemente restaurando un archivo del programa.

• Antes: documentar servicios afectados, aprobación, estado de las copias e interrupción prevista.
• Durante: registrar cambios y desviaciones sin abrir varias líneas de trabajo imprevistas a la vez.
• Después: comprobar inicio de sesión, función principal de negocio, trabajos en segundo plano, conexión con la base de datos y supervisión.
• Finalización: registrar versiones nuevas, confirmar los reinicios necesarios y asignar los fallos pendientes.

Planifique las copias de seguridad partiendo hacia atrás del objetivo de recuperación

RPO es el objetivo de pérdida de datos tolerada, expresado como intervalo temporal. RTO es el objetivo de duración de la recuperación. Si no pueden perderse más de 30 minutos de pedidos, una copia diaria por sí sola no puede cumplir ese objetivo. Que encajen copias más frecuentes, copia del registro de transacciones u otro método depende de la aplicación y del almacenamiento de datos.

En su módulo de concepto de copias de seguridad, el BSI destaca, entre otras cosas, la recuperación documentada. La falta de instrucciones o la información indisponible pueden retrasar o impedir la recuperación. Por ello, la documentación debe seguir siendo accesible aunque fallen el servidor afectado y sus vías normales de acceso. BSI: CON.3 Concepto de copias de seguridad, edición de 2022 ↗

Compruebe copias separadas, retención adecuada y separación del acceso respecto al entorno de producción. Para copias cifradas, las claves y los permisos necesarios forman parte del plan de recuperación. Deben permanecer disponibles de forma segura sin quedar expuestos en la documentación general. Una copia de base de datos también debe proporcionar un estado coherente; copiar arbitrariamente archivos abiertos en ese momento no es una suposición fiable para ello.

Ejemplo: por qué se incumple un objetivo de restauración de dos horas

Un servicio hipotético debe volver a ser utilizable dentro de las dos horas posteriores a una interrupción. La copia contiene 200 GB en unidades decimales. Para la prueba suponemos una tasa efectiva de transferencia de 400 Mbit/s. Por tanto, solo la transferencia de datos necesita 200 × 8,000 / 400 = 4,000 segundos, unos 67 minutos. Todas las duraciones siguientes son suposiciones de nuestro propio modelo.

El resultado es de aproximadamente dos horas y 37 minutos, por lo que no se cumple el objetivo. Una conexión más rápida por sí sola no resolverá necesariamente todos los problemas. Entre las posibles medidas están un sistema de destino preparado, una copia más fácilmente disponible, menos dependencias manuales o un método de recuperación técnicamente distinto. Vuelva a medir después. Un valor optimista en una hoja de cálculo no cuenta como objetivo cumplido.

Relacione las alertas con una acción

Una simple comprobación de ping informa de que un equipo responde. No muestra si un cliente puede iniciar sesión o guardar un pedido. Combine señales técnicas con una comprobación de bajo impacto de la función necesaria. Una alerta debe identificar la aplicación afectada, su urgencia, quién responde y dónde están las instrucciones apropiadas.

Observe tendencias además de errores: capacidad libre, antigüedad de la última copia satisfactoria, tiempos de respuesta crecientes y certificados próximos a caducar. En el espacio de almacenamiento importa el cambio. Nuestro cálculo con 500 GB libres y crecimiento de 20 GB diarios da teóricamente 25 días hasta llenarse; las reservas de mantenimiento y los picos acortan el periodo utilizable. Esto permite planificar la ampliación antes de que una aplicación rechace escrituras.

Elimine o modifique las alertas que sigan sin aportar significado. Una bandeja llena de mensajes idénticos dificulta reconocer interrupciones reales. Los errores recurrentes necesitan una acción sobre su causa raíz con un plazo. Las alertas silenciadas necesitan una fecha de fin o un motivo documentado para que no se olviden después del mantenimiento.

Mantenga también los plazos de soporte y la información de traspaso

Mantenga un calendario del ciclo de vida del sistema operativo, la base de datos, la aplicación y el hardware. El alcance del soporte depende del producto, la versión y los contratos adquiridos. Canonical, por ejemplo, distingue distintas coberturas de mantenimiento y soporte en el ciclo de vida de Ubuntu. Compruebe la cobertura real de su instalación en lugar de fijarse solo en la antigüedad del número de versión. Canonical: Ciclo de versiones de Ubuntu y cobertura de soporte ↗

Inicie una actualización de versión con suficiente antelación para probar compatibilidad y reversión. Mantenga también actualizado el inventario: ¿qué aplicación necesita qué base de datos, interfaz y persona responsable? Al traspasar a un nuevo proveedor, la información y el acceso necesario deben poder transferirse ordenadamente. La documentación forma parte del sistema operado.

Un informe mensual que lleve a decisiones

Un informe operativo útil no necesita veinte gráficos. Identifica las interrupciones relevantes, los cambios completados, las pruebas de restauración más recientes y los próximos límites de capacidad o soporte. Los asuntos abiertos tienen un responsable y una fecha. Así, los propietarios del negocio pueden ver qué limitación persiste y qué decisión hace falta.

Las copias fallidas o un objetivo de recuperación incumplido deben ser visibles en este informe. Solo corregir la causa y superar una prueba cierra el asunto. Entonces el mantenimiento pasa de una cuota mensual difícil de concretar a un servicio verificable cuya contribución a la capacidad de trabajo de la empresa sigue siendo comprensible.