Ten wątek z kwietnia 2026 roku rozpoczął się jako szeroki post „nowy użytkownik przytłoczony przez ZimaOS”, obejmujący kopie zapasowe i samodzielnie hostowaną pocztę elektroniczną. Problem z pocztą ostatecznie stał się drugorzędny: użytkownik uruchomił Mailcow na tyle dobrze, by spełniał jego potrzeby. Nierozwiązaną kwestią techniczną pozostała Kopia zapasowa ZimaOS, w której wyświetlane rozmiary były niespójne, pierwszy przebieg zwykle dobiegał końca, a kolejne mogły zawieszać się bez dalszej aktywności dysku.
Źródło jest szczególnie przydatne, ponieważ użytkownik przetestował więcej niż jedno urządzenie ZimaBoard 2, wiele dysków wewnętrznych i zewnętrznych, sieciową lokalizację docelową Synology, a później także ZimaOS 1.6.1. Problemu nie należy więc podsumowywać jako skutku pojedynczego uszkodzonego dysku USB lub jednej nieprawidłowej ścieżki sieciowej.
Użytkownik chciał prostej kopii zapasowej na wypadek awarii, a nie formatu archiwum
Pożądany przepływ pracy był prosty: ręcznie uruchamiać kopię zapasową w stylu 1:1, zachować rozpoznawalną strukturę folderów, unikać szyfrowania lub nieprzejrzystych pakietów i móc szybko odzyskać dane w razie całkowitej awarii ZimaBoard 2.
To oczekiwanie różni się od oprogramowania do tworzenia kopii wersjonowanych, które celowo przechowuje kopie historyczne. Gdy włączone jest przechowywanie wersji, wykorzystanie miejsca docelowego może zasadnie przekraczać rozmiar bieżącego zbioru danych źródłowych.
Problem po stronie serwera pocztowego został ostatecznie oddzielony
Oryginalny post opisywał również trudności z zastąpieniem Synology Mail Plus. Zima-Jerry zasugerował Stalwart, ale użytkownik potrzebował konkretnie pobierania wiadomości przez POP3. 16 kwietnia użytkownik poinformował, że Mailcow działał, a pozostałe aplikacje były wystarczające.
Warto zachować ten rezultat, ponieważ zapobiega on późniejszemu błędnemu odczytaniu dyskusji o Kopii zapasowej jako dowodu, że to sam Mailcow spowodował problem z pamięcią masową.
Rozmiary miejsca docelowego kopii zapasowej nie odpowiadały rzeczywistości
Na jednej płycie około 800 GB w źródle odpowiadało około 2,7 TB w katalogu docelowym. Na innej około 105 GB w źródle oznaczało brak około 2 GB w miejscu docelowym.
Przechowywanie wersji może wyjaśniać część wzrostu, ale nie zawieszenie drugiego uruchomienia
Zima-Jerry zapytał, czy włączona była funkcja „zachowywania wersji”. Przechowywanie poprzednich wersji może prawidłowo powodować, że miejsce docelowe kopii zapasowej jest większe niż bieżące źródło na żywo.
Jednak później użytkownik źródłowy zresetował test, używając nowo sformatowanego zewnętrznego dysku USB, i udokumentował inny błąd: pierwsza kopia zapasowa zakończyła się powodzeniem, druga skopiowała część danych, a następnie przestała wykazywać postęp.
Test z czystym dyskiem USB odtworzył błąd drugiego uruchomienia
Użytkownik usunął stare zadania, uruchomił ponownie ZimaBoard 2, sformatował zewnętrzny dysk i utworzył nową ręczną kopię zapasową z włączonymi wersjami. Pierwsze uruchomienie trwało prawie dwa dni i pomyślnie skopiowało około 1,25 TB.
Po odłączeniu i ponownym podłączeniu dysku przez aplikację Pliki drugie uruchomienie skopiowało część zmian, po czym pasek postępu się zawiesił, a dioda aktywności USB zgasła. Takie samo zachowanie wystąpiło w przypadku miejsca docelowego Synology.
IceWhale eskalowało problem z działaniem kopii zapasowej
Zima-Jerry podziękował użytkownikowi za przeprowadzenie kontrolowanych testów i powiedział, że problem zostanie przekazany zespołowi programistów do zbadania.
W późniejszej odpowiedzi związanej z IceWhale rozdzielono dwa znane obszary problemowe: tworzenie kopii zapasowej wszystkich /media/ZimaOS-HD wcześniej obejmowało zawartość potoków i gniazd Dockera, a dokładność wyświetlania postępu tworzenia kopii nadal wymagała poprawy.
Tworzenie kopii zapasowej całego dysku systemowego to nie to samo co obraz systemu możliwy do przywrócenia
Później dyskusja zeszła na odzyskiwanie po awarii. Odpowiedź zespołu wyjaśniła, że bezmyślne tworzenie kopii zapasowej całego dysku systemowego obejmuje zbędne pliki Dockera i środowiska uruchomieniowego, a także nie zapewnia automatycznie obsługiwanego procesu „przywróć ten folder, a cały system ZimaOS wróci dokładnie do poprzedniego stanu”.
Na potrzeby planowania awaryjnego rozróżnij dane użytkownika, dane aplikacji, bazy danych, konfigurację oraz zastępowalne obrazy kontenerów.
ZimaOS 1.6.0 zmienił metadane odzyskiwania pamięci
W późniejszej oficjalnej odpowiedzi stwierdzono, że począwszy od ZimaOS 1.6.0, informacje opisujące sposób montowania urządzenia pamięci masowej są również zapisywane na samym urządzeniu. Celem było ułatwienie ponownego rozpoznawania pamięci RAID lub pojedynczego dysku po awarii dysku systemowego.
Poprawia to odzyskiwanie macierzy, ale nie zmienia RAID w kopię zapasową i samo w sobie nie naprawia zawieszania się kopii zapasowej przy drugim uruchomieniu u autora problemu.
Użytkownik nadal odtwarzał problem w ZimaOS 1.6.1
27 kwietnia autor oryginalnego posta poinformował, że pierwsza kopia zapasowa nadal działała, ale drugie i kolejne uruchomienia zawieszały się na ponad sześć godzin bez dalszego zapisywania danych. Zamknięcie i ponowne otwarcie modułu Kopia zapasowa mogło wyświetlić miejsce docelowe jako 0 B.
Stwierdzili, że ten schemat został przetestowany z czterema dyskami wewnętrznymi, dwoma zewnętrznymi dyskami USB i trzema systemami ZimaBoard 2.
Obecny proces tworzenia kopii zapasowych ewoluował
Obecna dokumentacja ZimaOS opisuje teraz zaplanowane zadania tworzenia kopii zapasowych w lokalnych, USB, NAS i chmurowych miejscach docelowych jako element strategii 3-2-1.
Korzystaj z obecnego procesu tworzenia kopii zapasowych ZimaOS i dostępnych miejsc docelowych, zamiast zakładać, że interfejs wersji 1.5.x/1.6.1 działa dziś identycznie.
Sam obecny przewodnik nie dowodzi, że usunięto każdy opisany w tym wątku historyczny błąd występujący przy drugim uruchomieniu, dlatego zweryfikuj rzeczywiste działanie przywracania na używanej wersji.
Zweryfikuj kopię zapasową poza paskiem postępu
- w miarę możliwości porównać liczbę plików w źródle i miejscu docelowym;
- sprawdzić rzeczywistą pojemność miejsca docelowego, a nie tylko informacje w interfejsie kopii zapasowej;
- przetestować drugie i trzecie uruchomienie przyrostowe lub wersjonowane;
- przywrócić reprezentatywne pliki w innej lokalizacji;
- dokumentować, które bazy danych aplikacji i ustawienia trzeba tworzyć w kopii zapasowej oddzielnie.
Często zadawane pytania dotyczące kopii zapasowych w ZimaOS
Czy problem ze źródłem występował wyłącznie w przypadku serwera NAS firmy Synology?
Nie. Użytkownik odtworzył podobne zawieszanie się przy użyciu zewnętrznego dysku USB.
Czy pierwsza kopia zapasowa zakończyła się niepowodzeniem?
Kontrolowane pierwsze uruchomienie zakończyło się pomyślnie; powtarzający się problem pojawiał się przy kolejnych uruchomieniach.
Czy problem zniknął w ZimaOS 1.6.1?
Nie. Autor oryginalnego posta wyraźnie stwierdził, że problem nadal występował w tym miejscu.
Czy miejsce docelowe kopii zapasowej może być zgodnie z prawem większe niż bieżące źródło?
Tak, gdy włączone jest przechowywanie wersji, ale nie wyjaśnia to każdego objawu wyświetlania ani zawieszania zadań opisanego w wątku.
