Las herramientas de uso de disco pueden inducir a error en un NAS porque un directorio puede ser un almacenamiento local normal o el lugar donde está montado otro sistema de archivos. Este hilo de enero de 2026 comenzó con una unidad de ZimaOS de 1 TB que mostraba aproximadamente 915 GB usados, aunque el usuario creía que solo existían unos 450 GB de archivos multimedia. La primera suposición fue que se trataba de la caché de Docker. En cambio, la salida del comando apuntó hacia /DATA/.media, donde estaban implicados puntos de montaje de almacenamiento remoto y de copias de seguridad.
Mide antes de depurar Docker
La primera respuesta de la comunidad sugirió inspeccionar las carpetas más grandes en /DATA y comprobar la contabilidad propia de Docker. Era razonable, pero el resultado del usuario mostró solo unos 2,1 GB en el árbol de Docker y unos 2 GB de AppData.
Por tanto, Docker no podía explicar cientos de gigabytes desaparecidos.
/DATA la partición estaba casi llena.El primer usuario encontró 424 GB en /DATA/.media/UNTITLED 2
El análisis de tamaño mostró aproximadamente 419 GB de archivos multimedia normales y otros 424 GB en /DATA/.media/UNTITLED 2. El usuario reconoció ese nombre como el SSD que había utilizado anteriormente como destino de copia de seguridad de ZimaOS.
La parte confusa era que la unidad física de copia de seguridad ya no estaba conectada.
Un punto de montaje puede convertirse en una carpeta local normal
Los puntos de montaje de Linux son directorios. Cuando se monta una unidad USB o un recurso compartido SMB, los accesos al directorio llegan al sistema de archivos externo. Si el sistema de archivos externo desaparece y una aplicación sigue escribiendo en el mismo directorio, esas escrituras pueden terminar en el sistema de archivos local subyacente.
Esto crea el clásico fallo de «mi destino de copia de seguridad es externo, así que ¿por qué se llenó el disco del sistema?».
No elimines un directorio .media hasta saber si está montado
La solución de problemas original propuso comandos de eliminación destructiva después de comprobar el estado del montaje. Ese orden es importante. Eliminar archivos de un destino de copia de seguridad montado y activo puede borrar la copia de seguridad externa real en lugar de recuperar datos locales ocultos.
Como el comando de eliminación era una recomendación de la comunidad y no una instrucción de soporte de IceWhale, esta página no lo presenta como una receta de limpieza genérica.
Un segundo usuario reprodujo el mismo patrón después de un corte de energía
Más adelante en el hilo, otro usuario con una pequeña partición del sistema/datos de ZimaOS-HD perdió todo el espacio libre restante después de que un corte de energía interrumpiera la actividad de copia de seguridad. Su información sin procesar du el resultado parecía enorme porque también contaba los datos RAID y SMB montados debajo /DATA/.media.
Usa un análisis del mismo sistema de archivos para separar los datos locales de los montajes
La comunidad recomendó du un análisis que permanezca en el mismo sistema de archivos para excluir los recursos compartidos de red montados. En el segundo caso, esto reveló unos 30 GB de datos realmente locales bajo un directorio con nombre de IP dentro de /DATA/.media.
El segundo usuario recuperó 30 GB
Después de confirmar que el directorio con el nombre de la IP no era un montaje SMB activo e identificarlo como datos locales que habían quedado bajo el punto de montaje, el usuario eliminó el contenido no deseado e informó que había recuperado 30 GB.
Ese es el resultado confirmado más importante del hilo.
La teoría de la comunidad era que el respaldo escribía mientras el destino estaba desmontado
El usuario que respondió creía que el proceso de respaldo continuó escribiendo en la ruta SMB prevista cuando el recurso compartido no estaba montado correctamente, lo que hizo que Linux escribiera en el directorio local en su lugar.
La recuperación confirmada de 30 GB respalda la existencia de archivos locales bajo el punto de montaje, pero la explicación exacta del problema de respaldo fue un diagnóstico de la comunidad, no una publicación de ingeniería de IceWhale en este hilo.
El manejo actual de respaldos y almacenamiento de ZimaOS ha cambiado
La documentación actual de ZimaOS describe las tareas de respaldo administradas y una gestión de almacenamiento más amplia. Usa el flujo de trabajo de respaldo actual de ZimaOS para los trabajos nuevos y verifica que el destino previsto esté realmente montado antes de iniciar escrituras grandes.
Un flujo de trabajo más seguro para encontrar espacio faltante
- Usa
dfpara confirmar qué sistema de archivos local está lleno. - Analiza únicamente ese sistema de archivos para que los montajes SMB, USB y RAID no inflen los totales.
- Comprueba Docker y AppData por separado.
- Inspeccionar
/DATA/.mediapara directorios de puntos de montaje que contienen archivos locales reales. - Confirma que el destino no esté montado antes de eliminar cualquier elemento situado debajo de un punto de montaje.
- Después de la limpieza, verifica el espacio libre y vuelve a probar el destino de respaldo.
El caso de 424 GB del primer usuario era más ambiguo que el caso posterior de 30 GB
El autor original vio aproximadamente 424 GB en un directorio con el nombre del SSD de respaldo desconectado y creyó que era redundante. Luego, la discusión pasó por comprobaciones de montaje y propuestas de limpieza, pero la recuperación verificada más clara del hilo provino del usuario posterior, que recuperó 30 GB.
Esa distinción importa porque un directorio debajo de /DATA/.media puede representar un montaje activo, un punto de montaje obsoleto o archivos locales reales. Una ruta con el mismo aspecto no implica la misma acción segura de limpieza en todos los sistemas.
Usa df y du para preguntas diferentes
df responde a «¿qué sistema de archivos está realmente lleno?», mientras que du responde a «¿qué directorios visibles contienen archivos?». En un NAS con montajes anidados, las dos herramientas pueden parecer estar en desacuerdo porque du puede adentrarse en otros sistemas de archivos si no se le indica que no lo haga.
El hilo se volvió mucho más claro solo después de que la investigación separara el sistema de archivos local ZimaOS-HD del contenido SMB y RAID montado.
Las pérdidas de energía inesperadas hacen más peligrosos los problemas con los puntos de montaje
El caso posterior de 30 GB comenzó después de un corte de energía mientras las copias de seguridad estaban activas. Si un destino remoto no se vuelve a montar correctamente después del arranque, pero un trabajo de copia de seguridad se reanuda o reinicia, la ruta puede seguir existiendo como un directorio local normal.
Para trabajos de copia de seguridad importantes, verifica que el destino esté montado y permita escritura después de un reinicio o un corte de energía antes de asumir que la ruta antigua sigue apuntando al destino externo.
No elimines manualmente overlay2 de Docker para recuperar espacio
Al principio del hilo, las rutas de overlay de Docker destacaban visualmente en la salida del sistema de archivos. La comunidad advirtió específicamente que no se eliminaran archivos arbitrarios de overlay2. La capa de almacenamiento de Docker debe gestionarse mediante Docker o el ciclo de vida de la aplicación, no eliminando directorios de capas al azar.
ZimaOS también muestra ahora el uso de almacenamiento de las aplicaciones
La configuración actual de las aplicaciones de ZimaOS muestra el consumo de almacenamiento de las aplicaciones y permite limpiar la caché de las aplicaciones compatibles. Esto resulta útil para distinguir el crecimiento normal de las aplicaciones de los datos en puntos de montaje antes de usar el terminal.
La explicación de dónde almacenan los datos y la caché las aplicaciones actuales de ZimaOS ofrece un mapa inicial más seguro del sistema de archivos.
Preguntas frecuentes sobre el espacio desaparecido
¿Fue overlay2 de Docker responsable de los cientos de gigabytes desaparecidos del primer usuario?
No. Docker representaba solo una pequeña fracción del espacio utilizado en la salida publicada.
¿Por qué du puede informar de terabytes en un disco local mucho más pequeño?
Puede contar recursivamente los sistemas de archivos remotos montados o RAID, a menos que el análisis se limite al sistema de archivos local.
¿Se confirmó alguna recuperación?
Sí. Posteriormente, otro usuario recuperó 30 GB de datos locales almacenados debajo de un directorio que servía como punto de montaje SMB.
