Disk-usage tools can be misleading on a NAS because a directory may be either ordinary local storage or the place where another filesystem is mounted. This January 2026 thread began with a 1 TB ZimaOS drive showing roughly 915 GB used even though the user believed only about 450 GB of media existed. The first assumption was Docker cache. The command output instead pointed toward /DATA/.media, onde estavam envolvidos pontos de montagem de cópias de segurança e de armazenamento remoto.
Meça antes de podar o Docker
A primeira resposta da comunidade sugeriu inspecionar as pastas maiores em /DATA e verificar a própria contabilização do Docker. Isso era razoável, mas o resultado do utilizador mostrava apenas cerca de 2,1 GB na árvore do Docker e cerca de 2 GB de AppData.
Por isso, o Docker não podia explicar centenas de gigabytes em falta.
/DATA a partição estava quase cheia.O primeiro utilizador encontrou 424 GB em /DATA/.media/UNTITLED 2
A análise do tamanho mostrou cerca de 419 GB de ficheiros multimédia normais, além de outros 424 GB em /DATA/.media/UNTITLED 2. O utilizador reconheceu esse nome como o SSD anteriormente utilizado como destino de cópia de segurança do ZimaOS.
A parte confusa era que a unidade física de cópia de segurança já não estava ligada.
Um ponto de montagem pode transformar-se numa pasta local normal
Os pontos de montagem do Linux são diretórios. Quando uma unidade USB ou uma partilha SMB é montada, os acessos ao diretório chegam ao sistema de ficheiros externo. Se o sistema de ficheiros externo desaparecer e uma aplicação continuar a escrever no mesmo diretório, essas escritas podem acabar no sistema de ficheiros local subjacente.
Isto cria o clássico cenário de falha “o meu destino de cópia de segurança é externo, então porque é que o disco do sistema ficou cheio?”.
Não elimine um diretório .media antes de saber se está montado
A resolução de problemas original propunha comandos de remoção destrutivos depois de verificar o estado da montagem. Essa ordem é importante. Eliminar ficheiros de um destino de cópia de segurança montado e ativo pode apagar a cópia de segurança externa real em vez de recuperar dados locais ocultos.
Como o comando de eliminação era uma orientação da comunidade, e não uma instrução de suporte da IceWhale, esta página não o apresenta como uma receita de limpeza genérica.
Um segundo utilizador reproduziu o mesmo padrão após uma falha de energia
Mais tarde na discussão, outro utilizador com um sistema ZimaOS-HD com uma pequena partição de sistema/dados perdeu todo o espaço livre restante depois de uma falha de energia ter interrompido a atividade de cópia de segurança. Os dados brutos du o resultado parecia enorme porque também contabilizava dados RAID montados e SMB no interior /DATA/.media.
Utilize uma Análise no Mesmo Sistema de Ficheiros para Separar os Dados Locais das Montagens
A comunidade recomendou uma du análise que permanece no mesmo sistema de ficheiros, excluindo assim as partilhas de rede montadas. No segundo caso, esta análise revelou cerca de 30 GB de dados genuinamente locais sob um diretório com o nome de um IP dentro de /DATA/.media.
O Segundo Utilizador Recuperou 30 GB
Depois de confirmar que o diretório com o nome do IP não era uma montagem SMB ativa e de o identificar como dados locais deixados por baixo do ponto de montagem, o utilizador removeu o conteúdo indesejado e comunicou ter recuperado 30 GB.
Esse é o resultado confirmado mais sólido do tópico.
A Teoria da Comunidade Era que a Cópia de Segurança Escrevia Enquanto o Destino Estava Desmontado
O autor da resposta acreditava que o processo de cópia de segurança continuava a escrever no caminho SMB esperado quando a partilha não estava corretamente montada, fazendo com que o Linux escrevesse no diretório local em vez disso.
A recuperação confirmada de 30 GB apoia a existência de ficheiros locais sob o ponto de montagem, mas a explicação exata da falha da cópia de segurança foi um diagnóstico da comunidade, não uma publicação da equipa de engenharia da IceWhale neste tópico.
A Gestão de Cópias de Segurança e do Armazenamento no ZimaOS Mudou
A documentação atual do ZimaOS aborda as tarefas de cópia de segurança geridas e uma gestão de armazenamento mais abrangente. Utilize o fluxo de trabalho atual de cópia de segurança do ZimaOS para novos trabalhos e confirme que o destino pretendido está efetivamente montado antes de iniciar grandes gravações.
Um Fluxo de Trabalho Mais Seguro para Espaço em Falta
- Utilize
dfpara confirmar qual o sistema de ficheiros local está cheio. - Analise apenas esse sistema de ficheiros, para que as montagens SMB, USB e RAID não aumentem artificialmente os totais.
- Verifique o Docker e os dados da AppData separadamente.
- Inspecionar
/DATA/.mediapara diretórios de pontos de montagem que contêm ficheiros locais reais. - Confirme que o destino não está montado antes de eliminar qualquer conteúdo por baixo de um ponto de montagem.
- Depois da limpeza, confirme o espaço livre e volte a testar o destino da cópia de segurança.
O Caso dos 424 GB do Primeiro Utilizador Era Mais Ambíguo do que o Caso Posterior dos 30 GB
O autor original viu cerca de 424 GB numa pasta com o nome do SSD de cópia de segurança desligado e presumiu que fossem dados redundantes. A discussão passou depois por verificações de montagem e propostas de limpeza, mas a recuperação confirmada mais clara no tópico veio do utilizador posterior, que recuperou 30 GB.
Essa distinção é importante porque um diretório sob /DATA/.media pode representar uma montagem ativa, um ponto de montagem obsoleto ou ficheiros locais reais. O facto de o caminho ter o mesmo aspeto não implica a mesma ação de limpeza segura em todos os sistemas.
Utilize df e du para perguntas diferentes
df responde à pergunta “que sistema de ficheiros está realmente cheio?”, enquanto du responde à pergunta “que diretórios visíveis contêm ficheiros?”. Num NAS com montagens aninhadas, as duas ferramentas podem parecer discordar porque du pode entrar noutros sistemas de ficheiros se não lhe for indicado que não o faça.
A discussão só ficou muito mais clara depois de a resolução de problemas separar o sistema de ficheiros local ZimaOS-HD do conteúdo SMB e RAID montado.
As perdas inesperadas de energia tornam os problemas dos pontos de montagem mais perigosos
O caso posterior dos 30 GB começou após uma falha de energia enquanto as cópias de segurança estavam ativas. Se um destino remoto não for novamente montado corretamente após o arranque, mas uma tarefa de cópia de segurança continuar ou for reiniciada, o caminho pode continuar a existir como um diretório local normal.
Para tarefas de cópia de segurança importantes, verifique se o destino está montado e com permissões de escrita após um reinício ou evento de falha de energia, antes de presumir que o caminho antigo continua a apontar para o destino externo.
Não elimine manualmente o overlay2 do Docker para recuperar espaço
No início da discussão, os caminhos overlay do Docker pareciam visualmente proeminentes no resultado do sistema de ficheiros. A comunidade alertou especificamente contra a eliminação arbitrária de ficheiros de overlay2. A camada de armazenamento do Docker deve ser gerida através do Docker ou do ciclo de vida da aplicação, e não através da remoção aleatória de diretórios de camadas.
O ZimaOS atual também mostra a utilização do armazenamento das aplicações
As definições atuais das aplicações do ZimaOS mostram o consumo de armazenamento das aplicações e permitem limpar a cache das aplicações compatíveis. Isto é útil para distinguir o crescimento normal das aplicações dos dados nos pontos de montagem antes de utilizar o terminal.
A explicação de onde as aplicações atuais do ZimaOS armazenam dados e cache fornece um primeiro mapa mais seguro do sistema de ficheiros.
Perguntas frequentes sobre espaço em falta
O overlay2 do Docker foi responsável pelas centenas de gigabytes em falta do primeiro utilizador?
Não. O Docker representava apenas uma pequena fração do espaço utilizado no resultado publicado.
Porque é que o du pode indicar terabytes num disco local muito mais pequeno?
Pode contar recursivamente sistemas de ficheiros remotos montados ou sistemas de ficheiros RAID, a menos que a análise seja limitada ao sistema de ficheiros local.
Foi confirmada alguma recuperação?
Sim. O utilizador posterior recuperou 30 GB de dados locais armazenados sob um diretório de ponto de montagem SMB.
