Budowa sensownego magazynu danych zaczyna się od dysków i partycji, bo to one decydują o odporności na awarię, wygodzie rozbudowy i tym, czy odzyskanie plików będzie prostą wymianą nośnika, czy długą walką z układem storage. W praktyce serwer NAS wygrywa wtedy, gdy system plików, redundancja i layout nośników są dobrane do rzeczywistego obciążenia, a nie do samej pojemności obudowy. W tym tekście pokazuję, jak ja dobieram dyski, kiedy partycje mają sens, a kiedy tylko komplikują życie.
Najważniejsze decyzje przy NAS sprowadzają się do trzech pytań: co chronisz, czym chronisz i gdzie kończy się bezpieczeństwo.
- Najpierw ustal profil pracy: archiwum, backup, multimedia, a może maszyny wirtualne.
- Przy ZFS najczęściej lepiej sprawdzają się całe dyski niż partycje.
- Btrfs daje elastyczność, ale RAID5/6 nadal nie jest układem, na którym budowałbym ważne dane.
- mdadm z ext4 albo XFS to prosta i przewidywalna opcja na Linuksie.
- Przy dużych dyskach zostawiaj co najmniej 15-20% wolnego miejsca.
- Backup poza NAS-em to osobny obowiązek, nie dodatek.
Co trzeba ustalić, zanim wybierzesz dyski
Ja zawsze zaczynam od pytania, czy ten system ma być archiwum zdjęć, magazynem kopii zapasowych, serwerem multimediów czy zapleczem dla maszyn wirtualnych. To nie jest drobiazg: archiwum wymaga głównie pojemności, a VM i bazy danych potrzebują niskich opóźnień oraz wysokiego IOPS, czyli liczby operacji wejścia i wyjścia na sekundę. Dopiero potem patrzę na liczbę zatok, hałas, pobór mocy i to, czy sprzęt ma przetrwać pojedynczą awarię bez paniki.
W praktyce inne dyski wybieram do spokojnego przechowywania filmu rodzinnego, a inne do katalogu, w którym jednocześnie zapisuje się dużo małych plików. Dyski 5400 rpm są zwykle chłodniejsze i cichsze, ale przy intensywnej pracy ustępują 7200 rpm. SSD ma sens tam, gdzie ważniejsze są małe bloki i niskie opóźnienia niż sama liczba terabajtów.
- Jeśli trzymasz głównie zdjęcia, dokumenty i backupy, priorytetem jest pojemność oraz prostota odzyskania danych.
- Jeśli NAS ma serwować multimedia, liczy się przepustowość i stabilność odczytu, a nie maksymalny benchmark.
- Jeśli ma obsługiwać VM, kontenery albo współdzielone projekty, lepiej zaplanować SSD lub hybrydę SSD + HDD.
Od tej decyzji zależy, czy sens ma prosta kopia lustrzana, czy bardziej rozbudowany układ z parzystością i osobną warstwą systemową.
Czy lepiej użyć całych dysków, partycji czy wolumenów
W dokumentacji OpenZFS zalecenie jest proste: jeśli możesz, oddaj puli całe dyski, a nie wydzielone partycje. To upraszcza układ, zmniejsza liczbę punktów, w których można popełnić błąd, i zwykle pomaga w poprawnym wyrównaniu bloków. Ja traktuję partycje jako narzędzie do odseparowania systemu, bootowania albo szyfrowania, a nie jako domyślny sposób budowania samej puli danych.
| Model | Kiedy ma sens | Plusy | Minusy |
|---|---|---|---|
| Całe dyski | ZFS, często także Btrfs, gdy nie potrzebujesz osobnego cięcia każdego nośnika | Prosty układ, mniej warstw pośrednich, zwykle lepsze wyrównanie | Mniej elastyczny podział miejsca na jednym dysku |
| Partycje | mdadm, oddzielenie boot od danych, szyfrowanie, nietypowe ograniczenia sprzętowe | Większa kontrola nad layoutem, łatwe wydzielenie EFI i systemu | Więcej pracy przy planowaniu i większe ryzyko błędów |
| Wolumeny logiczne | Gdy chcesz elastycznie dzielić przestrzeń na LVM po macierzy | Łatwiejsze rozszerzanie i dzielenie miejsca między usługi | Kolejna warstwa do zrozumienia i utrzymania |
Jeśli muszę użyć partycji, zaczynam od wyrównania na 1 MiB, a nie od starych układów z przypadkowym początkiem nośnika. To drobny detal, ale właśnie takie szczegóły potrafią potem wywołać read-modify-write, czyli zapis małych zmian po wcześniejszym odczytaniu i przerobieniu całego bloku, co niepotrzebnie obciąża dyski.
Gdy warstwa fizyczna jest już jasna, można przejść do pojemności i redundancji, bo tutaj najłatwiej o decyzję, która wygląda dobrze tylko na papierze.
Jak dobrać liczbę i pojemność dysków
Ja wolę nie planować macierzy pod samą pojemność. Przy NAS-ie ważniejsze jest to, ile danych zostaje po awarii, jak długo potrwa odbudowa i czy podczas tego procesu system nadal będzie działał bez nerwów. Im większe dyski, tym mniej atrakcyjny robi się układ z jedną parzystością, bo odbudowa trwa dłużej, a okno ryzyka rośnie.
| Układ | Użyteczna pojemność | Ochrona | Mój komentarz |
|---|---|---|---|
| Mirror | 50% sumy nośników | Awaria 1 dysku | Najprostszy wybór dla 2 zatok i danych, które naprawdę mają znaczenie |
| RAIDZ1 / RAID5 | (N - 1) nośników | Awaria 1 dysku | Przy większych talerzach bywa kuszący, ale ja patrzę na niego ostrożnie |
| RAIDZ2 / RAID6 | (N - 2) nośniki | Awaria 2 dysków | Rozsądny kompromis dla 4-6 zatok, gdy dane są ważniejsze niż maksymalny wynik |
W praktyce trzy zasady robią największą różnicę. Po pierwsze, biorę możliwie identyczne pojemności, bo miks 4 TB i 8 TB zwykle kończy się stratą części miejsca. Po drugie, zostawiam 15-20% wolnej przestrzeni, bo pełna pula działa gorzej i trudniej się utrzymuje. Po trzecie, przy 2 zatokach wybieram mirror, a przy 4 lub więcej poważnie rozważam RAIDZ2 albo RAID6, jeśli dane są ważne.
Przy 3 zatokach robi się najbardziej kompromisowo: albo akceptujesz RAIDZ1 z jedną warstwą parzystości, albo rezygnujesz z pełnej pojemności na rzecz bardziej konserwatywnego układu z kopią lustrzaną i rezerwą. Ja ten rozmiar obudowy uważam za najmniej wygodny do planowania, bo zmusza do wyboru między przestrzenią a spokojem.
Który system plików sprawdza się najlepiej w NAS
Sam dobór dysków nie załatwia sprawy, jeśli system plików jest źle dobrany do sposobu pracy. Ja patrzę na to tak: ZFS daje bardzo dobrą kontrolę integralności i snapshoty, Btrfs daje elastyczność i nowoczesne funkcje na Linuksie, a mdadm z ext4 lub XFS wygrywa prostotą oraz przewidywalnością. Każde z tych rozwiązań może być dobre, ale nie do tego samego scenariusza.
Btrfs ma sens wtedy, gdy chcesz nowoczesnych funkcji na Linuksie, ale dokumentacja Btrfs nadal ostrzega przed używaniem RAID5/6 w produkcji. To dla mnie wystarczający sygnał, żeby ważnych danych nie budować właśnie na takim układzie. Jeśli potrzebujesz elastyczności, użyj mirrorów albo prostszego schematu, zamiast liczyć, że problem sam zniknie.
| System plików | Co daje | Kiedy bym go wybrał | Na co uważać |
|---|---|---|---|
| ZFS | Sumy kontrolne, scrub, snapshoty, bardzo dobra ochrona integralności | Gdy dane są cenne i chcesz możliwie spójnej warstwy storage | Zwykle najlepiej działa na całych dyskach i lubi sensowną ilość RAM |
| Btrfs | Snapshoty, subvolumes, kompresję, elastyczne zarządzanie urządzeniami | Gdy chcesz nowoczesny system plików mocno związany z Linuksem | Nie polecałbym RAID5/6 dla ważnych danych |
| ext4 / XFS + mdadm / LVM | Prostą, stabilną i szeroko wspieraną bazę | Gdy najważniejsza jest przewidywalność i łatwość utrzymania | Ochrona danych zależy bardziej od RAID i backupu niż od samego FS |
Jeśli mam wybrać rozwiązanie dla kogoś, kto chce po prostu mieć porządny, linuxowy magazyn danych, często kończę właśnie na mdadm plus XFS albo na ZFS. Pierwsze jest prostsze, drugie bardziej samodzielne w pilnowaniu spójności danych. W obu przypadkach ważniejsze od nazwy jest to, czy umiesz to utrzymać przez lata.
Jak wygląda sensowny układ partycji w praktyce
Ja w praktyce oddzielam system od danych, zamiast wciskać wszystko w jeden fizyczny worek. Dla UEFI rezerwuję zwykle 512 MiB na partycję EFI, a sam system potrafi spokojnie zmieścić się w 16-32 GB, jeśli mówimy o typowym serwerze domowym. Reszta miejsca powinna pracować na dane, nie na sztuczny podział dla samego podziału.
| Scenariusz | Układ | Dlaczego właśnie tak |
|---|---|---|
| Domowy NAS z 2 zatokami | 2 identyczne HDD w mirrorze, system na osobnym SSD lub parze SSD | Najprostsza odbudowa i brak ryzyka, że awaria jednego nośnika wyłączy system oraz dane naraz |
| NAS do zdjęć i wideo z 4 zatokami | 4 identyczne HDD w RAIDZ2 lub RAID6, osobny boot SSD | Dwa nośniki parzystości mają sens, gdy odbudowa dużych dysków może trwać bardzo długo |
| Homelab z VM | SSD mirror na maszyny wirtualne, HDD mirror albo RAIDZ na archiwum | Łączy niskie opóźnienia dla aktywnych usług z dużą pojemnością na pliki |
Jeśli muszę dzielić dyski na partycje, robię to tylko tam, gdzie naprawdę coś zyskuję: osobny boot, osobna strefa systemowa, osobne dane albo szyfrowanie. Nie rozcinam każdego nośnika na kilka równorzędnych fragmentów tylko po to, żeby wyglądało to schludnie w panelu administracyjnym.
Ten układ działa najlepiej wtedy, gdy jest prosty do odtworzenia po awarii. Gdy wchodzą złożone warstwy, szybko pojawia się problem z odzyskiem, migracją albo samym zrozumieniem, co gdzie leży.
Najczęstsze błędy, które psują nawet dobry zestaw
Najgorszy błąd, jaki widzę, to traktowanie RAID jak kopii zapasowej. RAID chroni przed awarią nośnika, ale nie przed skasowaniem plików, błędem użytkownika, ransomware ani uszkodzeniem logicznym. Drugi błąd to mieszanie dysków o różnych pojemnościach bez policzenia, ile realnie stracisz przestrzeni.
- Brak backupu poza NAS-em - macierz nie zastępuje kopii w innym miejscu.
- Zły dobór układu do pojemności dysków - przy dużych nośnikach odbudowa może trwać wiele godzin, a czasem dłużej niż dobę.
- Ignorowanie wolnego miejsca - zbyt pełna pula działa gorzej i trudniej ją utrzymać.
- Złe wyrównanie partycji - potrafi obniżyć wydajność i zwiększyć zbędne zapisy.
- Btrfs RAID5/6 do ważnych danych - to nadal układ, którego nie polecałbym do spokojnej pracy produkcyjnej.
- Brak rutyny kontroli - ja ustawiam scrub raz w miesiącu i sprawdzam SMART przynajmniej raz w tygodniu.
Poza tym warto od razu zaplanować, co zrobisz po pierwszej awarii: który dysk kupujesz, jak długo potrwa rebuild i czy masz miejsce, żeby system przez ten czas nie pracował na granicy wydolności. To właśnie takie detale odróżniają rozsądny magazyn danych od zestawu, który tylko dobrze wygląda na liście komponentów.
Kiedy te błędy są już wyeliminowane, zostaje ostatnia rzecz: wybranie wariantu, który jest prosty dla ciebie, a nie imponujący na slajdzie producenta.
Gdybym składał taki NAS dziś, wybrałbym jeden z trzech układów
Gdybym dziś składał domowy system od zera, zacząłbym od prostoty, nie od maksymalnej pojemności. Dla 2 zatok wybrałbym mirror na identycznych HDD i osobny nośnik dla systemu. Dla 4 zatok postawiłbym na RAIDZ2 albo RAID6, jeśli dane są ważniejsze niż każdy dodatkowy terabajt. Przy 6 zatokach i więcej zacząłbym myśleć o przyszłych wymianach dysków, a nie tylko o tym, jak zapełnić całą obudowę od pierwszego dnia.
- 2 zatoki - mirror, bo daje najprostsze odzyskanie po awarii jednego dysku.
- 4 zatoki - RAIDZ2 lub RAID6, bo lepiej znoszą dłuższą odbudowę dużych nośników.
- 6 zatok i więcej - układ pod przyszłe rozszerzanie, migracje i rezerwy pojemnościowe.
Jeśli mam zostawić jedną zasadę, to jest nią rozdzielenie wygody od bezpieczeństwa: system może być prosty, ale dane powinny mieć co najmniej jedną warstwę ochrony więcej niż samą pojemność dysków. RAID pomaga przetrwać awarię nośnika, lecz dopiero backup zamyka temat i daje realny spokój.
