«El almacenamiento integrado está casi lleno» es un síntoma, no un único error de ZimaOS. Este hilo de origen reveló al menos tres causas diferentes: una tarea de copia de seguridad cuyo destino USB desapareció y que, en la práctica, se recreó en el almacenamiento local /DATA, un registro JSON de Docker descontrolado que creció hasta 519 GB y otro sistema en el que /DATA/.media ocupaba 409 GB.
La respuesta más segura es medir primero, identificar el servicio responsable, detener el proceso que escribe y limpiar únicamente los datos confirmados. No elimines de forma recursiva /DATA/.docker, .media ni AppData solo porque sean grandes.
/DATA aunque su gran grupo de datos todavía tenía varios terabytes disponibles.Migrar los datos de las aplicaciones no garantiza que todas las escrituras futuras abandonen /DATA
Usa comprobaciones de du de solo lectura para encontrar el directorio más grande
El usuario de origen compartió lo siguiente:
sudo du -x -h --max-depth=1 /DATA 2>/dev/null | sort -hrEsto no modifica archivos. Repítelo en un directorio sospechoso para localizar el subárbol más grande.
Un destino de copia de seguridad desconectado fue la primera causa confirmada
Cobblerkid descubrió que una tarea de copia de seguridad esperaba una unidad USB externa. Después de desconectar la unidad, la estructura de la copia de seguridad se recreó en /DATA y la tarea programada siguió escribiendo hasta llenar el almacenamiento local.
Zima-Jerry confirmó que esto parecía ser un problema y lo remitió internamente. Esto lo convierte en algo más que una teoría de la comunidad.
Otro usuario encontró un registro JSON de contenedor de 519 GB
Un segundo participante inspeccionó el directorio de un contenedor de Docker y encontró un *-json.log un archivo de aproximadamente 519 GB, atribuido a un contenedor de Home Assistant.
El usuario eliminó el contenedor y recuperó espacio. No generalices esto como «eliminar manualmente los registros de Docker»; primero identifica el contenedor que genera el exceso de registros, inspecciona sus registros y corrige el error repetido que los está generando.
Otro sistema tenía 409 GB en /DATA/.media
Otro usuario publicó un desglose del tamaño en el que los datos normales de las aplicaciones ocupaban unos 225 GB, .docker solo 3,5 GB, pero .media ocupaba 409 GB. Esto demuestra por qué un solo comando de limpieza no puede resolver todos los informes de «disco lleno».
La versión actual de ZimaOS ofrece más controles sobre el almacenamiento y la caché de las aplicaciones
La documentación actual de IceWhale indica que Configuración → Aplicaciones muestra la ubicación de AppData y permite limpiar la caché y consultar el uso por aplicación. Mantener AppData en la matriz de almacenamiento principal reduce la presión sobre la pequeña unidad del sistema.
Usa los controles actuales de almacenamiento de aplicaciones de ZimaOS antes de intentar limpiar desde el shell.
Un orden de recuperación más seguro
- detén la tarea o aplicación que todavía esté generando datos;
- mide
/DATAsolo lectura; - identifica el archivo o la carpeta exactos y su propietario;
- haz una copia de seguridad de los datos de AppData y la configuración importantes;
- usa los controles compatibles de aplicaciones/caché siempre que sea posible;
- elimina únicamente datos desechables o cuya incorrección se haya verificado;
- confirma que el espacio libre se mantiene estable después de reiniciar.
docker image prune no soluciona todos los problemas de espacio de Docker
En la fuente, raller1028 mencionó docker image prune -a como forma de eliminar imágenes que los contenedores no utilizan. Esto puede recuperar capas de imágenes no utilizadas, pero no resolverá un registro JSON activo de un contenedor de 519 GB, un destino de copia de seguridad descontrolado ni los datos del usuario en .media.
Usa el análisis de tamaño para identificar primero la categoría. Un comando de limpieza dirigido a la categoría equivocada puede liberar casi nada y, al mismo tiempo, crear nuevos riesgos.
Un registro JSON enorme significa que el bucle de errores del contenedor sigue activo
Eliminar el contenedor problemático liberó espacio para un usuario, pero la mejor pregunta a largo plazo es por qué la aplicación escribió cientos de gigabytes de registros. Inspecciona los registros recientes para detectar errores repetidos, bucles de reinicio, dispositivos no disponibles o problemas de configuración antes de reinstalar la misma carga de trabajo.
Si el contenedor recreado comienza inmediatamente a generar registros de nuevo, la condición de disco lleno volverá.
Trata .media como almacenamiento administrado, no como caché desechable
Los 409 GB /DATA/.media el ejemplo puede contener datos reales de montajes/archivos administrados en lugar de una caché temporal. Antes de eliminar cualquier elemento allí, identifica qué almacenamiento, recurso compartido o aplicación es su propietario y confirma que los mismos archivos existan en otro lugar.
Preguntas frecuentes sobre el almacenamiento integrado lleno
¿La fuente demostró que la migración de AppData había fallado?
No. El autor original había migrado las categorías administradas; el llenado confirmado provenía de un destino de copia de seguridad desconectado.
¿Es seguro eliminar todo el directorio .docker?
No. Puede contener el estado activo de los contenedores, registros, imágenes y dependencias de las aplicaciones.
¿Cuál es el mejor primer comando de la fuente?
Una operación de solo lectura du análisis de tamaño de /DATA para identificar el subárbol grande real.
