Notatka od Zima
Dziękujemy, King_Arda, za podzielenie się tym, jak może wyglądać pierwszy serwer NAS, gdy prywatność, eksperymentowanie i nauka poprzez praktykę są równie ważne jak wygoda. Twój ZimaBlade stał się domem dla Immich, Jellyfin, Duplicati, szyfrowanych kopii zapasowych oraz zdalnego dostępu przez konfigurację WireGuard, której już ufałeś w swojej sieci.
Szczególnie doceniamy, że równie otwarcie opisałeś problemy, jak i elementy, które działały — od konfiguracji Dockera i niejasności dotyczących ścieżek przechowywania po działanie kopii zapasowych i planowanie zasilania dla drugiego dysku. Te szczegóły dają innym twórcom domowych laboratoriów bardziej użyteczny obraz tego, jak naprawdę wygląda stopniowa rozbudowa małego, samodzielnie zbudowanego serwera NAS.
— Zima
Poznaj King_Arda
King_Arda to twórca domowego laboratorium z Reddita, który w oryginalnym poście napisał, że studiuje cyberbezpieczeństwo i posiada wiedzę z zakresu sieci zdobytą podczas nauki do certyfikatu Cisco CCNA. Nie szukał wyłącznie urządzenia, które pomieściłoby pliki. Chciał serwera NAS, który mógłby stać się także praktycznym miejscem do eksperymentowania z usługami hostowanymi samodzielnie, siecią, kopiami zapasowymi i pamięcią masową.
Przed zakupem ZimaBlade porównywał bardziej konwencjonalne serwery NAS z ponownym wykorzystaniem starego komputera. Ostatecznie wybrał mniejszy system x86, ponieważ połączenie ceny, elastyczności, wyglądu i możliwości eksperymentowania odpowiadało jego oczekiwaniom wobec pierwszego serwera NAS do domowego laboratorium.
Możesz obserwować King_Arda na Reddicie, aby zobaczyć profil twórcy stojący za tą historią użytkownika.
Informacja: W oryginalnym poście na Reddicie King_Arda napisał, że skontaktował się ze wsparciem Zima po odkryciu, że jego dotychczasowy zasilacz nie był wystarczająco mocny dla planowanej konfiguracji pamięci masowej. Ujawnił, że wsparcie zapewniło bezpłatną wysyłkę w zamian za opublikowanie posta na Reddicie, zaznaczając jednocześnie, że mógł swobodnie wyrazić własną opinię. Ta historia użytkownika zachowuje tę informację oraz jego krytyczne uwagi dotyczące korzystania z konfiguracji.
Od poszukiwań serwera NAS do ZimaBlade
Przed wyborem ZimaBlade King_Arda rozważał dwa typowe rozwiązania na początek: zakup serwera NAS Synology lub ponowne wykorzystanie starego komputera. Jego poszukiwania ostatecznie skierowały go ku mniejszej platformie DIY, która mogła pełnić funkcję zarówno pamięci masowej, jak i uniwersalnego serwera domowego.
Opisywał ten wybór głównie w kategoriach opłacalności i elastyczności. Podobała mu się także szersza idea oprogramowania open source oraz większej kontroli nad usługami działającymi na urządzeniu. Było to ważne, ponieważ serwer NAS od początku nie miał pozostać urządzeniem przeznaczonym do jednego celu.
Aktualna dokumentacja ZimaBlade opisuje tę platformę jako jednopłytowy serwer x86 z dwoma złączami SATA 3.0, Gigabit Ethernetem i możliwością rozbudowy przez PCIe. Post King_Arda nie wskazuje, czy jego płyta to model 3760 czy 7700, dlatego w tej historii nie przypisujemy mu żadnego z nich.
Dlaczego ZimaOS pozostał centrum tej konfiguracji
King_Arda pozostawił ZimaOS w systemie, zamiast od razu zastępować go Windowsem, Proxmoxem lub innym systemem operacyjnym dla serwerów. Podobała mu się obsługa plików przez przeglądarkę oraz App Store, ponieważ ułatwiały wyszukiwanie i wdrażanie aplikacji Docker bez zamieniania każdego eksperymentu w projekt wymagający pracy z wierszem poleceń.
Trzy aplikacje stały się kluczowe dla tej konfiguracji: Immich do zdjęć, Jellyfin do multimediów oraz Duplicati do obsługi kopii zapasowych. Po drodze eksperymentował także z innymi aplikacjami i wtedy urządzenie zaczęło zachowywać się mniej jak prosty serwer NAS, a bardziej jak rzeczywisty węzeł domowego laboratorium.
Prywatność bez rezygnacji z kopii zapasowej poza domem
Zdjęcia były jednym z najważniejszych powodów, dla których King_Arda zdecydował się na samodzielny hosting. Napisał, że nie czuł się komfortowo, pozostawiając całą bibliotekę zdjęć wyłącznie w Google, szczególnie ze względu na obawy dotyczące wykorzystywania zdjęć przechowywanych w chmurze w związku ze sztuczną inteligencją.
Nie oznaczało to jednak całkowitej rezygnacji z pamięci masowej w chmurze. Immich zapewnił mu usługę zdjęć na sprzęcie, nad którym miał kontrolę, a Duplicati wysyłał zaszyfrowaną kopię zapasową obrazów na Dysk Google. Opisał także przenoszenie plików z Dysku z powrotem na ZimaBlade, aby żadna z lokalizacji nie była jedyną kopią.
Dzięki temu projekt miał charakter hybrydowy, a nie zero-jedynkowy: lokalne usługi zapewniały codzienną kontrolę, a szyfrowana pamięć poza domem pozostawała dodatkową warstwą kopii zapasowej.
WireGuard zamiast dodawania kolejnej warstwy zdalnego dostępu
W przypadku zdalnego dostępu King_Arda rozważał Tailscale, ale wybrał WireGuard, ponieważ jego router już go obsługiwał. Dzięki temu mógł korzystać ze znanej mu ścieżki sieciowej, zamiast dodawać kolejną usługę zdalnego dostępu wyłącznie na potrzeby serwera NAS.
Aktualne wersje ZimaOS również opisują zdalny dostęp przez ZimaClient, ale konfiguracja King_Arda pokazuje inny sposób podejścia do samodzielnego hostingu: użytkownicy, którzy już zarządzają własną siecią, mogą wybrać warstwę dostępu pasującą do pozostałej infrastruktury.
Aktualny przewodnik po zdalnym dostępie w ZimaOS opisuje ścieżkę z użyciem ZimaClient, natomiast oryginalny post na Reddicie dokumentuje odrębny wybór King_Arda — WireGuard.
Gdzie łatwa ścieżka przestała być łatwa
App Store był wygodny, ale King_Arda nie opisywał każdej instalacji jako całkowicie bezobsługowej. Napisał, że czasami musiał zmieniać fragmenty pliku Dockera, zanim aplikacja zaczęła działać zgodnie z jego oczekiwaniami.
Zgłosił także poważniejszy problem ze ścieżką przechowywania: niektóre dane wyglądały na zapisane w pamięci wewnętrznej ZimaBlade, mimo że był przekonany, iż wybrał dysk HDD. Zadania tworzenia kopii zapasowych, które według jego oczekiwań miały pobierać dane automatycznie, również nie zawsze działały zgodnie z planem.
Problemy te nie skłoniły go do porzucenia systemu, ale zmieniły typ użytkownika, któremu poleciłby to rozwiązanie. Jego doświadczenia były znacznie bardziej pozytywne dla osoby gotowej sprawdzać konfigurację i rozwiązywać problemy niż dla kogoś, kto oczekuje urządzenia, które nigdy nie ujawnia podstawowego modelu kontenerów ani pamięci masowej.
Aktualne wskazówki dotyczące ZimaOS wyraźniej określają ścieżki danych aplikacji
Aktualna dokumentacja ZimaOS zawiera teraz osobne wskazówki dotyczące pamięci aplikacji. Przewodnik po ścieżkach pamięci aplikacji zaleca umieszczanie danych aplikacji w głównej przestrzeni pamięci zamiast pozostawiania dużych, trwałych zbiorów danych na dysku systemowym. W szczególności wskazuje biblioteki zdjęć, takie jak Immich, jako obciążenia, które mogą szybko zapełnić mały dysk systemowy.
Nie dowodzi to, że dokładny problem zaobserwowany przez King_Arda został rozwiązany na jego urządzeniu. Zapewnia jednak wyraźniejsze, aktualne wskazówki dotyczące tej samej klasy problemu, z którym zetknął się podczas nauki współdziałania trwałości danych ZimaOS i Dockera.
Serwer NAS dla majsterkowiczów, nie dla każdego
Ogólna rekomendacja King_Arda była celowo warunkowa. Podobało mu się urządzenie i uważał, że spełnia jego potrzeby, ale nie poleciłby tych samych doświadczeń zupełnemu początkującemu, który oczekuje, że każda usługa zadziała bez konfiguracji i samodzielnego rozwiązywania problemów.
Dla osoby gotowej edytować ustawienia, rozumieć, gdzie znajdują się dane, i w razie potrzeby rozwiązywać problemy z kontenerem jego wnioski były znacznie bardziej pozytywne. W tym sensie ZimaBlade działał nie tylko jako pamięć masowa, lecz także jako platforma do nauki.
Najpierw jeden dysk, potem drugi
W momencie opublikowania oryginalnego posta serwer NAS działał z jednym dyskiem HDD. King_Arda planował dodać drugi dysk i użyć macierzy RAID, ale nie opublikował informacji o planowanym poziomie RAID.
W przypadku dwóch dysków aktualna dokumentacja ZimaOS uwzględnia RAID 1 jako opcję lustrzaną, podczas gdy RAID 5 wymaga co najmniej trzech dysków. To przydatny kontekst dla czytelników, ale nie należy na tej podstawie twierdzić, że King_Arda osobiście wybrał RAID 1. Jego publiczna aktualizacja kończy się na planie dodania kolejnego dysku.
Szersze możliwości opisano w aktualnym odniesieniu do RAID w ZimaOS.
Planowanie zasilania stało się częścią planowania pamięci masowej
Przejście w kierunku drugiego dysku ujawniło kolejne praktyczne ograniczenie: zasilacz w konfiguracji King_Arda nie był wystarczająco mocny dla planowanego zastosowania. To właśnie ten problem skłonił go do skontaktowania się ze wsparciem i doprowadził do ustalenia bezpłatnej wysyłki ujawnionego w poście na Reddicie.
Aktualne wskazówki dotyczące konfiguracji serwera NAS ZimaBlade również zalecają rozważenie zewnętrznego zasilania przy długotrwałym korzystaniu z dysków HDD. Oryginalny post nie zawiera modelu dysku, prądu rozruchowego, specyfikacji zasilacza ani modelu ZimaBlade, dlatego ta historia nie próbuje diagnozować dokładnego ograniczenia elektrycznego jego konfiguracji.
Mały serwer NAS, który stał się domowym laboratorium do nauki poprzez praktykę
W czasie, gdy King_Arda opisywał projekt, ZimaBlade robił znacznie więcej niż tylko przechowywał pliki. Stał się prywatnym serwerem zdjęć, urządzeniem z Jellyfin, węzłem kopii zapasowych oraz miejscem do wykorzystania wiedzy z zakresu sieci i cyberbezpieczeństwa, którą już zdobywał.
Wartość tej historii polega na tym, że nauka wynikała zarówno z sukcesów, jak i z napotkanych trudności. Musiał zdecydować, gdzie powinny znajdować się dane kontenerów, która warstwa zdalnego dostępu ma sens, jak zachować zaszyfrowaną kopię poza domem oraz co zmienia się w momencie, gdy rozbudowa pamięci masowej zwiększa wymagania dotyczące zasilania.
Historia wciąż się tworzy
Historia King_Arda i Zima wciąż się tworzy. Post na Reddicie z 31 stycznia 2026 roku przedstawia system, który był już użyteczny, ale nadal był rozbudowywany: jeden dysk HDD obsługiwał rzeczywiste obciążenia, planowano dodanie drugiego dysku i RAID, Immich oraz Jellyfin stały się codziennie używanymi usługami, Duplicati zajmował się kopiami zapasowymi, a WireGuard zapewniał zdalny dostęp.
W materiałach zweryfikowanych na potrzeby tej strony nie ma publicznej aktualizacji potwierdzającej rozbudowę o drugi dysk, ostateczną konfigurację RAID ani rozwiązanie problemów z danymi aplikacji i kopiami zapasowymi. Te kwestie powinny pozostać otwarte do czasu, aż King_Arda sam udokumentuje kolejny etap.
Aby poznać źródło tej historii, przeczytaj oryginalny post King_Arda o serwerze NAS ZimaBlade na Reddicie lub odwiedź profil King_Arda na Reddicie.
