ZimaOS: brakujące miejsce na dysku — znajdź lokalne dane ukryte pod punktami montowania kopii zapasowych i SMB

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, w którym występowały punkty montowania pamięci kopii zapasowych i zdalnej. Narzędzia do analizy zajętości dysku mogą wprowadzać w błąd na serwerze NAS, ponieważ katalog może być albo zwykłym lokalnym miejscem przechowywania, albo miejscem, w którym zamontowano inny system plików. Ten wątek ze stycznia 2026 roku rozpoczął się od dysku ZimaOS o pojemności 1 TB, na którym zajęte było około 915 GB, mimo że użytkownik sądził, iż ma tylko około 450 GB multimediów. Pierwszym założeniem była pamięć podręczna Dockera. Dane wyjściowe polecenia wskazały natomiast na

Zmierz, zanim zaczniesz usuwać dane Dockera

Pierwsza odpowiedź społeczności sugerowała sprawdzenie największych folderów w /DATA i sprawdzenie własnych statystyk Dockera. Było to rozsądne, ale wynik użytkownika pokazał tylko około 2,1 GB w drzewie Dockera i około 2 GB danych AppData.

Docker nie mógł więc wyjaśniać setek brakujących gigabajtów.

Pierwszy użytkownik znalazł 424 GB w /DATA/.media/UNTITLED 2

Skanowanie rozmiaru wykazało około 419 GB zwykłych multimediów oraz kolejne 424 GB w /DATA/.media/UNTITLED 2. Użytkownik rozpoznał tę nazwę jako nazwę dysku SSD używanego wcześniej jako miejsce docelowe kopii zapasowych ZimaOS.

Mylące było to, że fizyczny dysk kopii zapasowej nie był już podłączony.

Punkt montowania może stać się zwykłym lokalnym folderem

Punkty montowania w systemie Linux są katalogami. Po zamontowaniu dysku USB lub udziału SMB dostęp do katalogu prowadzi do zewnętrznego systemu plików. Jeśli zewnętrzny system plików zniknie, a aplikacja nadal będzie zapisywać do tego samego katalogu, te zapisy mogą trafić do lokalnego systemu plików znajdującego się niżej.

To prowadzi do klasycznego scenariusza „cel kopii zapasowej jest zewnętrzny, więc dlaczego zapełnił się dysk systemowy?”.

Nie usuwaj katalogu .media, dopóki nie wiesz, czy jest zamontowany

W źródłowym rozwiązaniu problemu zaproponowano destrukcyjne polecenia usuwania po sprawdzeniu stanu montowania. Ta kolejność ma znaczenie. Usuwanie plików z aktywnie zamontowanego miejsca docelowego kopii zapasowej może skasować rzeczywistą zewnętrzną kopię zapasową zamiast odzyskać lokalne ukryte dane.

Ponieważ polecenie usuwania było poradą społeczności, a nie instrukcją pomocy technicznej IceWhale, na tej stronie nie przedstawiono go jako uniwersalnej procedury czyszczenia.

Drugi użytkownik odtworzył ten sam schemat po awarii zasilania

Później w wątku inny użytkownik z niewielką partycją systemową/danych ZimaOS-HD utracił całe pozostałe wolne miejsce po tym, jak awaria zasilania przerwała tworzenie kopii zapasowej. Jego surowe du wynik wyglądał na ogromny, ponieważ uwzględniał również zamontowane dane RAID i SMB znajdujące się poniżej /DATA/.media.

Użyj skanowania w obrębie tego samego systemu plików, aby oddzielić dane lokalne od montowań

Społeczność zaleciła du skanowanie odbywające się w obrębie tego samego systemu plików, dzięki czemu zamontowane udziały sieciowe są wykluczone. W drugim przypadku ujawniło to około 30 GB rzeczywiście lokalnych danych w katalogu nazwanym adresem IP, znajdującym się wewnątrz /DATA/.media.

Drugi użytkownik odzyskał 30 GB

Po potwierdzeniu, że katalog nazwany adresem IP nie był aktywnym montowaniem SMB, i ustaleniu, że zawierał lokalne dane pozostawione pod punktem montowania, użytkownik usunął niechcianą zawartość i zgłosił odzyskanie 30 GB.

To najsilniej potwierdzony wynik w całym wątku.

Teoria społeczności zakładała, że kopia zapasowa była zapisywana, gdy miejsce docelowe nie było zamontowane

Odpowiadający uznał, że proces tworzenia kopii zapasowej nadal zapisywał dane w oczekiwanej ścieżce SMB, gdy udział nie był prawidłowo zamontowany, przez co system Linux zapisywał je zamiast tego w lokalnym katalogu.

Potwierdzone odzyskanie 30 GB wskazuje na istnienie lokalnych plików pod punktem montowania, ale dokładna hipoteza dotycząca problemu z kopią zapasową była diagnozą społeczności, a nie wpisem inżynierów IceWhale w tym wątku.

Obsługa kopii zapasowych i pamięci masowej w aktualnym ZimaOS uległa zmianie

Aktualna dokumentacja ZimaOS opisuje zarządzane zadania tworzenia kopii zapasowych i szersze zarządzanie pamięcią masową. W przypadku nowych zadań skorzystaj z aktualnego procesu tworzenia kopii zapasowych w ZimaOS i upewnij się, że wybrane miejsce docelowe jest rzeczywiście zamontowane, zanim rozpoczną się duże zapisy.

Bezpieczniejszy sposób wykrywania brakującego miejsca

1. Użyj df aby potwierdzić, który lokalny system plików jest pełny.
2. Przeskanuj tylko ten system plików, aby montowania SMB, USB i RAID nie zawyżały wyników.
3. Sprawdź osobno Dockera i AppData.
4. Sprawdź /DATA/.media w przypadku katalogów punktów montowania zawierających rzeczywiste pliki lokalne.
5. Przed usunięciem czegokolwiek znajdującego się pod punktem montowania upewnij się, że miejsce docelowe nie jest zamontowane.
6. Po wyczyszczeniu sprawdź ilość wolnego miejsca i ponownie przetestuj miejsce docelowe kopii zapasowej.

Przypadek 424 GB pierwszego użytkownika był bardziej niejednoznaczny niż późniejszy przypadek 30 GB

Autor pierwotnego posta zobaczył około 424 GB w katalogu nazwanym jak odłączony dysk SSD z kopią zapasową i uznał, że dane są zduplikowane. Następnie dyskusja objęła sprawdzanie punktu montowania i propozycje czyszczenia, ale najjaśniejszy potwierdzony przypadek odzyskania miejsca dotyczył późniejszego użytkownika, który odzyskał 30 GB.

To rozróżnienie ma znaczenie, ponieważ katalog znajdujący się pod /DATA/.media może oznaczać aktywne zamontowanie, nieaktualny punkt montowania lub rzeczywiste lokalne pliki. Taki sam wygląd ścieżki nie oznacza, że na każdym systemie można bezpiecznie wykonać tę samą czynność czyszczenia.

Używaj df i du do różnych celów

df odpowiada na pytanie „który system plików jest faktycznie pełny?”, podczas gdy du odpowiada na pytanie „które widoczne katalogi zawierają pliki?”. Na serwerze NAS z zagnieżdżonymi punktami montowania oba narzędzia mogą wydawać się niezgodne, ponieważ du może przejść do innych systemów plików, jeśli nie otrzyma odpowiedniego ograniczenia.

Wątek stał się znacznie jaśniejszy dopiero po oddzieleniu lokalnego systemu plików ZimaOS-HD od zamontowanej zawartości SMB i RAID.

Nieoczekiwana utrata zasilania zwiększa zagrożenie związane z błędami punktów montowania

Późniejszy przypadek 30 GB rozpoczął się po awarii zasilania podczas wykonywania kopii zapasowych. Jeśli zdalne miejsce docelowe nie zostanie prawidłowo zamontowane ponownie po uruchomieniu, ale zadanie kopii zapasowej wznowi się lub zostanie ponownie uruchomione, ścieżka może nadal istnieć jako zwykły lokalny katalog.

W przypadku ważnych zadań tworzenia kopii zapasowych po ponownym uruchomieniu lub zdarzeniu związanym z zasilaniem sprawdź, czy miejsce docelowe jest zamontowane i umożliwia zapis, zanim uznasz, że stara ścieżka nadal wskazuje zewnętrzny cel.

Nie usuwaj ręcznie Docker overlay2, aby odzyskać miejsce

Na początku wątku ścieżki warstw Dockera wyglądały na szczególnie widoczne w wynikach systemu plików. Społeczność wyraźnie ostrzegała przed usuwaniem przypadkowych plików z overlay2. Warstwą pamięci masowej Dockera należy zarządzać za pośrednictwem Dockera lub cyklu życia aplikacji, a nie przez usuwanie przypadkowych katalogów warstw.

Bieżące ZimaOS pokazuje także wykorzystanie miejsca przez aplikacje

Ustawienia aplikacji w bieżącym ZimaOS pokazują zużycie miejsca przez aplikacje i umożliwiają czyszczenie pamięci podręcznej w obsługiwanych aplikacjach. Ułatwia to odróżnienie normalnego przyrostu danych aplikacji od danych w punkcie montowania przed przejściem do terminala.

Wyjaśnienie miejsca przechowywania danych i pamięci podręcznej przez bieżące aplikacje ZimaOS zapewnia bezpieczniejszy wstępny obraz systemu plików.

Najczęstsze pytania dotyczące brakującego miejsca

Czy Docker overlay2 odpowiadał za setki brakujących gigabajtów u pierwszego użytkownika?

Nie. Docker odpowiadał tylko za niewielką część zajętego miejsca widocznego w opublikowanych danych wyjściowych.

Dlaczego du może raportować terabajty danych na znacznie mniejszym lokalnym dysku?

Może rekurencyjnie zliczać zamontowane zdalne systemy plików lub systemy RAID, chyba że skanowanie zostanie ograniczone do lokalnego systemu plików.

Czy potwierdzono odzyskanie danych?

Tak. Późniejszy użytkownik odzyskał 30 GB lokalnych danych przechowywanych pod katalogiem punktu montowania SMB.