Domowe laboratorium IT na starym PC: serwer plików, kopie, testy sieci

Masz stary komputer? Zrób z niego domowe laboratorium IT

Leży w szafie stary PC, a Ty potrzebujesz miejsca na zdjęcia, porządnych kopii zapasowych i przestrzeni do testów sieci? To dobry moment, by zbudować domowe laboratorium IT: serwer plików, system backupów i środowisko do nauki sieci na jednym sprzęcie. Klucz to rozsądny plan, kilka sprawdzonych narzędzi i jasne priorytety: stabilność danych, powtarzalność kopii i bezpieczne testy bez psucia domowej sieci.

Najpierw konkrety: o co zwykle chodzi

• Czy mój stary PC w ogóle się nada? – Nada się, jeśli ma sprawny dysk, minimum 8 GB RAM i kartę sieciową gigabitową.
• Jaki system wybrać, by mieć serwer plików i backupy? – Proste opcje: OpenMediaVault, TrueNAS SCALE, Proxmox z kontenerami/VM. Dla minimalizmu: Debian/Ubuntu Server.
• Jak ustawić regularne kopie i nie przepłacać za chmurę? – Rsync/Borg/Restic lokalnie, Rclone do chmury, rotacja 3-2-1 i test odtwarzania.
• Czy dam radę testować sieci i usługi? – Tak: wirtualny router (OPNsense/pfSense), VLAN-y, kontenery z narzędziami, iperf3, tcpdump.
• Jak nie spalić rachunku za prąd i nie ogłuchnąć? – Dyski NAS/CMR, spindown, harmonogram włączania, powertop/autotune, cichy wentylator.

Reszta to dobrze dobrane kompromisy: prostota kontra elastyczność, wydajność kontra pobór energii, oraz to, czy bardziej chcesz „włączyć i zapomnieć”, czy mieć plac zabaw pod pełną kontrolą.

Ocena starego sprzętu: na czym realnie możesz polegać

Procesor, RAM i dyski – dolna granica komfortu

Do serwera plików i kopii zapasowych wystarczy procesor dwurdzeniowy sprzed dekady, ale przy wirtualizacji i testach sieci docenisz 4–8 wątków. Rozsądne minimum RAM to 8 GB: 4 GB wystarczy tylko na bardzo osnovy NAS. Jeśli planujesz ZFS i kilka maszyn wirtualnych, celuj w 16 GB lub więcej. Dyski? SSD jako system i cache, HDD CMR jako magazyn. Nośniki SMR sprawdzą się do rzadkiej archiwizacji, ale bywają wolne przy długich zapisach i macierzach. Na start: 1 SSD 120–240 GB na system, 1–2 HDD 2–8 TB na dane.

Karta sieciowa i płyta główna – niuanse, które bolą później

Gigabitowy Ethernet to standard. Układy Intel zwykle są stabilniejsze i lepiej wspierane w Linuxie niż część modeli Realtek. Gdy planujesz VLAN-y lub passthrough do VM, rozważ dodatkową kartę PCIe Intel i350 lub i210. Sprawdź też, czy BIOS obsługuje boot z USB i dysków >2 TB; aktualizacja BIOS potrafi rozwiązać zaskakujące problemy.

Zasilacz, hałas i obudowa – infrastruktura to nie detal

Stary zasilacz bez certyfikatu 80 PLUS potrafi grzać i szumieć pod małym obciążeniem. Rozsądny, cichy zasilacz 300–450 W często zwraca się niższym rachunkiem za prąd. Wibracje talerzowych HDD ucisza gumowe mocowanie, a kurtyna przeciwkurzowa w obudowie ogranicza wzrost temperatur. Zamknij sprzęt w przewiewnym miejscu, ale nie wciśnięty w narożnik bez przepływu powietrza.

Wybór platformy: prosty NAS, hipernadzorca czy czysty Linux

Trzy sensowne kierunki

Na starym PC zrobisz domowe laboratorium IT na kilka sposobów:

• Prosty NAS z GUI: OpenMediaVault (Debian) lub TrueNAS SCALE (Linux + ZFS + KVM + kontenery). Dobre, jeśli chcesz szybki efekt i wygodne zarządzanie.
• Hipernadzorca: Proxmox VE. Na nim postawisz VM i kontenery, a rola serwera plików będzie w jednym z nich (np. OMV w LXC/VM).
• Czysty Debian/Ubuntu Server: maksimum kontroli, minimum narzutu. Wymaga komfortu z terminalem i samodzielnym składaniem klocków.

Porównanie opcji pod kątem celu

Jak zdecydować bez przeciągania

Gdy priorytetem jest serwer plików i kopie zapasowe „tu i teraz”, a testy sieci to dodatek – wybierz OpenMediaVault lub TrueNAS SCALE. Gdy największą frajdą będzie lab sieciowy i wirtualizacja – Proxmox. Jeśli czujesz się pewnie w Linuxie i lubisz pełną kontrolę – czysty Debian.

Magazyn danych: systemy plików, RAID i ZFS bez mitów

RAID to nie backup – ustaw role i ryzyka

RAID ma dać ciągłość działania przy awarii dysku, nie chroni przed skasowaniem, ransomware czy błędem użytkownika. Celuj w RAID1 (mirroring) lub ZFS mirror dla dwóch dysków. RAID5/6 na bardzo starych kontrolerach i dyskach SMR bywa ryzykowny i wolny. Pojedynczy dysk + dobre kopie zapasowe to często bezpieczniejsze i tańsze rozwiązanie niż „tani RAID” z kiepskich nośników.

ZFS, btrfs, mdadm + ext4 – kiedy co wybrać

• ZFS: świetne snapshoty, kompresja, samonaprawa. Lubi RAM, ale na domowy użytek działa rozsądnie od 8–12 GB. Potrzebuje dobrego wsparcia (TrueNAS, Proxmox, Debian z zfs-dkms).
• btrfs: snapshoty i kompresja w jądrze. Do pojedynczego dysku lub RAID1 – OK. Złożone konfiguracje RAID5/6 wciąż mają kontrowersje.
• mdadm + ext4/xfs: klasyka; przewidywalne i szybkie. Snapshoty i wersjonowanie trzeba zrobić narzędziami wyżej (np. Borg/Restic).

Jeśli zależy Ci na prostocie i przewidywalności – mdadm + ext4 lub pojedynczy dysk + rsync/Borg/Restic. Gdy chcesz mieć snapshoty udziałów i kopie „wbudowane” – ZFS (TrueNAS SCALE to strzał w dziesiątkę).

SSD jako cache lub system – rozsądna inwestycja

System postaw na SSD. ZFS doceni SLOG/L2ARC, ale na starym PC rzadko to się opłaca – lepszy będzie po prostu szybki SSD na system i metadane, a HDD na magazyn. Jeżeli chcesz ciszy i niskiego poboru mocy, rozważ jeden większy SSD NVMe/SATA na całość, ale pamiętaj o cyklach zapisu i konieczności backupu.

Serwer plików: udziały, uprawnienia i wydajność SMB/NFS

SMB dla Windows i macOS, NFS dla Linuxa

Najwygodniejszy dla domowników będzie SMB (Samba). Utwórz osobne konta użytkowników i prywatne udziały (np. domy/zdjęcia), a do współdzielonych dokumentów jeden udział z kontrolą dostępu. Dla maszyn Linux w sieci domowej skonfiguruj NFS, jeśli zależy Ci na lekkości i szybkości montowania katalogów.

Uprawnienia, wersjonowanie i snapshoty

Ustal regułę: wszystko co ważne zapisuj na serwerze plików, nie na laptopach domowników. Włącz wersjonowanie plików (np. przez snapshoty ZFS/Btrfs czy mechanizm VFS Recycle po stronie Samby) i codzienne snapshoty na poziomie datasetu. Trzymaj 7 dziennych, 4 tygodniowe, 3 miesięczne – to prosta, przewidywalna rotacja.

Wydajność SMB: typowe wąskie gardła

Jeśli transfery są powolne, sprawdź kolejno: okablowanie (Cat5e lub wyżej), duplex i prędkość linku, sterowniki karty (Realtek?), MTU 1500 vs 9000 (jumbo frames przetestuj parami), antywirus na kliencie, szyfrowanie SMB (często zbędne w LAN), a także protokoły SMB1/2/3 – wymuś co najmniej SMB3. Dysk SMR w trakcie długiego zapisu potrafi „przysiąść” – to niekoniecznie wina sieci.

Kopie zapasowe w praktyce: od planu 3‑2‑1 do realnego przywracania

Strategia, która nie przerośnie sprzętu

Reguła 3‑2‑1 jest punktem odniesienia, nie dogmatem. Na starym PC zwykle sprawdza się układ: szybka kopia lokalna (na innym fizycznym dysku lub udziale), druga kopia okresowo na odłączanym dysku USB oraz replikacja zaszyfrowanych danych do chmury z limitem transferu. Taki zestaw pozwala przeżyć awarię dysku, przypadkowe skasowanie i zalanie mieszkania. Jeśli budżet jest napięty – zacznij od dwóch kopii (lokalna + okresowy dysk USB), chmurę dołóż po weryfikacji, co faktycznie musi być off‑site.

Borg czy Restic – różnice, które czuć w użyciu

Oba narzędzia deduplikują i szyfrują, ale mają inne mocne strony. Borg bardzo dobrze sprawdza się lokalnie i po SSH (szybki odczyt, sprawne prune), za to Restic jest prostszy do chmury (backendy S3/Azure/Backblaze, brak demona, jeden statyczny binarnik). Na starszym CPU deduplikacja i kompresja potrafią zająć czas – lepiej robić częste, krótkie przyrosty wieczorem niż jedną gigantyczną sesję w weekend. Dla osób z Windows w miksie łatwiej zorganizować Restic (działa przewidywalnie przez S3/REST), ale jeśli cały dom to Linux i SSH – Borg bywa wygodniejszy.

Harmonogram, który nie obudzi domowników

Codzienne przyrosty w nocy, tygodniowe i miesięczne pruningi poza godzinami szczytu to rozsądny start. Włącz limitowanie pasma dla zadań chmurowych, aby nie dławić Netflixa w salonie. Zamiast crona wygodniej użyć systemd timers – łatwiej o zależności (np. „uruchom dopiero po zamontowaniu dysku USB” i „powtórz po błędzie za 15 minut”). Rotacja typu 7 dziennych, 4 tygodniowe, 6 miesięcznych jest przewidywalna i nie zjada dysku w ukryciu.

Szyfrowanie i klucze – uniknij blokady własnych danych

Hasła do repozytoriów i pliki kluczy trzymaj w dwóch miejscach offline (zamknięta koperta i pendrive w innej lokalizacji). Przetestuj odblokowanie repo na drugim komputerze, zanim zaczniesz produkcyjny cykl kopii. W chmurze trzymaj wyłącznie dane zaszyfrowane po stronie klienta; nie zakładaj, że wersjonowanie dostawcy zastąpi Twoją rotację.

Test odtwarzania – najmniejszy sensowny scenariusz

Nawet najlepszy plan bez próby przywracania jest tylko życzeniem. Minimum kontroli jakości można zamknąć w krótkiej liście:

• Raz w miesiącu odtwórz losowy katalog na maszynie testowej i porównaj sumy kontrolne.
• Kwartalnie zrób „bare‑metal light”: nowa VM, czysty system i przywrócenie najważniejszej usługi (np. udziału SMB lub bazy domowej aplikacji).
• Po każdej zmianie klucza/hasła sprawdź odblokowanie repozytorium na innym sprzęcie.

Mini‑lab sieciowy bez psucia domowego LAN

Dwie topologie, które trzymają ryzyko w ryzach

Najbezpieczniej zacząć od w pełni wirtualnej podsieci w hipernadzorcy. Tworzysz izolowany most (vSwitch/bridge) bez fizycznego uplinku, uruchamiasz w nim VM z OPNsense/pfSense jako router i kilka maszyn klienckich. Dostęp do internetu zapewnia NAT gospodarza – ruch labu nie „wlewa się” do domowej sieci, a DHCP z VM nie konkuruje z routerem operatora.

Jeśli potrzebujesz prawdziwych ramek i VLAN‑ów na kablu, dołóż drugą kartę sieciową i zarządzalny switch. Na porcie do serwera ustaw trunk (tagged VLAN‑y), na portach do urządzeń – access z konkretnym VLAN‑em. W routerze‑VM filtruj ruch do domowego LAN regułami „deny by default” i nie przekazuj DHCP poza lab. Jedna pomyłka (np. DHCP na nie‑tagowanym porcie) potrafi wyłączyć internet w całym mieszkaniu – najpierw testuj na odłączonym segmencie.

Router w VM – przydziały i ustawienia bez magii

Routerowi daj dwa interfejsy: LAN (do wirtualnego switcha) i WAN (do NAT gospodarza lub osobnej fizycznej karty). 2 vCPU i 1–2 GB RAM zwykle wystarczają. W OPNsense/pfSense wyłącz offloadingi wirtualne, jeśli widzisz dziwne dropsy lub błędy checksums. Usługi do ćwiczeń to klasyka: DHCP, DNS z lokalnymi strefami, prosty VPN site‑to‑site między dwiema VM. Gdy testujesz QoS/jumbo frames – konfiguruj parami (router i hosty) albo pomiar będzie niemiarodajny.

Diagnostyka, która skraca drogę do przyczyny

iperf3 do przepustowości i jittera, mtr do stabilności tras, tcpdump/Wireshark do zrozumienia „co i gdzie ginie”. W kontenerze typu netshoot masz pod ręką zestaw narzędzi (dig, ss, curl). Skaner nmap uruchamiaj w labie, nie na produkcyjnym LAN – domowe IoT bywa nadwrażliwe i potrafi się zawiesić po intensywnym skanowaniu portów.

Najczęstsze potknięcia: kolizja serwerów DHCP, pętle L2 bez STP, mieszane MTU (9000 po jednej, 1500 po drugiej stronie), a także nakładające się zapory – firewall hipernadzorcy filtruje inaczej niż firewall w VM.

Monitoring i utrzymanie: wykryj problem, zanim zaboli

SMART, temperatury i regularne testy

Włącz smartd z mailowymi alertami i zaplanuj długie testy SMART raz w miesiącu poza godzinami użycia. Dysk z rosnącą liczbą realokowanych sektorów lub wysokim pending zostaw do migracji danych, zanim padnie w niedzielę wieczorem. Dla ZFS ustaw scrub co 30 dni; dla ext4/xfs przynajmniej okresową weryfikację sum kontrolnych plików istotnych aplikacji. Temperatury trzymaj w ryzach (HDD ~30–40°C, SSD zwykle 30–60°C) – zbyt ciepły dysk skraca żywotność i obniża wydajność.

Alerty bez szumu i rozbudowanego NOC

Wystarczy prosty MTA do wysyłki e‑maili, webhook do powiadomień (np. ntfy/Telegram) i dwa progi: ostrzeżenie oraz krytyczny. Kopie zapasowe niech raportują sukces i czas trwania; brak raportu to też alarm – serwisy typu healthchecks mogą pilnować, czy zadanie w ogóle wystartowało. Zmniejszaj hałas: wysyłaj alert dopiero po X kolejnych niepowodzeniach, ale błędy integralności danych sygnalizuj od razu.

Konserwacja systemu i aktualizacje bez niespodzianek

Na starym PC najrozsądniej trzymać się stabilnych wydań (Debian/Ubuntu LTS, TrueNAS SCALE, Proxmox VE). Zmiany rób „małymi porcjami”. Zanim zaktualizujesz kernel lub Sambę/ZFS, zrób snapshot systemu (btrfs/ZFS) lub przynajmniej obraz systemowy. Dla Debiana/Ubuntu przy krytycznych pakietach ustaw pinning albo tymczasowe „hold”, aby uniknąć lawiny zależności. Rebooty planuj – lepiej kontrolowany restart o 2:00 niż wymuszone zawieszenie w niedzielę przy wspólnym filmie. Reguła praktyczna: najpierw aktualizuj zapasową/próbną VM, potem hosta. Jeśli host to hypervisor + storage, testuj w dwóch krokach: usługi gościa, a dopiero później jądro i moduły na hoście.

Kontenery i wirtualizacja: jak nie zabić starego PC

VM, LXC i Docker/Podman – dobierz narzędzie do zadania

• Pełne VM: izolacja i zgodność, kosztem RAM i I/O. Dobre dla routerów‑VM, systemów, które lubią „swoje” jądro (np. starsze appliance) oraz eksperymentów z innymi dystrybucjami.
• LXC: lekka wirtualizacja systemowa, mały narzut. Sensowna, gdy chcesz mieć wiele „prawie VM” bez dublowania jąder. W Proxmoxie łatwo limitować CPU/RAM i uprawienia.
• Kontenery (Docker/Podman): świetne do aplikacji z katalogami danych na hostowym FS. Trzymaj stan w wydzielonych wolumenach/datasetach, a nie w warstwach obrazu.

Na starym PC brak RAM jest częstszym problemem niż CPU. Daj twarde limity cgroups (pamięć, CPU) dla kontenerów i uprość I/O: mniej wolumenów na szybkich ścieżkach, raczej mniej usług, ale „wypieszczonych”. Dla gęstych małych plików (np. PhotoPrism, Git) preferuj SSD. Przy ZFS rozważ osobny dataset per usługa; dla Docker używaj overlay2 na ext4/xfs lub natywnego drivera ZFS, ale unikaj mieszanki „bind‑mounty z randomowymi atrybutami + intensywna deduplikacja” – łatwo o dziwną latencję.

Sieć i I/O – szybkie wygrane

Kiedy kontenery i VM konkurują o sieć i dysk, ustaw proste limity i kolejki. W Proxmox użyj limitów ioprio i mgmt QoS per VM; w Dockerze throttle I/O (device‑read‑bps/iops) dla hałaśliwych usług (np. indeksowanie zdjęć). Nie mieszaj wielu warstw NAT – wybierz albo bridge hosta, albo NAT w routerze‑VM. Jeśli musisz stosować overlay networks w Dockerze, testuj iperf3 także pomiędzy kontenerami, nie tylko host‑host.

Kopie konfiguracji i dane aplikacji – trzymaj porządek od początku

W kontenerach i VM granica między „systemem” a „danymi” szybko się zaciera. Ustal proste reguły: pliki Compose/Cloud‑Init/Ansible trzymaj w repozytorium Git na osobnym udziale, a katalogi danych aplikacji w dedykowanych datasetach/partycjach montowanych po UUID. Aktualizując obraz kontenera, nie dotykasz danych; zmieniając hosta, przenosisz tylko repo z definicjami i katalogi danych. Unikaj losowych bind‑mountów do „/root” czy „/home/user” – po pół roku nikt nie będzie pamiętał, co gdzie leży. Obrazy przypinaj tagami wersji, nie „latest”, żeby móc powtórzyć wdrożenie bez niespodzianek.

Magazyn danych: ZFS, mdadm+ext4, btrfs – rozsądne wybory na starym PC

ZFS: bezpieczeństwo i spójność, ale bez cudów z pamięcią

ZFS daje sumy kontrolne end‑to‑end, snapshoty i łatwy scrub, co realnie ogranicza ryzyko cichej korupcji. Nie jest prawdą, że „bez 32 GB RAM się nie da” – da się, tylko bez wodotrysków. Sensowny start to 8–16 GB RAM, deduplikacja wyłączona, kompresja lz4 włączona globalnie. Dla małych zestawów dysków częściej sprawdza się mirror (2+2) niż RAIDZ1: szybszy rebuild i elastyczniejsza rozbudowa. Przy dużych dyskach (8 TB+) RAIDZ1 bywa ryzykowny – długi resilver i większa szansa na błąd odczytu w trakcie odbudowy. L2ARC i SLOG zostaw na później; SSD‑cache źle dobrany potrafi tylko mieszać w I/O.

mdadm + LVM + ext4/xfs: prosto i przewidywalnie

Klasyczny układ mdadm (RAID1/5/10) z ext4/xfs i LVM bywa najlepszy na start, gdy chcesz łatwe powiększanie i dobrze znane narzędzia. Minusy: brak natywnych snapshotów per FS (LVM ma snapshoty, ale kosztują I/O), brak sum kontrolnych plików. Jeżeli to głównie multimedia i kopie zapasowe z własnymi sumami – wystarczy. Jeżeli trzymasz bazy i masz mało RAM – xfs jest odporny i wydajny przy dużych plikach, ext4 przewidywalny przy miksie małych i średnich plików.

btrfs: snapshoty i kompresja, ostrożnie z RAID5/6

btrfs daje wygodne snapshoty i szybkie wysyłki (send/receive). Z kompresją zstd zyskasz miejsce przy dokumentach i zdjęciach RAW. Pułapka: tryby RAID5/6 nadal potrafią zaskoczyć pod obciążeniem – do domowego użytku bezpieczniejsze są single/mirror, a RAID zorganizuj pod spodem (mdadm) lub na górze (LVM). Sprawdza się jako FS pod kontenery i małe zbiory szybko zmieniających się danych.

Dobór dysków i kontrolerów

• Unikaj mieszania SMR z CMR w jednej puli. SMR bywa tańszy, ale w RAID i przy długich zapisach potrafi dramatycznie zwolnić.
• Jeżeli dokładasz karty HBA, szukaj kontrolerów LSI w trybie IT (passthrough), nie pseudo‑RAID na PCIe z własnymi sterownikami‑wynalazkami.