Cómo evitar que los registros de Home Assistant llenen el disco del sistema

Evita que los registros de Home Assistant llenen el disco identificando primero el archivo exacto que está creciendo, corrigiendo el evento repetitivo y aplicando la retención en la capa propietaria de ese registro.

En un pequeño servidor doméstico, los registros de Home Assistant Core, Docker, Supervisor o los complementos, así como el journal del sistema anfitrión, pueden consumir el mismo disco del sistema y requerir soluciones diferentes. Mide el crecimiento durante un intervalo breve y controlado, conserva suficiente evidencia para identificar quién escribe, usa límites reversibles y detén las escrituras no esenciales si el espacio restante es demasiado bajo para reiniciar o hacer una copia de seguridad de forma segura.

Identifica qué registro está consumiendo espacio

Registra el espacio libre total y, después, muestra los archivos y directorios más grandes del sistema de archivos afectado sin eliminar nada. Compara los tamaños nuevamente después de cinco a diez minutos mientras Home Assistant funciona con normalidad. El archivo cuyo tamaño cambia es más útil que una lista estática de archivos antiguos de gran tamaño.

Los casos de Home Assistant demuestran que el agotamiento del disco puede proceder de distintas capas, incluidos los registros del sistema y no solo la base de datos de Recorder. Una discusión resuelta rastreó el crecimiento hasta el journal de systemd, por lo que la primera distinción es qué directorio sigue creciendo, no si Home Assistant parece estar ocupado.

Si crece un registro de Core, inspecciona el componente y el mensaje que se repiten. Si crecen los registros JSON de Docker, inspecciona el controlador de registros del contenedor. Si crece el journal, inspecciona el servicio que los emite. Si el espacio libre ya es críticamente bajo, detén el contenedor no esencial más ruidoso o el propio Home Assistant antes de que nuevas escrituras dificulten la recuperación.

Corrige los errores repetitivos antes de reducir la visibilidad

Cuenta el mensaje predominante y relaciona sus marcas de tiempo con un dispositivo, integración, automatización, complemento o evento de red. Una advertencia repetida miles de veces suele ofrecer más valor preventivo que decenas de entradas aisladas y no relacionadas. Guarda una muestra breve con la versión y el desencadenante antes de cambiar la configuración.

Un problema de Home Assistant Core documentó un error de Tradfri que hizo crecer un registro hasta superar los 10 GB y agotó el disco del sistema. Es un ejemplo específico de una versión en el que una integración saturó un registro; respalda la identificación del emisor, no la suposición de que Tradfri o la rotación sean siempre la causa.

Desactiva el registro de depuración cuando hayas terminado la captura; después, recarga o desactiva únicamente la integración ruidosa confirmada y repite el desencadenante original. Si la frecuencia de mensajes disminuye drásticamente, repara esa integración o su dependencia. Si no lo hace, restablece la configuración y pasa al siguiente emisor verificado en lugar de suprimir todas las advertencias.

Configura la retención en la capa propietaria del registro

Establece una política limitada para el journal del sistema anfitrión, el controlador de registros de Docker, el proxy inverso y los demás complementos por separado. El nivel de registro de Core no limita el almacenamiento del journal de systemd, y una opción de tamaño de Docker no rota un archivo escrito directamente dentro de un directorio de configuración montado.

Elige límites que conserven suficiente historial para cubrir el intervalo entre comprobaciones y, al mismo tiempo, mantengan espacio para copias de seguridad, actualizaciones, operaciones de base de datos y recuperación. El artículo relacionado de ZimaSpace sobre el almacenamiento libre de Home Assistant explica por qué consumir el margen final puede interrumpir tareas que necesitan temporalmente espacio adicional en el disco.

Documenta cada política en la configuración que sobreviva a la recreación. Reinicia o recrea únicamente el servicio afectado, confirma que la configuración esté activa y conserva el valor anterior para poder revertir el cambio. No uses un borrado general programado como sustituto de encontrar un emisor anómalo.

-15% OFF

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

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifica que el crecimiento se mantenga limitado con el desencadenante original

Reproduce el evento que causó la saturación, como la desconexión de un dispositivo, un reintento de una integración, una copia de seguridad o una interrupción de red. Supervisa el tamaño del mismo archivo, la frecuencia de mensajes, el espacio libre, el estado del servicio y la respuesta de las automatizaciones durante más tiempo que el intervalo de crecimiento anterior.

Un resultado satisfactorio presenta una huella de registros estable o rotativa, sin pérdida de diagnósticos necesarios, escrituras normales del historial y suficiente espacio libre para la próxima copia de seguridad y actualización. Reinicia el anfitrión una vez y repite el desencadenante para demostrar que los límites siguen funcionando después de recrear los servicios.

Revierte el cambio de retención si elimina la evidencia necesaria para diagnosticar un fallo persistente. Si el registro sigue creciendo después de aislar el origen confirmado, escala el caso con el mensaje repetido, el componente emisor, la versión, la velocidad de crecimiento y la ruta de almacenamiento; vuelve a detener las escrituras si el disco se acerca al agotamiento.