Cómo crear una implementación recuperable de Home Assistant con contenedores

Una implementación recuperable de Home Assistant en contenedores trata la imagen del contenedor como desechable, y considera que el estado, la configuración, los secretos, las asignaciones de dispositivos, el comportamiento de red y el procedimiento de restauración son el sistema real.

El objetivo no es simplemente hacer que Docker reinicie Home Assistant. El objetivo es reconstruir el servicio en un host limpio después de una actualización fallida, la pérdida de un disco o el reemplazo del host, y recuperar los mismos usuarios, integraciones, automatizaciones, radios, estado de la base de datos e identidad de red dentro de un plazo conocido.

Mantén el estado persistente fuera de la imagen del contenedor

Monta el directorio de configuración completo de Home Assistant en un almacenamiento persistente del host y haz copias de seguridad de todo su contenido, incluidos los directorios ocultos. Las migraciones de la comunidad fallan repetidamente cuando los operadores copian los archivos YAML visibles, pero omiten .storage, donde se guardan las entidades gestionadas desde la interfaz, las integraciones y otros estados. Un fallo de migración de contenedor muestra cómo la expansión de comodines del shell puede omitir silenciosamente esos archivos ocultos.

Conserva el archivo de Compose, la plantilla de variables de entorno, la zona horaria, el modo de red, las asignaciones de dispositivos, las rutas de los montajes vinculados y los permisos de grupo necesarios en notas de infraestructura versionadas. No integres el estado específico de una vivienda en una imagen personalizada, a menos que también tengas una compilación reproducible y una copia de recuperación independiente.

La topología completa de servidor de Home Assistant de ZimaSpace ofrece el patrón general: mantén pequeña la ruta de control, separa el estado persistente del almacenamiento masivo y coloca la recuperación fuera del dominio de fallo activo antes de añadir más dependencias de servicios.

Haz copias de seguridad del estado de forma coherente, no solo frecuente

Una copia de seguridad solo es útil si sus archivos representan un momento coherente. Para una implementación local sencilla con SQLite, detener el servicio durante una ventana de mantenimiento y copiar el volumen de configuración persistente es fácil de comprender. Para una base de datos externa, haz la copia mediante un método coherente con la base de datos y registra con qué copia de seguridad de la configuración de Home Assistant debe asociarse.

Un flujo reciente de copia de seguridad de volúmenes de Docker hace hincapié en restaurar la copia en lugar de asumir que un comando de archivado ejecutado correctamente equivale a capacidad de recuperación. Conserva al menos una generación fuera del host de Docker para que un SSD, sistema de archivos o poda accidental defectuosos no eliminen tanto el servicio como la copia de seguridad.

Registra la antigüedad de la copia, la versión de la aplicación, la versión de la base de datos, el tamaño, la suma de comprobación, la ubicación de la clave de cifrado y los pasos para restaurar en un host limpio. La retención sin metadatos de restauración crea un montón de archivos, no un sistema de recuperación.

Modela las dependencias y la disponibilidad en Compose

Cuando Home Assistant depende de MQTT, una base de datos externa, un proxy u otro servicio local, el orden de inicio de los contenedores no equivale a la disponibilidad del servicio. Un proceso puede estar en ejecución mientras su socket, esquema o endpoint de estado siguen sin estar disponibles. Una guía sobre la disponibilidad en Compose muestra cómo las comprobaciones de estado y las condiciones de dependencia reducen las carreras durante el inicio.

Asigna a cada dependencia su propia señal de estado y comportamiento ante fallos. Home Assistant debería volver a intentar conectarse a una base de datos que está iniciándose, pero una base de datos que permanece en estado incorrecto debe mostrarse como un fallo, no quedar oculta tras reinicios interminables. Usa políticas de reinicio para recuperarte de las salidas de procesos; utiliza comprobaciones de estado y monitorización para decidir si el servicio está realmente disponible.

Mantén los servicios opcionales fuera de la cadena crítica de inicio siempre que sea posible. Un renderizador de paneles, una herramienta multimedia o un exportador de métricas defectuosos no deberían mantener desconectado el controlador de automatizaciones.

-15% OFF

ZimaBoard 2 - Mini servidor doméstico para tu gran idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Fija los límites de cambio y conserva un par de reversión

Antes de una actualización, registra la etiqueta actual de la imagen de Home Assistant, la definición de Compose, la versión de la base de datos, la copia de seguridad de la configuración y las versiones de cualquier servicio complementario que participe en el inicio. Cambia una sola capa cada vez. Si una actualización falla, revertir únicamente la imagen del contenedor puede ser inseguro después de que las migraciones de configuración o de la base de datos hayan modificado el estado persistente.

Utiliza una restauración de prueba o un directorio de recuperación clonado para probar la versión objetivo antes de realizar una migración importante del host o de la base de datos. Conserva como par la imagen anterior que se sabía que funcionaba y la instantánea del estado creada justo antes de la actualización. Elimina ese par solo después de que la nueva versión supere las pruebas de automatizaciones, historial, radios, paneles, notificaciones y reinicio.

Un artículo más reciente sobre el diseño de Home Assistant con Docker Compose trata las redes, el almacenamiento persistente y las copias de seguridad como decisiones explícitas de implementación. Ese es el modelo adecuado para la reversión: conserva el estado y la definición de implementación que necesita un contenedor de reemplazo, no el sistema de archivos desechable del contenedor.

Reconstruye en un host limpio antes de considerar recuperable la implementación

Elige una máquina de repuesto, una máquina virtual o un directorio de prueba aislado y realiza la recuperación sin leer archivos del sistema de archivos del contenedor activo. Instala el entorno de ejecución de contenedores, coloca la definición de Compose, restaura el estado persistente, vuelve a crear los secretos, conecta las radios mediante rutas de dispositivo estables, inicia las dependencias necesarias y arranca Home Assistant.

Comprueba la propiedad y los permisos de los archivos antes de asumir que la copia de seguridad es defectuosa. Las diferencias de permisos después de una migración pueden mostrar una pantalla de configuración inicial aunque los datos existan. Un caso de recuperación de una migración de Docker muestra cómo los permisos y el estado oculto pueden impedir de forma independiente que aparezca la instalación restaurada.

1. Inicia sesión con la cuenta de administrador existente.
2. Verifica las integraciones, entidades, automatizaciones, paneles y el historial.
3. Confirma la propiedad de Zigbee, Z-Wave, Thread, Bluetooth u otras radios.
4. Desconecta Internet y ejecuta una automatización local crítica.
5. Reinicia el host y todas las dependencias necesarias.
6. Mide el tiempo total de restauración desde un host vacío hasta recuperar el control funcional de la vivienda.

Usa un contrato de recuperación para cada dependencia en contenedores

Una implementación recuperable cuenta con una definición versionada, estado fuera del host, disponibilidad de las dependencias, un par de reversión y una restauración cronometrada en un host limpio. Una vez superadas esas pruebas, los contenedores se convierten en lo que deben ser: unidades de ejecución reemplazables, no mascotas irremplazables.