Podążaj za instrukcjami w poniższym filmie, aby zobaczyć, jak zainstalować naszą stronę jako aplikację internetową na ekranie głównym swojego urządzenia.
Informacja: Ta funkcja może nie być dostępna w niektórych przeglądarkach.
Używasz przestarzałej przeglądarki. Może ona nie wyświetlać poprawnie tej lub innych stron internetowych. Powinieneś zaktualizować swoją przeglądarkę lub użyć alternatywnej przeglądarki.
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.
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:
Bash:
df -h
df -i
- Sprawdź użycie /tmp i / (root) oraz /mnt/HDA_ROOT:
Bash:
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:
- Logi Container Station / Docker i konkretnego kontenera:
Bash:
# 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:
Bash:
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).
- Sprawdź listę woluminów dockera i ich mapowania:
Bash:
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.
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.
MMariusz 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:
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.
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"
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.
problemem. 
