Rozpoczęcie dziś od jednego dysku NVMe i przejście później na RAID to rozsądny plan dla serwera domowego, ale bezpieczna ścieżka migracji nie polega na kliknięciu „Konwertuj JBOD na RAID”. W wątku źródłowym z lutego 2026 roku zalecano kontrolowany proces utworzenie kopii zapasowej → utworzenie nowej macierzy → przywrócenie danych → weryfikacja, zamiast zakładać, że ZimaOS może przekształcić istniejącą pamięć na jednym dysku bezpośrednio na miejscu.
Od czasu tego wpisu narzędzia migracji w ZimaOS zostały ulepszone. Ustawienia > Migracja danych umożliwiają teraz przenoszenie obrazów Dockera, danych aplikacji Dockera oraz baz danych użytkownika ZimaOS między przestrzeniami pamięci. Ułatwia to migrację stanu aplikacji, ale nadal nie pozwala przekształcić używanego pojedynczego dysku w nadmiarową macierz RAID 1/5 bez oddzielnej macierzy docelowej.
Użytkownik źródłowy rozpoczął od jednego dysku NVMe i dysku USB na kopie zapasowe
System korzystał z wbudowanej pamięci eMMC na potrzeby ZimaOS, jednego dysku SSD NVMe skonfigurowanego jako pamięć JBOD oraz dysku twardego USB do tworzenia kopii zapasowych. Użytkownik chciał później dodać kolejne dyski NVMe i przenieść wszystko do macierzy RAID 1 lub RAID 5.
To dokładnie sytuacja, w której zachowanie zweryfikowanej, niezależnej kopii zapasowej ma znaczenie, ponieważ zmiana topologii pamięci może wymagać inicjalizacji nowych dysków, a ostatecznie także wymazania starego układu z jednym dyskiem.
Nie zakładaj, że JBOD z jednym dyskiem można przekonwertować bezpośrednio na miejscu
Odpowiedź społeczności wskazywała, że interfejs pamięci masowej ZimaOS nie udostępniał obsługiwanego procesu konwersji pojedynczego dysku JBOD → RAID. Zamiast tego zalecano utworzenie nowej macierzy z nieużywanych dysków.
Obecna publiczna dokumentacja pamięci masowej obsługuje już dodawanie dysków do niektórych istniejących układów RAID, szczególnie rozbudowę RAID 5, ale różni się to od konwersji nieredundantnej przestrzeni z jednym dyskiem na RAID bezpośrednio na miejscu.
Twórz kopię zapasową nie tylko oczywistych folderów udostępnionych
Przed zmianą pamięci zabezpiecz:
- zwykłe pliki udostępnione;
- dane aplikacji Dockera;
- niestandardowe foldery montowane przez bind mount;
- bazy danych aplikacji;
- definicje Compose/YAML niestandardowych aplikacji;
- ważne konfiguracje, które nie są odtwarzane automatycznie.
Kopię zapasową należy zweryfikować przez faktyczne otwarcie reprezentatywnych plików lub wykonanie testowego przywracania, a nie tylko sprawdzenie, czy zadanie zostało oznaczone jako ukończone.
Utwórz nową macierz RAID przed wymazaniem starego dysku
Najbezpieczniejsza architektura migracji polega na pozostawieniu oryginalnego dysku NVMe nietkniętego podczas tworzenia RAID na nowo dodanych dyskach. Dzięki temu oryginalna pamięć pozostaje dodatkowym źródłem odzyskiwania danych do czasu zweryfikowania nowej macierzy.
Obecny ZimaOS obsługuje tworzenie macierzy w Ustawieniach > Pamięć. Skorzystaj z obecnego procesu konfiguracji pamięci ZimaOS, zamiast odtwarzać stare ręczne procedury mdadm.
Wybierz RAID 1 lub RAID 5 na podstawie liczby dysków i planów rozbudowy
RAID 1 to proste lustrzane odbicie na dwóch dyskach. RAID 5 wymaga co najmniej trzech dysków i poświęca pojemność jednego dysku w zamian za tolerancję awarii jednego dysku.
Obecna dokumentacja ZimaOS przedstawia RAID 5 jako rozwiązanie dla rosnącej biblioteki i informuje, że z czasem można dodawać kolejne dyski. RAID 5 może więc być atrakcyjny, jeśli użytkownik przewiduje rozbudowę puli po początkowej migracji.
Obecna funkcja migracji danych może przenosić zarządzane dane ZimaOS
Obecna dokumentacja IceWhale informuje, że Ustawienia > Migracja danych umożliwiają przenoszenie:
- obrazów Dockera;
- danych aplikacji Dockera;
- baz danych użytkownika, takich jak Galeria, Pobrane, Dokumenty, Multimedia i Kopie zapasowe.
Użyj obecnego procesu migracji danych ZimaOS po utworzeniu pamięci docelowej.
Niestandardowe bind mounty nadal wymagają ręcznej weryfikacji
Wbudowane kategorie migracji nie gwarantują, że każda niestandardowa ścieżka hosta w każdym stosie Compose zostanie automatycznie przepisana. Sprawdź aplikacje, które montują nietypowe foldery poza standardowymi lokalizacjami zarządzanymi przez ZimaOS.
Po migracji sprawdź mapowanie woluminów każdej ważnej aplikacji i potwierdź, że folder po stronie hosta wskazuje na nową pamięć.
Zweryfikuj nową macierz RAID przed zmianą przeznaczenia oryginalnego dysku NVMe
Potwierdź, że:
- macierz RAID ma status sprawnej;
- ważne foldery udostępnione zawierają oczekiwane pliki;
- aplikacje Dockera uruchamiają się, a ich bazy danych są nienaruszone;
- uprawnienia działają z poziomu zwykłych klientów;
- zadania kopii zapasowych wskazują zamierzone źródło i miejsce docelowe.
Dopiero wtedy należy wymazać oryginalny dysk NVMe lub wykorzystać go ponownie.
Zachowaj kopię zapasową na USB po przejściu na RAID
RAID chroni dostępność danych w przypadku awarii dysku wchodzącego w skład macierzy. Nie chroni przed przypadkowym usunięciem, oprogramowaniem ransomware, uszkodzeniem aplikacji, kradzieżą ani utratą całego serwera.
Kopia zapasowa na USB z planu źródłowego pozostaje przydatna po migracji do RAID i może stać się elementem szerszej strategii 3-2-1.
Najczęstsze pytania dotyczące migracji z JBOD do RAID
Czy obecny ZimaOS może przenosić dane AppData między przestrzeniami pamięci?
Tak. Obecne narzędzie Migracja danych obejmuje dane aplikacji Dockera i obrazy Dockera.
Czy oznacza to, że pojedynczy dysk JBOD można przekonwertować bezpośrednio na RAID 1?
Nie. Przenoszenie danych i zmiana topologii pamięci to odrębne operacje.
Kiedy można wymazać oryginalny dysk?
Dopiero po zweryfikowaniu nowej macierzy, plików, stanu aplikacji, uprawnień i kopii zapasowych.
