¿Puede un servidor doméstico reanudar los servicios en orden de dependencia después de la recuperación del SAI?

Eva Wong

IceWhale author

Eva Wong es la Redactora técnica y manitas residente en ZimaSpace. Una geek de toda la vida con pasión por los homelabs y el software de código abierto, se especializa en traducir conceptos técnicos complejos en guías accesibles y prácticas. Eva cree que el autoalojamiento debe ser divertido, no intimidante. A través de sus tutoriales, empodera a la comunidad para desmitificar las configuraciones de hardware, desde construir su primer NAS hasta dominar los contenedores Docker.

Can a Home Server Resume Services in Dependency Order After UPS Recovery?

Sí, pero solo cuando el grafo de dependencias está definido explícitamente. Un servidor puede encenderse automáticamente después de que se restablezca el UPS, mientras las aplicaciones siguen fallando porque el almacenamiento, el DNS, las bases de datos o las redes aún no están listos.

El orden de inicio de los procesos no es lo mismo que la disponibilidad del servicio. Usa dependencias de systemd para los recursos del host y comprobaciones de estado para los contenedores y las aplicaciones. Esta distinción determina la configuración segura, el método de validación y el punto de reversión.

Escribe el grafo de dependencias antes de automatizarlo

Enumera la cadena desde la alimentación y la red, pasando por los discos cifrados, los montajes NAS, el entorno de ejecución de contenedores, las bases de datos, los servicios de aplicaciones y el proxy inverso. Indica qué dependencias son locales y cuáles se encuentran en otro servidor.

Asigna a cada dependencia con estado una señal de disponibilidad: ruta montada, consulta a la base de datos, resolución DNS o endpoint de estado de la aplicación. Evita las esperas fijas, porque el tiempo de recuperación cambia después de un apagado incorrecto.

Define un estado de fallo acotado para que la ausencia del NAS no haga que una aplicación escriba en un directorio local vacío.

Coordina cada capa de control

Usa las relaciones `After=` y `RequiresMountsFor=` de systemd para los servicios del host y los montajes remotos. Haz que la unidad de la pila de contenedores dependa de Docker y de las unidades de montaje necesarias.

Dentro de Compose, añade comprobaciones de estado reales y usa `depends_on` con `condition: service_healthy` cuando sea compatible. Las aplicaciones aún deben reintentar las conexiones a la base de datos, porque las dependencias pueden fallar después del inicio.

Usa la tabla siguiente para asignar cada dependencia a la capa que realmente puede observarla.

Estado observado	Veredicto	Siguiente acción
Montajes de discos y NAS	Dependencias de montaje de systemd	Bloquear los servicios con estado
Base de datos lista para consultas	Comprobación de estado del contenedor	Bloquear las aplicaciones
Aplicación externa accesible	Reintento de la aplicación más monitorización	No usar una espera fija

Diseña la recuperación entre dos servidores

Inicia primero el servidor de almacenamiento o infraestructura y, después, espera a que los recursos compartidos exportados y las bases de datos estén en buen estado antes de habilitar los servicios de aplicaciones en el segundo host. El software del UPS no debería limitarse a encender ambos hosts simultáneamente.

El artículo de ZimaSpace sobre señales del UPS y máquinas virtuales muestra por qué la cadena de control atraviesa varias capas.

Una guía independiente sobre systemd y Compose explica las condiciones de carrera en el orden de arranque y apagado.

Mantén un procedimiento manual de arranque en frío para el caso en que la automatización se detenga por un control de estado fallido. Debe indicar la comprobación, el tiempo de espera previsto, el reintento seguro y el responsable de cada servicio.

Featured

ZimaCube 2 NAS personal en la nube para el hogar

ZimaCube2

Prueba el estado completo de recuperación del UPS

Organiza un apagado controlado con batería, restablece la corriente alterna y registra las marcas de tiempo del arranque del host, la disponibilidad de los montajes, el estado de la base de datos, el estado de la aplicación y la disponibilidad del proxy.

Repite la prueba con un NAS retrasado y con una recuperación de la base de datos que tarde más de lo normal. Los servicios deben esperar o fallar de forma visible, en lugar de iniciarse sin el estado necesario.

Continúa cuando la recuperación normal y la retrasada conserven el orden y las rutas de datos. Detente si las políticas de reinicio omiten la disponibilidad, las aplicaciones escriben en directorios alternativos o una dependencia no tiene una señal de estado medible.