Nie ścigaj się na CPU przy serwerze Raspberry Pi
Wkładasz kartę microSD do czytnika, uruchamiasz Raspberry Pi Imager i nagrywasz obraz — to konkretny moment, od którego rusza cały serwer, bo wersja systemu i nośnik decydują o reszcie.
Pierwsze uruchomienie
To banalne, ale ważne: krok pierwszy to faktycznie „włóż kartę microSD do czytnika kart w komputerze, otwórz Raspberry Pi Imager i wybierz system” — to nie rytuał, to przygotowanie środowiska. Karta SD działa, ale traktowanie jej jako głównego nośnika dla usług użytkowych to kompromis wydajności i trwałości.
Gdzie leży realna wydajność
W praktyce dla serwera domowego i małego biura większy wpływ ma I/O i sieć niż dodatkowe megahercy.
Dlatego SSD podłączony do USB3 razem z kablowym Ethernetem i statycznym adresem IP (oraz opcjonalną nazwą domeny) dają więcej realnej wydajności niż gonitwa za „najmocniejszym” modelem CPU. Dla serwera plików lepszym wyborem jest Nextcloud na SSD niż kilkanaście HDD podłączonych chaotycznie.
Praktyczny przykład z warsztatu
Mój pierwszy Pi 4B działał miesiącami jako Nextcloud na SSD i dowiódł, że ten układ jest praktyczny i stabilny przy poprawnej konfiguracji — to nie teoria to deployment na jors.pl który faktycznie służył użytkownikom przez dłuższy czas. Podczas testów: czy inwestować w ECC RAM dla domowego serwera. Opisałem gdzie pamięć ECC ma sens i gdzie jest tylko koszt.
Konfiguracja która ma ręce i nogi
W praktyce: wybierz Raspberry Pi 4B, podłącz SSD w obudowie USB3 obsługującej UASP. Skonfiguruj kablowy Ethernet i przypisz statyczny adres IP w routerze. Ustaw SSH i ewentualnie VNC w lokalnej sieci, żeby nie bawić się fizycznie przy każdym drobnym remoncie konfiguracji. Zamiast podpinać kilka zewnętrznych talerzy pod USB, lepiej jeden SSD z porządną konfiguracją backupu i regularną kopią zapasową poza urządzeniem.
RAID nie zastępuje kopii zapasowych a chaotyczne doklejanie dysków podpiętych ad-hoc najczęściej prowadzi do problemów z IOPS i zwiększa koszty, nie do większej niezawodności.