Dyskusja Zanikające pliki usług postawionych w Container station

[smolam]

Dzień dobry.

Borykam się z dziwnym (może tylko dla mnie problemem.
Mam w firmie QNAP-a, który służy głownie jako serwer baz danych postawionych na Docker. Są to dwa osobne serwery po jednym na każdą z baz.
Jestem w trakcie wdrażania systemu MES (do zarządzania produkcją). System jest tak przygotowany, że skalda się z kilku usług każda w osobnym kontenerze.
Firma która wdraża u minie ten system, postawiła całe środowisko i wszytko ładnie działało aż któregoś dnia, system przestał odpowiadać.

Chłopaki sprawdzili co się dzieje i okazało się, że kontenery działają ale zniknęły wszystkie pliki z przypisanych do niech storage.
Sprawdzili, z poziomu SUDO, logi i nie znaleźli nic co mogło by sugerować co się stało.
Uznaliśmy, że to jakiś przypadek i postawili wszytko od nowa. Ponownie działało jakiś czas do momentu aż sytuacja się powtórzyła.
I ponownie w logach kompletnie nic nie widać a plików brak.

Co przegapiliśmy? W jakiej sytuacji QTS może usuwać pliki? Jak sprawdzić co się dzieje i zapobiec temu w przyszłości?
Powiem tylko, że bazy działają poprawnie i z niemi nic się nie dzieje.

Z góry dziękuję za pomoc.

 

[QNAP AI Assistant]

Krótko: najczęściej powodami „znikania” plików w Container Station są: użycie tymczasowych katalogów (tmpfs lub /mnt/HDA_ROOT) zamiast trwałego share (np. /share/Container), automatyczne czyszczenie /tmp przy restarcie, konwersja sterownika storage (overlay → overlay2) lub aktualizacja/operacja systemowa, która usuwa anonimowe woluminy kontenerów. Działaj szybko: wykonaj pełny backup danych kontenerów i obrazów, potem przeanalizuj poniższe punkty kontrolne i wprowadź zabezpieczenia.

1) Pierwsze bezpieczeństwo (natychmiast)

• Zrób kopię zapasową folderów, obrazów i konfiguracji Container Station (eksport kontenerów i obrazów). To najważniejsze przed analizą.
• Jeśli podejrzewasz, że dyski nadal mają dane, unikaj zapisu na nich — każda operacja może utrudnić odzyskanie.

2) Co najczęściej „usuwa” pliki w QTS / Container Station — przegląd przyczyn

• /tmp jest tmpfs — czyści się przy restarcie systemu. Jeśli kontenery miały mounty do /tmp (wewnątrz NAS), dane znikają po reboocie.
• /mnt/HDA_ROOT (party j systemowa) ma ograniczoną pojemność; QTS może usuwać/rotować pliki tymczasowe, update_pkg lub logi, a przy krytycznym braku miejsca usługi mogą zachowywać się niestandardowo.
• Container Station przy migracji/konwersji sterownika storage (np. overlay → overlay2) może wymagać usunięcia i ponownego importu kontenerów; anonimowe woluminy powiązane z kontenerami mogą zostać utracone, jeżeli nie zrobiono eksportu przed konwersją.
• Automatyczne zadania (cron, harmonogramowane zadania QTS, skrypty zewnętrzne/QPKG) mogą wykonywać czyszczenia lub synchronizacje, które kasują pliki.
• Błędy montowania udziałów (np. kontener miał mapowanie do udziału, który w danym momencie był odmontowany) — wtedy kontener zapisał dane gdzie indziej (np. lokalnie w warstwie obrazu), które potem zostały utracone przy re-rysowaniu/aktualizacji kontenera.
• Usługi systemowe, sprawdzanie systemu plików lub nieprawidłowe przywrócenie ustawień (restore settings) mogą zmienić konfigurację share/udostępnień i spowodować „brak” plików (udostępnienia przeniesione/usunięte).
• Możliwe też: błędny skrypt aplikacji w kontenerze, który usuwa pliki według reguł (np. rotacja logów bez kryterium) — to jest po stronie aplikacji.

3) Co sprawdzić od razu (lista kroków diagnostycznych)
(Uwaga: poniższe komendy uruchom przez SSH z uprawnieniami root; przed wykonywaniem skopiuj ważne pliki)
- Sprawdź zajętość przestrzeni:

df -h
df -i

- Sprawdź użycie /tmp i / (root) oraz /mnt/HDA_ROOT:

du -sh /tmp /mnt/HDA_ROOT /share 2>/dev/null
ls -la /tmp

- Sprawdź logi systemowe QTS:
przejrzyj Centrum logów (Event Logs) w GUI oraz pliki /var/log, /var/log/messages, dmesg:

dmesg | tail -n 200
tail -n 500 /var/log/messages
tail -n 500 /var/log/syslog

- Logi Container Station / Docker i konkretnego kontenera:

# lista kontenerów i ich status
docker ps -a
# logi kontenera
docker logs <container-id>
# logi Container Station - lokalizacja może się różnić, sprawdź w GUI "Pobierz logi"

- Sprawdź, czy były ostatnio operacje konwersji storage/aktualizacje Container Station:
przejrzyj Event Logs w GUI (dział System / Dziennik zdarzeń) na wpisy związane z Container Station, overlay, storage driver, aktualizacjami o konkretnej godzinie zniknięcia.
- Sprawdź cron i harmonogram zadań QTS:
przejrzyj /etc/crontab i zadania użytkowników root oraz harmonogramy w GUI (Panel sterowania → Harmonogram).
- Czytanie otwartych (usuń) plików — pliki usunięte ale otwarte są nadal widoczne:

lsof +L1
# albo dla konkretnego wolumenu
lsof | grep /share/QnapShareName

- Sprawdź, czy udział, na który były mapowane wolumeny kontenerów, pozostaje w tej samej lokalizacji (/share/...) i czy ma poprawne uprawnienia UID/GID używane przez kontenery.

4) Specyfika Container Station i storage drivers (ważne)

• Container Station historycznie używała drivera overlay/aufs — konwersja do overlay2 lub zmiana sposobu przechowywania obrazów może wymagać reimportu kontenerów i usunięcia anonimowych woluminów. FAQ QNAP wyraźnie mówi: przed konwersją wykonaj eksport/kopie zapasowe i zanotuj ID anonimowych woluminów.
• Jeśli kontenery używały anonimowych woluminów (nie mapowane do shareów typu /share/xxx), dane były trzymane wewnątrz storage Dockera i łatwo je stracić przy usunięciu kontenera lub czyszczeniu storage.
• Zalecenie: zawsze mapować wolne dane kontenerów na hostowy udział QNAP (np. /share/Containers/<service>) zamiast trzymać je w warstwie obrazu/anonimowym woluminie.

5) Zapobieganie utracie danych — dobre praktyki

• Mapuj wolumeny kontenerów do trwałych udziałów: używaj ścieżek z /share/<volume> (udostępniony katalog w QTS). Dzięki temu QTS nie skasuje danych podczas restartu/aktualizacji.
• Nie używaj /tmp ani katalogów systemowych jako miejsca przechowywania danych aplikacji.
• Przed aktualizacją QTS/Container Station lub konwersją storage zrób eksport wszystkich kontenerów i snapshot/share.
• Włącz snapshoty (jeśli na QTS: Storage & Snapshots) dla krytycznych udziałów i planuj regularne backupy poza NAS (np. inne NAS, chmura, taśmy).
• Monitoruj wykorzystanie /tmp i /mnt/HDA_ROOT; ustaw alerty w Centrum Powiadomień (threshold ~80%).
• Unikaj QPKG lub skryptów trzecich, które przechowują dane na partycji systemowej; konfiguruj tak, aby korzystały z /share.
• Sprawdzaj i ogranicz rotację logów w kontenerach (logrotate) oraz log-driver Dockera (np. max-size, max-file).
• Oznacz anonimowe woluminy: używaj jawnych volumeów dockerowych mapowanych do udziałów QNAP.
• Przed migracją lub przywracaniem ustawień systemowych upewnij się, że backup obejmuje udziały i konfigurację Container Station.

6) Jak odtworzyć/odkryć co się stało (przydatne polecenia)
- Szukaj plików usuniętych w czasie zbieżnym z problemem w /var/log/messages i event logs:

grep -i "container" /var/log/messages | tail -n 200
grep -i "overlay" /var/log/messages
grep -i "update_pkg" /var/log/messages

- Sprawdź listę woluminów dockera i ich mapowania:

docker volume ls
docker inspect <volume-name>   # pokaże mountpoint

- Sprawdź, czy ktoś/usługa wykonała przywrócenie ustawień: w logach systemowych znajdź restore/restore_config/restore_settings.

7) Co robić, jeśli już utraciłeś dane

• Natychmiast wykonaj kopię sektorową (image) dysków jeśli dane są krytyczne i rozważ kontakt z pomocą QNAP lub firmą odzysku (przy RAID lepiej nie działać na żywo).
• Jeśli dane były na anonimowych woluminach dockera, spróbuj listy woluminów docker (docker volume ls) i sprawdź mountpoint (może dane są nadal na dysku, choć niepowiązane z kontenerem).
• Możesz spróbować narzędzi do odzyskiwania plików z EXT4 (jeśli QTS) lub z ZFS (jeśli QuTS hero — tu raczej snapshoty). Ale to jest ryzykowne i wymaga ostrożności.

8) Różnice QTS vs QuTS hero (ważne przy analizie)

• QTS (ext4/lvm): /tmp jako tmpfs, /mnt/HDA_ROOT partycja systemowa; QTS automatycznie rotuje/usuwa update_pkg i logi. Sprawdzanie FS może odmontować wolumin.
• QuTS hero (ZFS): snapshoty i samonaprawa, inne mechanizmy zarządzania danymi; konwersje storage containers też mają swoje niuanse. Jeśli używasz QuTS hero, sprawdzaj historyczne snapshoty i pool events zamiast /var/log/messages. (Zalecenie: snapshoty przed zmianami.)

9) Krótkie podsumowanie — checklist do wykonania teraz
1. Natychmiast: wykonaj backup wszystkich danych kontenerów i obrazów (eksport).
2. Sprawdź df -h, du dla /tmp, /mnt/HDA_ROOT i /share.
3. Przejrzyj dzienniki systemowe (Event Logs) w czasie, gdy pliki zniknęły; szukaj wpisów o Container Station, overlay, konwersji, aktualizacji, czyszczeniu dysków.
4. Sprawdź docker volumes i mapowania (docker inspect) — szukaj anonimowych woluminów.
5. Upewnij się, że kontenery trzymają dane w /share/..., a nie w /tmp ani w anonimowych woluminach.
6. Wprowadź snapshoty/backup i blokadę automatycznych operacji na krytycznych udziałach.
7. Przed każdą aktualizacją Container Station/firmware: eksport kontenerów i pełny backup.

Ostrzeżenie końcowe: operacje na woluminach, sprawdzanie systemu plików czy migracja storage mogą trwale usunąć anonimowe woluminy kontenerów. Zrób kopię zapasową przed jakąkolwiek zmianą i przenieś trwałe dane kontenerów na udziały typu /share.

Źródła na forum:

• Jak sprawdzić użycie przestrzeni /tmp i /mnt/HDA_ROOT przez terminal SSH?
• Znikające dane z dysku
• Co zrobić, gdy NAS zgłasza komunikat „File system is not clean."?
• Problem z przywróceniem ustawień systemu
• Jak pobrać logi oprogramowania QNAP do rozwiązywania problemów
• Ograniczenie Snapshot Replica po uaktualnieniu do QuTS hero h5.3

Ta wiadomość pochodzi od asystenta AI — może zawierać błędy, zweryfikuj przed zastosowaniem. Oceń ją, głosując pod postem: ▲ pomocna lub ▼ nieprzydatna.

Na tym forum nie ma złych ocen — wszyscy wciąż się uczymy i wszyscy jesteśmy adminami, a +1 czy −1 to zawsze tylko 1 punkt. Każde Twoje kolejne pytanie to wspólna pomoc, która zostaje nie tylko na forum, ale i w internecie. Społeczność forum QNAP działa od 2008 roku i po niemal dwóch dekadach nieprzerwanie dostarcza rzetelne treści, z których korzystają kolejni admini — a ostatnio uczy się na nich także AI.

 

[Silas Mariusz]

Jak powyżej. Gdzie są zamontowane dane? A może jakiś zewnętrzny soft korzysta z tych plików?

Połączono posty: 30 minut temu

Po za tym chłopaki sprawdzili. Uja sprawdzili. Zostawiliby lsof w petli lub doinstalowali inotify z opkg. Chłopaki nie mają pojęcia co robią.

 

[smolam]

M Mariusz jestem daleki od oceny kompetencji innych ludzi po tym, co ktoś o nich napisał w internecie. Jeżeli chcesz pomoc to odnoś się do przedstawionego problemu a nie obrażaj osób których nie znasz.
Ja też nie jestem alfą i omega dlatego zwracam się o pomoc do osób mądrzejszych ode mnie w konkretnym aspekcie.

Z tego co widzę w zakładce "Woluminy" Container station to ścieżki wygladaja przykładowo tak:

• /share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/backend_storage/_data
• /share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/postgres_data/_data

 

[Silas Mariusz]

Ależ nikogo nie obrażam. Jeśli są chłopakami od wdrożenia - czyli biorą za to kasę, to ich obowiązkiem jest wiedzieć takie rzeczy - zwłaszcza że jest to elementarna wiedza nt linuxa, czyli notabene platformy „ich” softu. Skoro są to tylko te katalogi, to tak jak wyżej napisałem + dokładny debug z ich strony. Samo nigdy nic nie znika.

 

[pecet]

wydaje się, że pierwsza odpowiedz jest wystraczająca i nie ma co opowiadać o chłopakach (offtop).

 

[smolam]

Ależ nikogo nie obrażam. Jeśli są chłopakami od wdrożenia - czyli biorą za to kasę, to ich obowiązkiem jest wiedzieć takie rzeczy - zwłaszcza że jest to elementarna wiedza nt linuxa, czyli notabene platformy „ich” softu. Skoro są to tylko te katalogi, to tak jak wyżej napisałem + dokładny debug z ich strony. Samo nigdy nic nie znika.

Ok, pewnie masz racje ale czy nie może za to odpowiadać, jakiś specyficzny element architektury QNAP-a, wbrew pozorom to nie jest powszechne rozwianie i nie każdy musi znać jego wszystkie tajniki
Dla minie istotne jest znalezienie przyczyny i rozwiązania i wszelkie osobiste wycieczki są, w mojej ocenie, niepotrzebne Dlatego jak napisałe pecet, koniec o "chłopakach"

 

[SiewcaRyżu]

Chłopaki sprawdzili co się dzieje i okazało się, że kontenery działają ale zniknęły wszystkie pliki z przypisanych do niech storage.

tak więc - gdzie każda aplikacja w kontenerze zapisuje dane ? czy ta właśnie ścieżka jest wyciągnięta poza kontener - albo poprzez wolumen albo bind (po chłopsku , do folderu w NASie poza folderem dockera).
najczęściej dane znikają bo są zapisane w kontenerze ale nie w takiej ścieżce i odtworzenie kontenera zabija dane - co jest przedszkolnym błędem.

Zdecydowanie polecam żeby dane trzymać na osobnym fizycznym nośniku niż system qnapa i tutaj bind sprawuje się najlepiej.

 

[smolam]

tak więc - gdzie każda aplikacja w kontenerze zapisuje dane ? czy ta właśnie ścieżka jest wyciągnięta poza kontener - albo poprzez wolumen albo bind (po chłopsku , do folderu w NASie poza folderem dockera).
najczęściej dane znikają bo są zapisane w kontenerze ale nie w takiej ścieżce i odtworzenie kontenera zabija dane - co jest przedszkolnym błędem.

Zdecydowanie polecam żeby dane trzymać na osobnym fizycznym nośniku niż system qnapa i tutaj bind sprawuje się najlepiej.

Masz na myśli fizyczny dysk poza QNAP podłączony do QNAP?

 

[SiewcaRyżu]

nie - inny dysk w nasie

 

[pecet]

tzn. także, że podczas wstępnej konfiguracji Qnap zalecane jest by dysk systemowy znajdował się poza pulą (osobny wolumin). Jeśli tak nie jest to trzeba dodać osobny dysk poza pulą (nowy wolumin) i na nim zapisywać dane z kontenerów.