Proxmox #2 - Tworzymy własny serwer plików (NAS) z wykorzystaniem TrueNAS i Proxmox-a

Proxmox #2 - Tworzymy własny serwer plików (NAS) z wykorzystaniem TrueNAS i Proxmox-a

Dariusz Luber
Dariusz Luber
📺

Wolisz wideo?

Przejdź do sekcji wideo

Video i ten wpis uzupełniają się nawzajem, dlatego dla najlepszego efektu skorzystaj z obu źródeł 😊

Macierz dyskowa (NAS - Network Attached Storage) chroni Wasze dane przed awarią pojedynczego dysku - jeśli jeden, dwa albo trzy dyski padną (zależnie od konfiguracji), danych nie stracicie. To jednak nie jest backup. Redundancja na NAS-ie nie uratuje Was przed przypadkowym skasowaniem plików czy ransomware - kopia zapasowa musi istnieć osobno, w innym miejscu.

TL;DR

  • TrueNAS instalujecie jako VM na Proxmoxie, ale dane trzymacie na dyskach przekazanych bezpośrednio (Disk Passthrough) - nie na wirtualnych .qcow2.
  • Trzy pułapki, które najczęściej psują pierwsze podejście: zaznaczone Pre-Enrolled keys (Secure Boot blokuje boot), domyślna karta graficzna (zamrożony/czarny ekran instalatora) i brak parametru serial przy przekazywaniu dysków (TrueNAS nie utworzy puli bez unikalnych numerów seryjnych).
  • Pamięć RAM ustawcie na sztywno i wyłączcie Ballooning - ZFS zakłada wyłączną kontrolę nad RAM-em (cache ARC), w przeciwnym razie grozi to kernel panic.
  • Dyski w jednej puli ZFS muszą mieć tę samą pojemność - mniejszy dysk obcina wszystkie pozostałe do swojego rozmiaru.
  • Po utworzeniu puli nie udostępniacie całego dysku - tworzycie DataSety, użytkowników tylko do SMB i nadajecie im uprawnienia (ACL).

1) TrueNAS SCALE czy CORE?

TrueNAS SCALE (bazujący na Debianie, podobnie jak Proxmox) to obecnie lepszy wybór niż starsza wersja CORE - pozwala łatwo skalować pulę, dokładając pojedyncze dyski, bez przebudowywania całej macierzy i przenoszenia danych. CORE bywa w tym względzie bardziej sztywny.

Sercem obu wersji jest ZFS - system plików, który natywnie dba o integralność danych, koryguje błędy w locie i obsługuje migawki (snapshots).

Złota zasada: ZFS został zaprojektowany, by rozmawiać bezpośrednio z fizycznym sprzętem. Nie twórzcie wirtualnych dysków (.qcow2) pod dane - użyjcie Disk Passthrough.

2) Wymagania i pobranie obrazu ISO

Minimalne wymagania dla VM z TrueNAS:

  • RAM: min. 8 GB - ZFS zużywa RAM jako pamięć podręczną ARC (Adaptive Replacement Cache), czyli trzyma w niej najczęściej używane dane i metadane, żeby czytać je błyskawicznie z pamięci zamiast za każdym razem sięgać na wolniejszy dysk; im więcej RAM-u, tym większy i skuteczniejszy cache.
  • CPU: min. 2 rdzenie, typ Host.
  • Dysk systemowy: ok. 32 GB, wyłącznie pod system operacyjny (dane trzymacie na osobnych dyskach).

Pobranie ISO najwygodniej zrobić bez pośredniego kroku „pobierz na dysk → wgraj do Proxmoxa”:

  1. Na stronie TrueNAS skopiujcie link do wybranego obrazu .iso (prawy klawisz → Copy link), zamiast go od razu pobierać.
  2. W Proxmoxie: Datacenter → wasz node → localISO ImagesDownload from URL, wklejcie link i zatwierdźcie.
  3. Proxmox pobierze plik bezpośrednio na storage - oszczędzacie sobie ręcznego uploadu.

Zwróćcie uwagę na wersję: na stronie pobierania TrueNAS widać, która wersja jest aktualnie stabilna (oznaczona jako General), a która to nowsza wersja dla early adopterów. Do domowego NAS-a, na którym ma leżeć realne dane, wybierajcie stabilną.

3) Tworzenie maszyny wirtualnej w Proxmoxie

  • Create VM → nadajcie ID i nazwę (np. TrueNAS), zaznaczcie Start at boot.

  • OS: wskażcie pobrane ISO TrueNAS, Type: Linux.

  • System: zmieńcie BIOS z SeaBIOS na OVMF (UEFI) - wymagane przez TrueNAS do poprawnego bootowania i obsługi nowych tablic partycji (Machine type automatycznie przełączy się na q35). Dodajcie dysk EFI.

    Krytyczne: przy dodawaniu dysku EFI odznaczcie Pre-Enrolled keys. Zaznaczenie tej opcji włącza Secure Boot i wgrywa certyfikaty zaufania (m.in. Microsoftu) - instalator TrueNAS ich nie rozpozna i odmówi bootowania (Failed to Load). Zostawcie puste - TrueNAS zaufa dyskowi i wgra tam własny bootloader GRUB.

  • Kontroler SCSI: VirtIO SCSI single.

  • Graphic card: zmieńcie na VirtIO-GPU - domyślna karta bywa niekompatybilna i potrafi zawiesić lub zaciemnić ekran instalatora/konsoli TrueNAS.

  • Disks: dysk systemowy ~32 GB.

    • Cache: No cache (unika podwójnego buforowania przez hosta i gościa; TrueNAS sam zarządza zapisem) lub opcjonalnie Write back (szybszy zapis kosztem bezpieczeństwa przy nagłym zaniku zasilania).
    • Zaznaczcie Discard, jeśli Proxmox stoi na SSD/NVMe - włącza TRIM, wydłuża żywotność nośnika.
  • CPU: min. 2 rdzenie, Type: Host - daje bezpośredni dostęp do instrukcji fizycznego CPU, co realnie przyspiesza operacje na macierzy i szyfrowanie dysków (emulowany typ byłby tu zauważalnie wolniejszy).

    Koszt wyboru Host: trudniejsza migracja na żywo (HA) między węzłami klastra. W tym scenariuszu to żaden problem - skoro i tak przekazujecie fizyczne dyski (Disk Passthrough), VM nie da się migrować na inny host bez tych samych dysków. Niezawodność (HA) dla NAS-a realizujecie inaczej: drugi fizyczny TrueNAS na innym hoście oraz natywna replikacja ZFS.

  • Memory: odznaczcie Ballooning, wpiszcie twardą wartość, np. 8192 MB (orientacyjnie ok. 1 GB RAM na 1 TB przestrzeni w puli - jeśli macie więcej RAM-u, przydzielcie więcej, poprawi to działanie cache'u).

    Dlaczego to ważne? Tę przydzieloną pamięć ZFS trzyma pod swoim wyłącznym zarządem jako ARC (Adaptive Replacement Cache) - opisany w sekcji 2 mechanizm cache'owania, dzięki któremu odczyt najczęściej używanych danych i metadanych dzieje się z RAM-u, a nie z wolniejszego dysku. Włączony Ballooning oznacza, że Proxmox dynamicznie zabiera/oddaje RAM w locie - dla ZFS to katastrofa: spadki wydajności, a w skrajnym przypadku kernel panic i uszkodzenie danych.

  • Network: zostawcie VirtIO (paravirtualized).

Po zamknięciu kreatora nie startujcie jeszcze VM - najpierw Disk Passthrough.

4) Disk Passthrough - przekazywanie fizycznych dysków

W konsoli (Shell) węzła Proxmox:

ls -l /dev/disk/by-id/ | grep -v "-part"

Dopisek | grep -v "-part" ukrywa partycje i zostawia czystą listę urządzeń. Szukajcie dysków przeznaczonych na dane (zwykle ata-... lub nvme-...) i skopiujcie ich pełne ścieżki - numer seryjny, który zaraz wpiszecie w komendzie qm set, to najczęściej po prostu ostatni człon tej samej nazwy, po myślniku (np. w ata-WDC_WD40EFRX-...-WD-XXXXXXXXX będzie to WD-XXXXXXXXX).

Podepnijcie je pod VM (zastąpcie 102 swoim ID maszyny):

qm set 102 -scsi1 /dev/disk/by-id/ata-nazwa-dysku-1,serial=NUMER_SERYJNY_1
qm set 102 -scsi2 /dev/disk/by-id/ata-nazwa-dysku-2,serial=NUMER_SERYJNY_2

Parametr serial jest obowiązkowy. Numer seryjny widać zwykle jako ostatni człon nazwy by-id (po myślniku) albo na naklejce dysku. Bez niego TrueNAS widzi tylko generyczne „dyski QEMU” - w nowszych wersjach systemu brak unikalnych numerów seryjnych całkowicie blokuje utworzenie puli, bo TrueNAS nie potrafi jednoznacznie odróżnić dysków od siebie. Przy awarii numer seryjny w interfejsie od razu wskaże, który dysk wymienić.

Podpięte dyski zobaczycie od razu w zakładce Hardware maszyny wirtualnej.

5) Częste błędy przy pierwszym uruchomieniu

Dwa problemy pojawiają się na tyle często, że warto je znać zanim wystąpią:

  • Failed to Load / instalator nie startuje - to efekt zaznaczonej opcji Pre-Enrolled keys przy dysku EFI (patrz sekcja 3). Aby naprawić zatrzymajcie VM (Stop, nie Restart), usuńcie dysk EFI, dodajcie go ponownie z odznaczoną opcją Pre-Enrolled keys, uruchomcie ponownie.
  • Zamrożony lub czarny ekran instalatora - to niekompatybilna karta graficzna. Zatrzymajcie VM, w Hardware zmieńcie Graphic card na VirtIO-GPU, uruchomcie ponownie.

Jeśli po podłączeniu dysków bez parametru serial TrueNAS odmawia utworzenia puli: zatrzymajcie VM, odepnijcie (Detach) i usuńcie dyski w Hardware, powtórzcie komendy qm set z dopisanym ,serial=..., uruchomcie VM ponownie.

6) Instalacja TrueNAS

  1. StartConsole.
  2. Wybierzcie Install/Upgrade.
  3. Jako dysk docelowy wskażcie mały wirtualny napęd systemowy (32 GB, zwykle sda/vda) - nie wybierajcie tu przekazanych dysków na dane.
  4. Ustawcie silne hasło dla konta truenas_admin.
  5. Potwierdźcie bootowanie w trybie EFI/UEFI i poczekajcie na koniec instalacji.
  6. System poprosi o restart - w HardwareCD/DVD Drive wybierzcie Do not use any media, usuńcie zamontowane ISO i zrestartujcie VM.

Po restarcie na konsoli zobaczycie adres IP przydzielony przez DHCP (np. http://192.168.1.50) - wejdźcie na niego z przeglądarki i zalogujcie się jako truenas_admin.

Każdy z dostępem do konsoli VM w Proxmoxie ma też bezpośredni dostęp do konsoli TrueNAS bez dodatkowego logowania - pilnujcie, kto ma dostęp do samego Proxmoxa.

7) Tworzenie puli (Pool) i wybór topologii VDEV

StorageCreate Pool. Interfejs sam wykryje przekazane dyski wraz z numerami seryjnymi. Do wyboru macie m.in.:

  • Stripe - dyski po prostu sumują pojemność, brak redundancji. Awaria jednego dysku = utrata wszystkich danych w puli. Odradzane dla danych, które chcecie zachować.
  • Mirror (RAID 1) - pełna kopia na min. 2 dyskach. Awaria jednego dysku nie kosztuje Was danych.
  • RAID-Z1 (RAID 5) - pojemność jednego dysku idzie na dane kontrolne (tzw. parzystość), z których ZFS odtworzy zawartość w razie awarii. Min. 3 dyski, przetrwa awarię jednego napędu.
  • RAID-Z2 (RAID 6) - to samo, ale na danych kontrolnych "tracicie" pojemność dwóch dysków. Min. 4 dyski, przetrwa jednoczesną awarię dwóch napędów.

Pułapka rozmiaru dysków: wszystkie dyski w puli muszą mieć tę samą pojemność. Zmieszacie np. dwa dyski 4 TB z jednym 2 TB? ZFS obetnie wszystkie do 2 TB - nadwyżka przepada, dopóki nie wymienicie najmniejszego dysku na większy.

Deklarowane a rzeczywiste TB: producenci często liczą 1 TB jako 1000 GB (dziesiętnie), a ZFS raportuje w jednostkach binarnych (TiB) - dysk „4 TB” pokaże się w puli jako ok. 3,64 TiB. To normalne, nie błąd.

Opcjonalnie, przy większej liczbie dysków, dostępne są jeszcze: dysk Spare (stoi w gotowości i automatycznie zastępuje uszkodzony dysk w puli - przydatne, gdy nie macie fizycznego dostępu do serwera na bieżąco), oraz osobne dyski (najlepiej SSD/NVMe) pod Cache/L2ARC i metadane, przyspieszające odczyt/zapis.

Włączcie Encryption, jeśli w puli będą dane wrażliwe - bez klucza nikt nie odczyta danych nawet mając fizyczny dostęp do dysków. Zatwierdźcie Create Pool (dyski zostaną wyczyszczone do zera - upewnijcie się, że wybraliście właściwe).

8) DataSety, użytkownicy SMB i uprawnienia (ACL)

Sama pula to fundament - całego dysku się nie udostępnia. Zamiast tego tworzycie DataSety: coś jak udostępnione katalogi, z których każdy może mieć własne limity miejsca, migawki, kompresję i uprawnienia. (Opcja Add Zvol obok DataSetu to co innego - wirtualny wolumen blokowy pod np. iSCSI, na razie ją pomijacie.)

Krok 1 - użytkownik tylko do SMB. Nie logujcie się do udziałów kontem truenas_admin. W Credentials → Users → Add utwórzcie konto (np. darek), ustawcie hasło i zaznaczcie Samba Authentication - bez tej flagi użytkownik nie zaloguje się do udziału sieciowego. Jeśli konto ma służyć wyłącznie do SMB, możecie pominąć tworzenie katalogu domowego i nie nadawać dostępu przez shell/SSH.

Krok 2 - DataSet. Storage → wasza pula → Add Dataset. Nadajcie nazwę (np. Home) i w Share Type wybierzcie SMB - TrueNAS dobierze wtedy parametry optymalne pod Windows (m.in. wyłącza wrażliwość na wielkość znaków). W Advanced Options warto też wyłączyć Enable Atime, jeśli używacie dysków talerzowych (HDD) - inaczej każdy odczyt pliku zapisuje log dostępu, co generuje zbędny ruch głowicy.

Krok 3 - udział SMB i ACL. Shares → Windows (SMB) Shares → Add, wskażcie DataSet. Przy pierwszym udostępnieniu system zapyta o konfigurację ACL. Typowe scenariusze:

  • Zasób prywatny: szablon Restricted, usuńcie domyślne grupy, zostawcie właściciela z Full Control. Reszta sieci nie ma dostępu.
  • Zasób współdzielony: szablon Open, dodajcie grupę builtin_users (trafiają tam wszyscy nowi użytkownicy lokalni) z uprawnieniem Modify.
  • Zasób tylko do odczytu (np. archiwum zdjęć): właściciel z Full Control, grupa builtin_users z Read - nikt przez pomyłkę nie skasuje zbiorów.
  • Zasób dla wybranych: szablon Restricted, właściciel z Full Control, Add Item → konkretny użytkownik (np. ania) z Read lub Modify. Reszta sieci nadal bez dostępu.

Nic nie stoi na przeszkodzie, by powtórzyć kroki 2–3 kilka razy i mieć osobne DataSety dla każdego domownika czy kategorii danych (Home, Kids, Videos) - każdy z własnymi uprawnieniami.

Podsumowanie i co dalej

Wirtualny TrueNAS z poprawnym Disk Passthrough i twardo przydzieloną pamięcią bez Ballooningu nie ustępuje fizycznemu NAS-owi ani stabilnością, ani wydajnością.

To dopiero początek możliwości. TrueNAS SCALE ma wbudowany katalog aplikacji, dzięki któremu na tym samym serwerze postawicie np. Immich - odpowiednik Zdjęć Google, z rozpoznawaniem twarzy i tagowaniem AI, ale działający wyłącznie lokalnie, na waszych dyskach. Zamiast wgrywać zdjęcia z telefonu do Google Photos czy pliki do Google Drive, trzymacie je u siebie - i to wy, a nie zewnętrzna firma, decydujecie, kto ma do nich dostęp. To jest prawdziwa siła posiadania własnego homelabu.

W kolejnej części: hardening TrueNAS - zarządzanie uprawnieniami przez grupy, automatyczne kopie zapasowe (Cloud Sync), migawki ZFS jako ochrona przed ransomware, oraz bezpieczny dostęp do zasobów homelabu spoza sieci domowej przez VPN (WireGuard).

Linki (oficjalne źródła)


Jeśli postawiliście już swoją pierwszą pulę ZFS, dajcie znać w komentarzu do filmu YT, jaką topologię wybraliście i na jakich dyskach działacie.


Ten wpis był pomocny? Postaw mi kawę, abym miał energię do tworzenia kolejnych treści.

Postaw mi kawę