Założenia, wymagania i sensowny zakres domowego serwera
Co realnie ma sens na domowym serwerze, a co jest przerostem formy
Domowy serwer na Ubuntu Server najczęściej spełnia trzy główne role: serwer plików (wspólny dysk sieciowy dla komputerów), serwer multimediów (filmy, muzyka, zdjęcia na TV, konsoli, telefonach) oraz miejsce na kopie zapasowe. Dla większości użytkowników to już ogromny skok jakościowy względem pojedynczych dysków USB podpinanych do laptopa.
Do rozsądnego zestawu usług można jeszcze dołożyć kilka lekkich dodatków: prywatną chmurę na pliki (np. Nextcloud), prosty serwer VPN do dostępu spoza domu czy lokalny serwer Git dla własnych projektów. Każda kolejna usługa zwiększa jednak złożoność utrzymania, zużycie zasobów i ryzyko błędów konfiguracyjnych, więc rozsądniej jest zaczynać od absolutnego minimum.
Fanaberią staje się zestaw, w którym na jednym, starym, hałaśliwym PC próbuje się uruchomić na raz: serwer gier, kilkanaście kontenerów, ciężki system monitoringu, a do tego repozytorium multimediów w 4K. Technicznie to możliwe, ale w domowych warunkach zwykle kończy się niestabilnością, hałasem i ogromnym zużyciem prądu. Bez doświadczenia w administracji lepiej podejść do tematu etapami: najpierw pliki i multimedia, potem stopniowe dokładanie usług.
Różnica między prostym NAS-em a serwerem na Ubuntu polega głównie na elastyczności i odpowiedzialności. NAS (np. Synology czy QNAP) to urządzenie „prawie gotowe” – producent narzuca strukturę systemu i ogranicza możliwości, za to wiele rzeczy działa z pudełka. Ubuntu Server daje swobodę: można dobrać system plików, usługi i sposób udostępniania dokładnie pod własne potrzeby, ale wymaga to czasu, czytania dokumentacji i minimalnego ogarnięcia terminala.
NAS a Ubuntu Server – różnice, które mają znaczenie w praktyce
Typowy NAS kusi prostą konfiguracją przez przeglądarkę, gotowymi aplikacjami do multimediów i automatycznymi aktualizacjami. W zamian użytkownik akceptuje ograniczenia: zamknięty system, trudną lub niemożliwą rozbudowę o niestandardowe usługi, często gorszą wydajność virtualizacji i kontenerów. Dla kogoś, kto chce po prostu trzymać filmy i robić backup zdjęć z telefonu, NAS będzie wygodną opcją.
Ubuntu Server na zwykłym PC lub miniPC to podejście „zrób to sam”. Konfiguracja wymaga kilku wieczorów, ale w efekcie można:
łatwo przenosić konfiguracje między maszynami (to w końcu pełny system Linux),
korzystać z ogromnej ilości dokumentacji i społeczności linuksowej,
samodzielnie decydować o bezpieczeństwie, kopiach zapasowych i aktualizacjach.
Minimalne i komfortowe wymagania sprzętowe
Oficjalnie Ubuntu Server uruchomi się na bardzo skromnym sprzęcie. Dla domowego serwera plików i multimediów minimalnie rozsądna konfiguracja to:
CPU: dowolny 64-bitowy procesor x86_64 (nawet starsze Core2Duo czy pierwsze i3),
RAM: 4 GB jako absolutne minimum, 8 GB daje dużo większy komfort,
Dyski: jeden SSD 60–120 GB na system + osobne HDD na dane (min. 1–2 TB),
Sieć: karta Gigabit Ethernet (1 Gb/s) jako standard, Wi-Fi tylko awaryjnie.
Do zwykłego udostępniania plików i streamowania filmów FullHD nawet starszy procesor poradzi sobie bez problemu. Kłopoty zaczynają się przy transkodowaniu wideo (np. Plex przekodowujący film 4K na urządzenie mobilne). W takich zastosowaniach przydają się nowocześniejsze jednostki z obsługą sprzętowego kodowania wideo (Intel Quick Sync, dekodery w nowszych Ryzenach), ewentualnie GPU obsługiwane przez używane oprogramowanie.
Większość domowych scenariuszy nie wymaga serwerowych procesorów Xeon ani 64 GB RAM. To przydaje się dopiero wtedy, gdy Ubuntu Server ma równocześnie pełnić rolę platformy do testów wirtualizacji, wielu kontenerów albo małego „labu” w stylu Proxmox. Do prostego serwera plików i multimediów sensowniej jest zainwestować w cichy zasilacz, dyski o większej pojemności i niezawodne chłodzenie.
Typowe scenariusze domowe i priorytety na start
Domowy serwer Ubuntu można projektować pod konkretne, dość powtarzalne sytuacje:
Jeden komputer + kilka laptopów: serwer głównie do wspólnego katalogu na dokumenty, zdjęcia i prosty streaming filmów. Kluczowe: cisza, niski pobór prądu, prostota obsługi.
Rodzina z konsolą/TV smart: nacisk na serwer multimediów, kompatybilność z telewizorami (DLNA, aplikacje), wygoda dostępu z telefonów. Tu liczy się stabilna sieć i szybkie dyski na filmy.
Domowy „lab”: jedna maszyna robi za serwer plików, kontenery Dockera, ewentualnie VM-ki. Liczy się RAM, CPU i elastyczność konfiguracji. W takim scenariuszu Ubuntu Server bywa też bazą pod KVM lub Proxmox.
Niezależnie od scenariusza, na starcie najbardziej opłaca się zadbać o: stabilne zasilanie, chłodzenie i dyski. RAID, kontenery, monitoring i rozbudowane automatyzacje to elementy, które można dołożyć później, gdy podstawowy serwer plików i multimediów działa stabilnie przez kilka tygodni. Zbyt szybkie wchodzenie w złożone konfiguracje bez zrozumienia zwykle kończy się utratą danych albo długimi wieczorami na ratowanie systemu.
Źródło: Pexels | Autor: Brett Sayles
Wybór sprzętu i architektury: od starego PC po „prawie-NAS”
Stary PC, miniPC, sprzęt serwerowy, Raspberry Pi – plusy i minusy
Domowy serwer Ubuntu Server można zbudować praktycznie na wszystkim: od odziedziczonego po kimś PC, przez miniPC typu NUC, po używane serwery rackowe czy Raspberry Pi. Wybór wpływa głównie na hałas, pobór prądu i możliwości rozbudowy.
Stary PC / desktop to najczęstszy start. Zaletą jest niski koszt (często sprzęt „z szafy”), możliwość zamontowania kilku dysków HDD i łatwy dostęp do części. Minusy: większy pobór energii, bywa głośny, a bardzo stary sprzęt może nie mieć sprawnego zasilacza czy obsługi nowoczesnych standardów (np. szybkiego SATA, UEFI w sensownym wydaniu).
MiniPC / Intel NUC to świetna baza dla cichego, energooszczędnego serwera. Zwykle mają 1–2 zatoki na dysk 2,5″ + slot M.2 dla SSD, gigabitowy Ethernet i niskie zużycie prądu. Trzeba tylko sprawdzić, ile RAM można realnie w nich zamontować i czy posiadają aktywne chłodzenie, które przy obciążeniu nie zamieni się w małą suszarkę.
Sprzęt klasy serwerowej (racki, duże tower serwery) jest bardzo kuszący w ogłoszeniach, ale mało kto w domu godzi się na ich hałas i apetyt na energię. To sprzęt projektowany do serwerowni, a nie do pokoju obok sypialni. Sprawdza się raczej w domowych „labach” w piwnicy lub osobnym pomieszczeniu.
Raspberry Pi i inne ARM-y świetnie radzą sobie z lekkimi usługami, ale w roli poważniejszego serwera plików i multimediów zaczynają mieć ograniczenia: słabsza wydajność I/O, często tylko jeden port SATA (częściej USB–SATA), ograniczony RAM. Do prostego serwera plików lub lekkiego media servera to wystarczy, ale dla stabilnego środowiska z dużą biblioteką multimediów lepiej celować w x86_64.
Kluczowe elementy: dyski, kontroler, sieć, RAM
Przy wyborze sprzętu warto ocenić kilka praktycznych elementów:
Liczba zatok na dyski: co najmniej dwie zatoki 3,5″ lub 2,5″ dają już sensowną elastyczność (np. jeden dysk na dane, drugi na kopie lub późniejszy RAID1).
Kontroler SATA: nowsze płyty z SATA III (6 Gb/s) zapewnią przyzwoitą prędkość dla SSD i HDD, bez wąskich gardeł starych kontrolerów.
Gigabitowy Ethernet: sieć 1 Gb/s to obecnie absolutne minimum, by kopiowanie plików nie przypominało czasów sprzed dwóch dekad.
Rozbudowa RAM: możliwość dołożenia pamięci pozwoli w przyszłości uruchomić kontenery lub VM-ki bez wymiany płyty głównej.
Dyski to osobny temat: SSD na system znacznie poprawia responsywność, logi i usługi nie obciążają talerzowych HDD. Dane multimedialne i pliki warto trzymać na osobnych dyskach HDD – są tańsze za gigabajt i wciąż wystarczająco szybkie dla streamingu w sieci lokalnej.
Dyski, SSD vs HDD, wstęp do RAID w warunkach domowych
Najbardziej rozsądny układ na start to:
niewielki SSD (np. 120–240 GB) na system (root, /var, logi),
jeden lub kilka HDD 3,5″ / 2,5″ na dane: /srv/data, /srv/media itp.
RAID w domu bywa przeceniany. RAID1 (mirror) zwiększa odporność na awarię pojedynczego dysku, ale nie zastępuje kopii zapasowej. RAID0 (striping) w domowym serwerze plików jest zwykle kiepskim pomysłem – awaria jednego dysku usuwa wszystkie dane w macierzy. RAID5/6 w formie programowej (mdadm) to już wyższa szkoła jazdy: przy dużych dyskach przebudowa macierzy trwa bardzo długo, ryzyko błędów rośnie, a korzyści w domu często są mocno dyskusyjne.
Bez doświadczenia dużo bezpieczniej jest zacząć od jednego dysku na dane i jednego na kopie (np. raz w tygodniu rsync/rsnapshot na drugi dysk), niż od razu wchodzić w skomplikowane RAID-y. Dopiero po kilku miesiącach stabilnego działania, kiedy pojawi się realna potrzeba, można rozważyć mdadm lub LVM RAID.
Zasilanie, chłodzenie, kurz i błędne decyzje przy budowie serwera
Domowy serwer często pracuje 24/7, więc zasilacz z dawnego „składaka” biurowego nie zawsze jest dobrą bazą. Niestabilne napięcia, słabe zabezpieczenia i nagłe wyłączanie się przy obciążeniu potrafią doprowadzić do uszkodzenia danych. Jeśli sprzęt ma działać ciągle, warto rozważyć porządny zasilacz markowej firmy i prosty UPS, choćby tylko po to, by uniknąć gwałtownego odcięcia prądu w trakcie zapisu na dysk.
Chłodzenie często jest ignorowane. Ustawienie serwera w szafce, bez cyrkulacji powietrza, kończy się wysokimi temperaturami, głośną pracą wentylatorów i skróceniem życia dysków. Domowy serwer nie musi być piękny – ważniejsze, by miał choć minimalny przepływ powietrza i był względnie odporny na kurz. Co kilka miesięcy sensownie jest fizycznie obejrzeć wnętrze, oczyścić filtry i sprawdzić stan kabli.
Błędnymi scenariuszami są: instalacja wszystkiego na jednym, starym 500 GB HDD, bez żadnej kopii zapasowej, upchnięcie komputera w zamkniętej szafce oraz kompletny brak monitoringu temperatury. Taki zestaw zadziała kilka miesięcy, a potem awaria dysku lub przegrzanie zniweczą całą pracę włożoną w konfigurację Ubuntu Server.
Przygotowanie do instalacji: pobranie Ubuntu Server i plan partycjonowania
Dobór wersji Ubuntu Server: LTS, architektura, weryfikacja ISO
Do domowego serwera plików i multimediów najrozsądniejszy jest wybór Ubuntu Server LTS (Long Term Support). Wersje LTS mają dłuższe wsparcie bezpieczeństwa i są mniej podatne na „niespodzianki” związane z szybkim rozwojem pakietów. W praktyce oznacza to mniej stresu związanego z aktualizacjami w środku domowej sieci.
W zdecydowanej większości przypadków odpowiednią architekturą jest x86_64 (amd64). Starsze maszyny 32-bitowe nie są już dobrym kandydatem na serwer – brak wsparcia i słaba wydajność tworzą zbyt dużo ograniczeń. Obraz ISO Ubuntu Server można pobrać bezpośrednio ze strony Canonicala, wybierając najnowszą LTS.
Po pobraniu warto sprawdzić sumy kontrolne (SHA256) dostarczone przez producenta. Błędny lub uszkodzony obraz ISO potrafi generować losowe problemy w trakcie instalacji, które trudno później zdiagnozować. Weryfikacja polega na obliczeniu sumy dla pobranego pliku i porównaniu jej z wartością opublikowaną na stronie Ubuntu.
Dla osób interesujących się technologią i open source, śledzących serwisy takie jak Linux, Windows, Open Source, własny serwer Ubuntu staje się czymś więcej niż magazynem plików – to przy okazji stabilne środowisko do nauki i eksperymentów.
Tworzenie nośnika instalacyjnego: USB i typowe problemy
Do instalacji Ubuntu Server najwygodniejszy jest bootowalny pendrive. W zależności od systemu, z którego przygotowujesz nośnik, można wykorzystać różne narzędzia:
Windows: Rufus – prosty interfejs, obsługa trybu UEFI i BIOS, możliwość wyboru schematu partycjonowania (GPT/MBR).
Tworzenie nośnika instalacyjnego w Linux i macOS
Na systemach uniksowych najprostsze bywa użycie wiersza poleceń, choć nie jest to rozwiązanie „odporne na błędy użytkownika”. Pomyłka w nazwie urządzenia potrafi nadpisać nie ten dysk, co trzeba.
Najpierw trzeba bezbłędnie rozpoznać urządzenie pendrive (kolumna SIZE, brak systemu dla partycji systemowych, czasem nazwa producenta). Celowo używa się całego urządzenia (/dev/sdX), a nie partycji (/dev/sdX1). Dla osób mniej pewnych siebie wygodniejszy będzie balenaEtcher albo Ventoy z interfejsem graficznym.
macOS: również dd, ale przez /dev/rdiskX (surowy dostęp):
Po zakończeniu kopiowania trzeba ręcznie „odłączyć” pendrive (diskutil eject /dev/diskX albo zwykłe wysunięcie w Finderze). Jeżeli instalator później nie startuje, najczęściej problemem jest tryb bootowania (UEFI/Legacy) lub kolejność bootowania w BIOS/UEFI, a nie sam pendrive.
UEFI, BIOS, Secure Boot i wybór trybu startu
Przed instalacją opłaca się spędzić kilka minut w ustawieniach firmware’u:
Tryb UEFI zamiast Legacy/CSM: nowy system sensowniej uruchamiać w UEFI, zwłaszcza gdy dysk jest w schemacie GPT. Mieszanie starych instalacji MBR + nowego UEFI zazwyczaj kończy się dodatkowymi komplikacjami z bootloaderem.
Secure Boot: Ubuntu teoretycznie obsługuje Secure Boot, ale przy późniejszej instalacji sterowników lub modułów (ZFS, np. DKMS) zaczynają się schody z podpisywaniem kernela. W typowym domowym serwerze wygodniej jest Secure Boot wyłączyć.
Kolejność bootowania: ustawienie USB jako pierwszego pozwala komfortowo przejść przez instalację, ale po zakończeniu lepiej z powrotem przywrócić start z dysku systemowego, żeby w razie pozostawionego pendrive’a maszyna nie próbowała z niego znowu wystartować.
Starczy jedno nieuważne przeklikanie (np. wymuszenie Legacy) i instalator przygotuje tablicę partycji MBR, a później, przy zmianie ustawień na UEFI, system zwyczajnie nie wystartuje. Unika się tego, trzymając się jednego, spójnego trybu od początku.
Plan partycjonowania: prostota kontra elastyczność
Przed uruchomieniem instalatora trzeba podjąć kilka decyzji, które trudniej będzie zmienić później. Chodzi głównie o to, gdzie fizycznie znajdzie się system, a gdzie dane użytkownika i multimediów.
Na typowy domowy serwer plików sensowny, mało kłopotliwy schemat to:
SSD:
/ (root) + /var + logi – jedna większa partycja lub wolumen LVM,
mały swap (gdy RAM jest ograniczony, np. 4–8 GB).
HDD:
jedna lub kilka partycji / wolumenów na dane, np. /srv/data, /srv/media.
Wyodrębnianie osobnych partycji dla /home w roli serwera plików ma sens dopiero wtedy, gdy na tej samej maszynie pracują interaktywni użytkownicy (np. SSH, development). Jeżeli to głównie serwer usług, wygodniej trzymać ich pliki w wydzielonych katalogach pod /srv, a /home zostawić minimalne.
LVM, klasyczne partycje i luks na przyszłość
Instalator Ubuntu Server domyślnie proponuje użycie LVM – i w kontekście serwera plików to zwykle dobre wyjście. LVM daje:
łatwe powiększanie wolumenów (np. gdy /srv/media zaczyna się zapełniać),
możliwość podpinania kolejnych dysków bez radykalnej przebudowy całej struktury,
szansę na robienie snapshotów (do bardziej zaawansowanych scenariuszy).
Jeżeli głównym celem jest prostota i serwer stoi na jednym SSD + jednym HDD, klasyczne partycje bez LVM też nie są błędem. Elastyczność LVM pokazuje swoją przewagę dopiero przy rozbudowie: dokładane dyski, migracje, reorganizacje przestrzeni.
Szyfrowanie pełnodyskowe (LUKS) w domu bywa dyskusyjne. Jeżeli serwer stoi w mieszkaniu, a głównym ryzykiem jest awaria sprzętu, niekoniecznie trzeba szyfrować wszystko. Kiedy natomiast w grę wchodzą bardziej wrażliwe dane (dokumenty z pracy, dane klientów), szyfrowanie dysku systemowego i/lub wolumenów z danymi staje się uzasadnione – ale trzeba wtedy pogodzić się z koniecznością podawania hasła przy starcie lub konfiguracją zdalnego odblokowania przez sieć.
Źródło: Pexels | Autor: Brett Sayles
Instalacja Ubuntu Server krok po kroku z omówieniem decyzji
Start instalatora i podstawowe ustawienia
Po uruchomieniu z pendrive’a pojawia się menu startowe instalatora. Najczęściej wystarczy wybrać „Install Ubuntu Server” i poczekać, aż wczytają się komponenty. Pierwsze ekrany to:
Wybór języka: można od razu ustawić polski, choć logi i tak w większości będą po angielsku. Część administratorów preferuje interfejs instalatora po angielsku, żeby łatwiej później szukać rozwiązań błędów w sieci.
Układ klawiatury: przy zdalnej administracji ma to mniejsze znaczenie, ale przy wpisywaniu haseł (szczególnie ze znakami specjalnymi) różnica między US a PL potrafi zaskoczyć.
Konfiguracja sieci podczas instalacji
Instalator zwykle proponuje DHCP. Do pierwszego uruchomienia wystarczy, lecz w dłuższej perspektywie serwer plików lepiej mieć pod jednym, stałym adresem IP.
Są dwa podejścia:
Static IP w instalatorze: od razu ustawia się stały adres (np. 192.168.1.10), maskę, bramę i DNS. Plusem jest pełna kontrola od pierwszego startu, minusem – konieczność spójności z ustawieniami routera (żeby nie wpaść w konflikt z pulą DHCP).
Rezerwacja DHCP w routerze: serwer nadal korzysta z DHCP, ale router na stałe przydziela mu ten sam adres na podstawie MAC. Mniej grzebania po stronie Ubuntu, wszystko widać z panelu routera, choć nie każdy router domowy radzi sobie z tym poprawnie.
Na etap konfiguracji usług (Samba, NFS, media server) wygodniej jest mieć stałe IP – wiele poradników i konfiguracji opiera się na twardym adresie, a nie na dynamicznie zmieniającym się z puli DHCP.
Ustawienie profilu proxy i mirrorów
Jeżeli serwer stoi za zwykłym domowym routerem, pole z proxy zwykle zostawia się puste. W bardziej skomplikowanych środowiskach można ustawić tu adres proxy HTTP/HTTPS, ale w typowym domu jedyna istotna decyzja dotyczy wyboru mirrora Ubuntu. Automatyczny wybór jest zazwyczaj wystarczający, ręczna zmiana przydaje się wtedy, gdy lokalny mirror jest ewidentnie przeciążony albo niestabilny.
Partycjonowanie w instalatorze
Najbardziej newralgiczna część, w której łatwo nadpisać zły dysk. Instalator pokazuje listę urządzeń (np. /dev/sda, /dev/sdb) z rozmiarami. Warto sprawdzić:
który dysk jest SSD (często niższy rozmiar, czasem nazwa producenta typu „Samsung SSD”),
który to HDD na dane (większa pojemność, zapisane wcześniej dane – o ile ich nie kasujemy).
Najprostszy, ale bezpieczny schemat dla początkujących:
wybrać SSD jako dysk dla systemu,
zezwolić instalatorowi na automatyczne utworzenie partycji z LVM na SSD,
na tym etapie nie ruszać HDD – zostawić go „pustego” do późniejszej konfiguracji pod /srv.
Jeżeli HDD ma już dane, których nie chcemy utracić, dobrze jest zrobić ich kopię przed eksperymentowaniem. Teoretycznie można w instalatorze podmontować istniejące partycje jako np. /srv/media bez formatowania, ale jedno omyłkowe zaznaczenie „formatuj” kończy się bezpowrotną utratą struktury systemu plików.
Utworzenie użytkownika administracyjnego i hasła
Instalator poprosi o nazwę hosta, użytkownika i hasło. Dla serwera domowego rozsądnie jest:
nazwa hosta krótka i jednoznaczna (np. nas, fileserver, media),
użytkownik inny niż ubuntu / admin / user,
hasło na tyle silne, żeby nie trzeba go było zmieniać po tygodniu (min. kilkanaście znaków, mieszanka liter/cyfr/znaków).
Serwer i tak będzie zarządzany przez sudo, więc użytkownik otrzyma uprawnienia administracyjne. Próby „prostoty” w stylu konta o nazwie nas z hasłem nas są wygodne tylko do momentu, kiedy ktoś z sieci domowej nie postanowi „przetestować”, jak łatwo się tam dostać.
Instalacja usług dodatkowych (OpenSSH, snaps)
Pod koniec instalator zaproponuje dodatkowe komponenty. Dla serwera plików absolutnym minimum jest:
OpenSSH server: zdalny dostęp do powłoki przez SSH jest praktycznie obowiązkowy – nikt nie chce podłączać do serwera monitora za każdym razem, gdy trzeba coś poprawić.
Resztę zestawów (np. pakiety dla kontenerów, serwer baz danych) lepiej zainstalować samodzielnie po pierwszym uruchomieniu. Gotowe prekonfiguracje rzadko trafiają w rzeczywiste potrzeby, a tylko zaśmiecają system zbędnymi usługami.
Pierwszy reboot i sprawdzenie podstaw
Po zakończeniu instalacji system poprosi o wyjęcie pendrive’a i zrestartuje maszynę. Przed przejściem dalej sensowne jest potwierdzenie kilku rzeczy:
system startuje bez błędów w GRUB-ie,
po zalogowaniu w konsoli widać adres IP (ip a),
możliwa jest aktualizacja pakietów (sudo apt update),
działa SSH z innego komputera w sieci lokalnej.
Jeżeli choć jeden z tych punktów zawodzi, lepiej zatrzymać się na tym etapie i rozwiązać problem, zamiast budować na niestabilnej bazie.
Podstawowa konfiguracja po instalacji: aktualizacje, sieć, SSH i użytkownicy
Aktualizacja systemu i podstawowe pakiety narzędziowe
Świeżo zainstalowane Ubuntu Server zwykle ma już część aktualizacji, ale nie wszystkie. Pierwsze kroki po zalogowaniu:
sudo apt update
sudo apt full-upgrade
„Full-upgrade” w odróżnieniu od „upgrade” potrafi usuwać i instalować nowe zależności – przy świeżej instalacji to pożądane, później można być bardziej zachowawczym. Po aktualizacji wypada zrestartować maszynę, żeby nowy kernel rzeczywiście był używany.
Do wygodnej administracji przydają się podstawowe narzędzia:
sudo apt install htop iotop smartmontools git tmux vim
Lista zależy od przyzwyczajeń. Ważne, by mieć pod ręką monitorowanie procesów (htop), I/O (iotop) i narzędzia do sprawdzania stanu dysków (smartmontools).
Ustawienie stałego adresu IP w netplan
Jeżeli adres IP nie został ustalony „na sztywno” w trakcie instalacji ani zarezerwowany w routerze, można to zrobić teraz. Ubuntu Server używa netplan. Konfiguracja leży zwykle w /etc/netplan/, plik ma nazwę typu 00-installer-config.yaml.
Przykładowa konfiguracja dla interfejsu enp3s0 z adresem 192.168.1.10/24, bramą 192.168.1.1 i DNS Google + Cloudflare:
Jeżeli po tej operacji traci się połączenie SSH, zwykle przyczyną jest literówka w adresie, masce albo nazwa interfejsu inna niż w pliku. Zawsze można chwilowo wrócić do konsoli lokalnej (monitor + klawiatura) i poprawić konfigurację.
Bezpieczniejsza konfiguracja SSH
Domyślna konfiguracja SSH działa, ale ma kilka słabych punktów. Przy serwerze widocznym tylko z LAN ryzyko jest mniejsze, jednak szybka higiena na starcie oszczędza nerwów, jeśli kiedyś trzeba będzie wystawić port 22 na świat.
Podstawowe kroki:
wyłączyć logowanie hasłem na rzecz kluczy,
rozważyć zmianę portu (nie jest to „prawdziwe” zabezpieczenie, ale zmniejsza szum w logach),
ograniczyć, kto w ogóle może logować się przez SSH.
Plik konfiguracyjny to /etc/ssh/sshd_config. Na początek lepiej robić kopię:
Na maszynie klienckiej (np. laptopie) generuje się klucz:
ssh-keygen -t ed25519 -C "domowy-serwer"
Klucz publiczny (~/.ssh/id_ed25519.pub) trzeba wgrać na serwer, np.:
ssh-copy-id użytkownik@192.168.1.10
Albo ręcznie dopisać zawartość pliku .pub do ~/.ssh/authorized_keys na serwerze (w katalogu domowym danego użytkownika, prawa katalogu .ssh – 700, pliku authorized_keys – 600).
Po potwierdzeniu, że logowanie kluczem działa, można zaostrzyć konfigurację SSH. Przykładowe fragmenty /etc/ssh/sshd_config:
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers użytkownik
AllowUsers ogranicza dostęp tylko do wskazanych kont. Przy dwóch administratorach można podać kilka nazw. Po edycji trzeba przeładować usługę:
sudo systemctl reload ssh
Bezpiecznie jest utrzymać otwartą istniejącą sesję SSH podczas testu – gdy nowa sesja działa poprawnie, starą można zakończyć. W razie literówki w konfiguracji pozostaje jeszcze lokalna konsola.
Zmiana portu (np. na 2222) obniża liczbę automatycznych prób logowania od skanerów Internetu, ale nie zastępuje kluczy i sensownego hasła. Jeśli port ma być wystawiony na WAN, dochodzi temat fail2ban lub firewalli z limitem połączeń.
Dodawanie użytkowników i podstawowe uprawnienia
Serwer plików w domu zwykle obsługuje więcej niż jedną osobę. Użytkownicy systemowi nie muszą pokrywać się 1:1 z osobami w domu, ale często tak jest wygodniej przy prostych scenariuszach.
Nowego użytkownika tworzy się poleceniem:
sudo adduser jan
W trakcie kreatora podaje się hasło i, opcjonalnie, dodatkowe dane. Użytkownikowi, który ma mieć dostęp administracyjny, trzeba dodać grupę sudo:
sudo usermod -aG sudo jan
Typowy błąd to przyznanie każdemu domownikowi praw sudo „bo tak łatwiej”. Jeśli jedna osoba zarządza serwerem, pozostałe konta mogą być zwykłe, bez możliwości eskalacji. Przy udziale dzieci czy mniej technicznych użytkowników to czasem różnica między „ups, skasowałem katalog” a „ups, wyczyściłem cały dysk systemowy”.
Jeżeli serwer ma być używany tylko przez klientów Samby / NFS, a nikt nie będzie logować się przez powłokę, można stworzyć użytkownika z zablokowaną powłoką logowania:
sudo adduser --shell /usr/sbin/nologin mediauser
Później taki użytkownik będzie widniał jako właściciel plików na serwerze, ale nie posłuży do „normalnego” logowania po SSH.
Podstawowa konfiguracja firewalla (UFW)
Ubuntu ma wbudowany filtr pakietów iptables/nftables, ale prostszą nakładką jest ufw. Do domowego serwera wystarcza najczęściej prosty zestaw reguł.
To blokuje cały ruch przychodzący, poza tym, co jawnie dopuścimy. Następnie należy zezwolić na SSH z sieci lokalnej. Jeśli serwer ma tylko jedną kartę w LAN, zwykle wystarczy:
sudo ufw allow 22/tcp
Przy niestandardowym porcie SSH (np. 2222/tcp) regułę trzeba dostosować:
sudo ufw allow 2222/tcp
Na końcu włączenie firewalla:
sudo ufw enable
Status reguł można sprawdzić:
sudo ufw status verbose
Jeżeli serwer będzie dostępny spoza domu, warto dodać ograniczenia źródłowych adresów IP (np. tylko własne biuro lub VPN). W LAN zwykle nie ma to sensu – przy zmianach w routerze / podsieciach łatwo o blokadę samego siebie.
Zarządzanie dyskami i systemem plików dla danych
Identyfikacja dysków i podstawowa diagnostyka
Przed jakąkolwiek operacją na dyskach trzeba wiedzieć, które urządzenie jest które. Podstawowe komendy:
lsblk – listuje dyski, partycje i ich punkty montowania,
sudo fdisk -l – bardziej szczegółowy widok, przydatny do weryfikacji typów partycji,
sudo smartctl -a /dev/sdX – stan SMART dysku (pakiet smartmontools).
lsblk pomaga szybko odnaleźć HDD na dane po rozmiarze. Przykładowe wyjście:
lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 232.9G 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
└─sda2 8:2 0 232.4G 0 part
└─vg0-root
sdb 8:16 0 4.6T 0 disk
Tutaj sda to SSD z systemem, sdb to 5 TB HDD, na którym jeszcze nic nie ma. Przed tworzeniem systemu plików dobrze jest sprawdzić SMART:
sudo smartctl -a /dev/sdb
Przy niepokojących parametrach (wysokie Reallocated_Sector_Ct, Pending_Sector, błędy odczytu) lepiej nie budować na takim dysku domowego archiwum.
Tworzenie partycji pod dane
Do prostego scenariusza wystarczy jedna partycja obejmująca cały dysk. Można użyć fdisk (MBR / GPT) albo parted. Dla większych dysków sensownie jest wybrać GPT.
Przykładowo, tworzenie pojedynczej partycji na całym dysku /dev/sdb za pomocą fdisk (GPT):
sudo fdisk /dev/sdb
W środku sekwencja komend (interaktywnie):
g – utworzenie nowej tablicy partycji GPT (kasuje wszystko na dysku!),
n – nowa partycja, domyślne wartości start/koniec (cały dysk),
w – zapisanie zmian.
Po wyjściu ponowne lsblk powinno pokazać /dev/sdb1. Jeśli dane na dysku już istnieją i mają być zachowane, etap partycjonowania wymaga dużo ostrożności, a najlepiej kopii zapasowej. Narzędzia typu gparted potrafią zmieniać rozmiary partycji bez utraty danych, ale przy domowym serwerze prościej i bezpieczniej bywa przekopiować dane na inny nośnik, wyczyścić układ partycji i wgrać je z powrotem.
Wybór systemu plików: ext4, XFS, ZFS
Debata o „najlepszym” systemie plików jest niekończąca się. Do domowego serwera z jednym lub dwoma dyskami regułą jest ext4 – sprawdzony, dobrze wspierany, prosty w naprawie. XFS bywa korzystny przy bardzo dużych plikach i macierzach, ZFS daje snapshoty i sumy kontrolne, ale wprowadza więcej złożoności.
ext4 – domyślny, przewidywalny. Dobrze współpracuje z większością narzędzi, brak „magii”, która mogłaby zaskoczyć mniej doświadczonego admina.
XFS – dobry przy sekwencyjnym zapisie dużych plików (wideo, backupy), gorzej znosi zmniejszanie systemu plików (praktycznie brak możliwości bez kopiowania).
ZFS – snapshoty, checksumming, kompresja. Wymaga dodatkowych modułów jądra (pod Ubuntu – zfsutils-linux), lepiej czuje się z większą ilością RAM. Przy jednym dysku w domu często jest to przerost formy nad treścią.
Dla prostego serwera plików z jednym dużym dyskiem na dane sensownym kompromisem jest ext4.
Tworzenie systemu plików ext4
Zakładając, że chcemy ext4 na nowo utworzonej partycji /dev/sdb1:
sudo mkfs.ext4 -L dane /dev/sdb1
-L dane ustawia etykietę, co później ułatwia identyfikację w blkid i lsblk. Po formatowaniu można sprawdzić:
Aby system automatycznie montował dysk z danymi przy starcie, trzeba dopisać wpis do /etc/fstab. Bazowanie na UUID zamiast nazwy urządzenia (/dev/sdb1) jest bezpieczniejsze – kolejność dysków może się zmienić przy dodawaniu nowych.
Na początek tworzymy katalog na dane, np. /srv/data:
ostatnie dwie liczby (0 2) – pierwsza kontroluje robienie dumpów (zwykle 0), druga kolejność sprawdzania fsck (2 dla systemów plików innych niż root).
Po edycji pliku warto przetestować wpis przed rebootem:
sudo mount -a
Jeżeli komenda nie zwróci błędów, system powinien poprawnie zamontować dysk przy kolejnym starcie. Typowy błąd to literówki w UUID lub brak katalogu montowania – w takim przypadku boot może zatrzymać się na interaktywnym trybie naprawy.
Proste grupowanie przestrzeni: LVM dla danych
Przy jednym dysku na dane LVM nie jest konieczne, ale daje elastyczność w przyszłości (rozszerzanie wolumenów o nowe dyski, snapshoty). Jeśli ktoś jest gotowy zainwestować trochę czasu w naukę, rozsądnym podejściem jest użycie LVM na dyskach danych, zostawiając jednocześnie prosty ext4 wewnątrz wolumenów logicznych.
Przykładowy scenariusz: dwa dyski HDD po 4 TB połączone jako volume group, w której tworzy się kilka wolumenów logicznych (lv) – osobno na media, backupy i „wspólne dane”. Nie jest to RAID – awaria jednego z dysków w wolumenie rozszerzonym o kilka nośników może oznaczać utratę części lub całości danych, jeśli nie używa się dodatkowego poziomu redundancji (mdadm RAID1/5/6/10 lub ZFS).
Podstawowe kroki (na przykładzie jednego dysku /dev/sdb):
Na nich można utworzyć ext4 tak samo jak wcześniej:
sudo mkfs.ext4 -L media /dev/vg_dane/media
sudo mkfs.ext4 -L backup /dev/vg_dane/backup
Do /etc/fstab trafiają wpisy już na podstawie UUID nowych systemów plików lub ścieżek /dev/vg_dane/.... LVM pozwala później zmieniać rozmiary wolumenów (z pewnymi ograniczeniami przy zmniejszaniu), ale wymaga większej dyscypliny przy backupach – błędna operacja na LV może skutecznie wyczyścić część danych.
RAID programowy mdadm – kiedy ma sens
Najczęściej zadawane pytania (FAQ)
Czy do domowego serwera plików i multimediów lepiej wybrać gotowy NAS czy Ubuntu Server?
Jeśli zależy ci głównie na tym, żeby „po prostu działało” – trzymanie filmów, zdjęć, automatyczny backup z telefonów – gotowy NAS zwykle będzie prostszy. Konfiguracja przebiega w przeglądarce, producent daje aplikacje mobilne i gotowe rozwiązania do multimediów.
Ubuntu Server na zwykłym PC lub miniPC daje dużo większą elastyczność, ale w zamian wymaga czasu, czytania dokumentacji i oswojenia się z terminalem. Sprawdza się u osób, które chcą czegoś więcej niż standard NAS-a: własnych kontenerów Dockera, VPN, Nextclouda czy własnego Git-a. Dla typowego użytkownika różnica to wybór między „mniej możliwości, więcej wygody” a „więcej możliwości, więcej odpowiedzialności”.
Jaki sprzęt wystarczy do domowego serwera na Ubuntu do filmów i plików?
Do prostego udostępniania plików i streamowania filmów FullHD wystarczy starszy komputer lub miniPC z procesorem 64‑bit (np. stare i3), 4 GB RAM jako dolna granica i 1 Gb/s Ethernet. System dobrze jest zainstalować na małym SSD (60–120 GB), a dane trzymać na oddzielnym HDD o pojemności od 1–2 TB wzwyż.
To, co najczęściej staje się problemem, to nie procesor, tylko dyski i sieć. Przy dynamicznym korzystaniu z multimediów lepiej zainwestować w:
SSD na system i aplikacje,
porządne HDD na dane (niekoniecznie „serwerowe”, ale w dobrym stanie),
stabilną sieć gigabitową w domu.
RAM i mocniejsze CPU zaczynają mieć znaczenie dopiero przy wirtualizacji, wielu kontenerach albo ciężkim transkodowaniu 4K.
Czy stary komputer nadaje się na domowy serwer Ubuntu, czy lepiej kupić coś nowego?
Stary desktop to często rozsądny start, o ile jest technicznie sprawny i nie żre prądu jak piec. Typowy scenariusz: wyjęty z szafy kilkuletni PC, do którego dokładamy SSD na system i większy HDD na dane. Zyskujesz niski koszt wejścia i sporo miejsca na dyski, ale płacisz wyższym poborem energii i zwykle większym hałasem.
Nowy miniPC/NUC będzie cichszy i znacznie oszczędniejszy energetycznie, ale ma mniej miejsca na dyski i często ograniczenia RAM. Przy ciągłej pracy 24/7 rachunek za prąd przestaje być abstrakcją – przy kilku latach działania różnica między starym desktopem a energooszczędnym miniPC potrafi zrównać koszt zakupu. Dlatego „stary PC na próbę, a potem świadoma decyzja co dalej” jest sensowną drogą.
Czy Raspberry Pi wystarczy jako domowy serwer plików i multimediów?
Raspberry Pi da sobie radę z bardzo lekkim scenariuszem: prosty serwer plików, kilka urządzeń w sieci, sporadyczne oglądanie filmów. Ograniczenia pojawiają się przy większej bibliotece multimediów, wielu jednoczesnych klientach i intensywnym odczycie/zapisie – wąskim gardłem jest zarówno I/O (dyski często po USB–SATA), jak i ilość RAM.
Jeśli plan jest taki, że serwer ma obsłużyć całą rodzinę, wygodnie streamować multimedia, a do tego może kiedyś pojawi się Nextcloud czy kontenery, bezpieczniej jest od razu iść w architekturę x86_64 (stary PC, miniPC). Raspberry Pi sprawdza się raczej jako zabawka edukacyjna lub dodatkowy, lekki węzeł usług, a nie główny magazyn domowych danych.
Ile RAMu naprawdę potrzebuje domowy serwer Ubuntu z Sambą, Plexem/Jellyfin i kopią zapasową?
Dla samego serwera plików (Samba/NFS) i jednego prostego serwera multimediów absolutne minimum to 4 GB RAM, ale przy takim zasobie margines błędu jest mały. Przy 8 GB RAM konfiguracja staje się dużo bardziej komfortowa: system ma miejsce na cache dyskowy, usługi nie walczą o każdy megabajt, a ewentualne dodatkowe narzędzia (np. lekkie kontenery Dockera) nie duszą się od razu.
Prawdziwe „zjadające RAM” są dopiero wirtualne maszyny, rozbudowane laby testowe i wiele kontenerów. Jeśli planujesz taki rozwój, lepiej na etapie wyboru sprzętu zadbać, żeby dało się włożyć 16 GB RAM i więcej. Do samego domowego serwera plików + multimediów większość osób nie wykorzysta nawet sensownie całych 8 GB.
Czy potrzebuję RAID w domowym serwerze plików, czy wystarczy zwykły backup?
RAID bywa mylony z backupem. Macierz RAID (np. RAID1) daje odporność na awarię jednego dysku, ale nie chroni przed skasowaniem plików, zaszyfrowaniem przez ransomware czy błędami użytkownika – wszystko to rozprzestrzenia się na wszystkie dyski w macierzy. W typowym domu częściej traci się dane przez błąd człowieka niż czysto sprzętową awarię.
Dla większości domowych zastosowań bezpieczniejszym i tańszym startem jest:
jeden porządny dysk na dane,
regularny backup na inny nośnik (zewnętrzny dysk, drugi komputer, czasem chmura).
RAID ma sens, gdy serwer musi być jak najdłużej dostępny (np. praca zdalna na współdzielonych danych) i akceptujesz większą złożoność konfiguracji. Jako pierwszy krok zwykle bardziej opłaca się dopracować prosty, sprawdzony scenariusz kopii zapasowych.
Czy domowy serwer Ubuntu musi być włączony 24/7 i jak to wpływa na koszty?
Nie musi, ale to, czy będzie wyłączany, zależy od scenariusza. Jeśli serwer ma służyć tylko do oglądania filmów wieczorami, można go wyłączać na noc czy na czas pracy poza domem. Jeśli ma przyjmować kopie z telefonów „w tle”, działać jako VPN z zewnątrz czy być dostępny rodzinie o różnych porach – częste wyłączanie zaczyna być kłopotliwe.
Praca 24/7 oznacza realny koszt energii, zwłaszcza przy starych desktopach i serwerach „z odzysku”. Zanim kupisz głośnego racka z ogłoszenia, dobrze policzyć, ile w skali roku może kosztować jego ciągła praca. W praktyce, jeśli serwer ma działać stale, opłaca się szukać możliwie energooszczędnej platformy (miniPC, NUC, laptop z zamkniętą klapą i dyskami po USB/SATA), a nie najtańszego w zakupie „potwora” z serwerowni.
Źródła informacji
Ubuntu Server Guide. Canonical – Oficjalna dokumentacja instalacji i konfiguracji Ubuntu Server
Ubuntu Server 22.04 LTS Documentation. Canonical (2022) – Wymagania sprzętowe, wsparcie architektur, dobre praktyki serwerowe
Filesystem Hierarchy Standard. Linux Foundation – Standard struktury systemu plików w systemach Linux
The Linux Command Line. No Starch Press (2012) – Podstawy pracy w terminalu, administracja i skrypty powłoki
Samba Documentation. Samba Team – Konfiguracja Samby jako serwera plików w sieci domowej
NFS Howto. The Linux Documentation Project – Opis konfiguracji NFS do udostępniania plików w sieci LAN
Nextcloud System Administration Manual. Nextcloud GmbH – Wymagania, instalacja i konfiguracja prywatnej chmury plików
Docker Documentation. Docker Inc. – Podstawy konteneryzacji, dobre praktyki dla usług domowych
