OpenMediaVault 5 do OMV 8 na Fujitsu FUTRO S900 – czysta instalacja bez utraty danych

Mój domowy NAS oparty na terminalu Fujitsu FUTRO S900 działał bez większych problemów przez kilka lat. Sprzęt nadal spełniał swoje zadanie, ale system zdążył się mocno zestarzeć. Na serwerze pracował Debian 10 Buster z OpenMediaVault 5.6.26 Usul, czyli środowisko, które dawno wypadło już z normalnego cyklu wsparcia.

Sam NAS nie wykonuje skomplikowanych zadań. Ma przede wszystkim działać jako prosty i energooszczędny serwer plików dostępny w sieci lokalnej. Nie potrzebuję na nim Kubernetes, dziesiątek kontenerów czy serwera multimediów. Zależało mi natomiast na aktualnym systemie, działającym SMB, wygodnym dostępie przez SSH, monitoringu dysków i rozwiązaniu ograniczającym liczbę zapisów na systemowym SSD.

Zamiast próbować wykonywać wieloetapową aktualizację OMV 5 przez kolejne generacje zdecydowałem się na czystą instalację OpenMediaVault 8. Najważniejsze założenie było proste – system instaluję od zera na SSD, natomiast osobnego HDD z danymi w ogóle nie ruszam.

Fujitsu FUTRO S900 jako domowy NAS

Podstawą serwera nadal jest Fujitsu FUTRO S900. To stary terminal typu thin client, ale do takiego zastosowania nadal sprawdza się zaskakująco dobrze.

Moja konfiguracja wygląda następująco:

• Fujitsu FUTRO S900
• AMD G-T44R 1,2 GHz
• 8 GB RAM
• SSD XrayDisk 60 GB mSATA na system
• HDD Seagate ST1000LM035 1 TB na dane
• Gigabit Ethernet
• jeden główny udział sieciowy SMB

Wcześniej systemem był:

Debian GNU/Linux 10 Buster
OpenMediaVault 5.6.26 Usul

Po modernizacji serwer działa na:

Debian GNU/Linux 13.7 Trixie
OpenMediaVault 8.5.9

Do tego doszły między innymi OMV-Extras, WriteCache, TempMon i Diskstats.

Sprzęt jest oczywiście słaby jak na dzisiejsze standardy, ale jako prosty serwer plików nie musi być szybki w obliczeniach. Ważniejsze są niski pobór energii, cicha praca i stabilność.

Dlaczego wybrałem czystą instalację zamiast aktualizacji OMV 5

Przeskok z OMV 5 do OMV 8 oznacza przejście przez kilka generacji zarówno OpenMediaVault, jak i Debiana. Można próbować wykonywać kolejne upgrade’y, ale w przypadku kilkuletniej instalacji pojawia się coraz więcej miejsc, w których coś może pójść nie tak.

W moim przypadku konfiguracja NAS-a była bardzo prosta. System znajdował się na osobnym SSD, a wszystkie ważne dane na drugim fizycznym HDD. To właściwie idealna sytuacja do czystej instalacji.

Dzięki temu:

• nie przenosiłem starych zależności i pakietów,
• nie musiałem naprawiać archiwalnych repozytoriów Debiana 10,
• dostałem czysty Debian 13,
• mogłem skonfigurować OMV od początku tylko z tymi usługami, których faktycznie używam,
• dysk z danymi pozostał nietknięty.

Najważniejsze było jednak wcześniejsze zebranie kilku informacji ze starego systemu.

Co warto sprawdzić przed reinstalacją OpenMediaVault

Pierwszą rzeczą było ustalenie, który dysk jest systemowy, a który przechowuje dane.

lsblk -f

W moim przypadku układ wyglądał tak:

sda1 ext4 Magazyn 576386ca-990e-40cd-ada7-90ded37a3720
sdb1 ext4 711b3772-3460-437a-8ca7-9c4b1cd25855 /

/dev/sda1 był HDD z danymi, a /dev/sdb1 systemowym SSD.

Dodatkowo sprawdziłem punkty montowania:

df -hT

HDD był zamontowany jako:

/srv/dev-disk-by-uuid-576386ca-990e-40cd-ada7-90ded37a3720

UUID warto zapisać. Nazwy /dev/sda i /dev/sdb mogą się zmieniać, natomiast UUID systemu plików pozostaje ten sam.

UID i GID użytkownika – rzecz, o której łatwo zapomnieć

Przed reinstalacją sprawdziłem również użytkowników:

getent passwd | grep -v nologin

Moje konto miało:

8art33z:x:1000:100

Oznacza to:

UID 1000
GID 100

Następnie sprawdziłem właścicieli danych:

ls -ln /srv/dev-disk-by-uuid-576386ca-990e-40cd-ada7-90ded37a3720/

Większość plików i katalogów należała do:

1000 100

To bardzo istotne. Linux nie zapisuje właściciela pliku jako nazwy użytkownika, tylko jako numery UID i GID. Jeżeli więc po reinstalacji utworzymy użytkownika z tymi samymi numerami, stare pliki automatycznie będą do niego pasowały.

Nie trzeba później wykonywać chown na kilkuset gigabajtach danych.

Sprawdzenie ACL przed migracją

Sprawdziłem również ACL katalogu głównego dysku:

getfacl /srv/dev-disk-by-uuid-576386ca-990e-40cd-ada7-90ded37a3720/

Wynik:

# owner: root
# group: users
user::rwx
group::rwx
other::r-x
default:user::rwx
default:group::rwx
default:other::r-x

Przykładowe katalogi należące do mojego użytkownika miały właściciela 8art33z, grupę users i analogiczne prawa.

Nie było więc żadnej skomplikowanej struktury ACL, którą należałoby później odtwarzać ręcznie.

Jak wyglądał stary udział SMB

Konfigurację Samby można szybko podejrzeć poleceniem:

sudo testparm -s

U mnie udział wyglądał mniej więcej tak:

[NAS]
path = /srv/dev-disk-by-uuid-576386ca-990e-40cd-ada7-90ded37a3720/
read only = No
browseable = Yes
valid users = 8art33z
write list = 8art33z

Czyli udział NAS wskazywał bezpośrednio na katalog główny HDD. To również warto wiedzieć przed reinstalacją, ponieważ późniejsze odtworzenie konfiguracji sprowadza się właściwie do kilku kliknięć.

Najprostsze zabezpieczenie danych – odłączenie HDD

Po zapisaniu wszystkich potrzebnych informacji wyłączyłem serwer:

sudo poweroff

Następnie fizycznie odłączyłem dysk HDD z danymi.

Moim zdaniem to najlepsze zabezpieczenie podczas instalacji systemu. Można dokładnie wiedzieć, który dysk jest który, ale chwila nieuwagi w instalatorze wystarczy, żeby wybrać niewłaściwe urządzenie.

Jeżeli dysku z danymi fizycznie nie ma w komputerze, instalator nie jest w stanie go przypadkowo sformatować. W FUTRO pozostał więc wyłącznie SSD mSATA 60 GB.

Instalacja OpenMediaVault 8 z Ventoya

Instalator OMV uruchomiłem z pendrive’a przygotowanego wcześniej za pomocą Ventoya.

To rozwiązanie sprawdziło się bardzo dobrze. Nie trzeba za każdym razem nagrywać konkretnego obrazu ISO na pendrive. Wystarczy skopiować ISO na partycję Ventoya, uruchomić komputer z USB i wybrać odpowiedni obraz z menu.

Instalacja OMV przebiegła bez problemów.

Po aktualizacji całego systemu otrzymałem:

Debian GNU/Linux 13.7 Trixie

oraz:

OpenMediaVault 8.5.9-1

Kernel:

7.1.13+deb13-amd64

Zainstalowałem również:

openmediavault-omvextrasorg 8.0.3

Stały adres IP dla NAS-a

NAS powinien mieć stały adres IP. W przeciwnym razie po zmianie dzierżawy DHCP serwer może pojawić się pod innym adresem.

U mnie Vault13 działa pod:

192.168.1.100

Sieć:

192.168.1.0/24

Gateway:

192.168.1.101

Konfigurację ustawiłem bezpośrednio z panelu WWW OpenMediaVault. Stały adres IP jest szczególnie wygodny przy udziałach SMB i połączeniach SSH, bo serwer zawsze jest dostępny w tym samym miejscu.

Użytkownik SSH z tym samym UID

W nowym OMV utworzyłem ponownie użytkownika:

8art33z

Nadałem mu shell:

/usr/bin/bash

oraz grupy:

users
_ssh
sudo

Po zalogowaniu przez SSH sprawdziłem:

id

Wynik:

uid=1000(8art33z) gid=100(users) groups=100(users),27(sudo),102(_ssh)

Dokładnie o to chodziło. Nowy użytkownik dostał taki sam UID i GID jak poprzednio, więc istniejące dane na HDD nadal należą do właściwego konta.

Grupa _ssh pozwala logować się przez SSH, natomiast sudo umożliwia wykonywanie poleceń administracyjnych bez bezpośredniego logowania na konto root.

Katalog domowy na SSD

Po utworzeniu użytkownika logowanie po SSH działało, ale katalog /home/8art33z jeszcze nie istniał.

Ponieważ chciałem, aby katalog domowy administratora pozostał na systemowym SSD, a nie na HDD z danymi, utworzyłem go ręcznie:

sudo install -d -m 750 -o 8art33z -g users /home/8art33z

Po ponownym zalogowaniu:

pwd

zwraca już:

/home/8art33z

Taki układ jest dla mnie najbardziej logiczny. System i katalog domowy użytkownika administracyjnego znajdują się na SSD, a HDD pozostaje wyłącznie magazynem danych.

Ponowne podłączenie HDD z danymi

Dopiero po przygotowaniu podstawowej konfiguracji wyłączyłem NAS, podłączyłem stary HDD i ponownie uruchomiłem system.

Najpierw sprawdziłem:

lsblk -f

Dysk został poprawnie rozpoznany:

sda1
ext4
Magazyn
576386ca-990e-40cd-ada7-90ded37a3720

UUID był dokładnie taki sam jak przed reinstalacją.

Następnie w panelu OMV wszedłem w:

Storage → File Systems

i zamontowałem istniejący system plików.

Tutaj trzeba uważać na jedną rzecz – wybieramy montowanie istniejącego filesystemu. Nie używamy Create, Wipe ani żadnej funkcji formatowania.

Po montowaniu dysk pojawił się ponownie jako:

/srv/dev-disk-by-uuid-576386ca-990e-40cd-ada7-90ded37a3720

Odtworzenie Shared Folder

Kolejnym krokiem było:

Storage → Shared Folders

Utworzyłem nowy Shared Folder:

Name: NAS
File system: Magazyn
Relative path: /

Relative path jest tutaj bardzo ważne.

Wartość:

/

oznacza katalog główny całego istniejącego systemu plików.

Gdybym wpisał:

NAS/

OMV utworzyłby nowy katalog NAS wewnątrz dysku zamiast udostępnić jego dotychczasową zawartość.

Dla użytkownika 8art33z ustawiłem dostęp Read/Write.

Ponowne uruchomienie SMB

W:

Services → SMB/CIFS

włączyłem usługę i utworzyłem udział wskazujący na Shared Folder NAS.

Najważniejsze ustawienia:

Public: No
Read-only: No
Browseable: Yes
Inherit ACLs: Yes

Po zapisaniu konfiguracji wystarczyło na komputerze z Windows wejść pod:

\\192.168.1.100\NAS

i zalogować się jako 8art33z.

Wszystkie dane pojawiły się od razu. Nie wykonywałem żadnego kopiowania i nie przenosiłem plików pomiędzy dyskami. Nowy OpenMediaVault po prostu zamontował istniejący system plików ext4 i ponownie udostępnił go przez SMB.

WriteCache zamiast starego FlashMemory

Na OMV 5 miałem zainstalowany plugin flashmemory, wykorzystujący folder2ram.

Jego zadaniem było ograniczenie liczby zapisów na systemowym SSD. Często modyfikowane katalogi, takie jak logi, były przechowywane w RAM i okresowo synchronizowane z nośnikiem.

W nowym OMV jego odpowiednikiem jest:

openmediavault-writecache

U mnie zainstalowana została wersja:

openmediavault-writecache 8.2.6

Plugin korzysta z tmpfs i overlayfs.

Ustawiłem:

Use system memory: Yes
Memory backing: RAM (tmpfs)
tmpfs size: 25%
Flush on shutdown: Yes
Rotate on shutdown: Yes
Flush hourly: No
Flush daily: Yes
Rotate on daily flush: Yes

Codzienny flush wykonuje się o:

03:45

Przy 8 GB RAM limit 25 procent daje około 1,8-2 GB przestrzeni tmpfs. Nie oznacza to jednak, że pamięć jest rezerwowana z góry. W normalnej pracy WriteCache wykorzystuje u mnie zaledwie niewielką część dostępnego limitu.

Po aktywacji cache takie miejsca jak:

/var/log
/var/cache/samba
/var/lib/apt/lists
/var/lib/openmediavault/rrd
/var/tmp

nie generują już bez przerwy drobnych zapisów bezpośrednio na SSD. To szczególnie przydatne w serwerze działającym przez całą dobę, zwłaszcza gdy system znajduje się na niedrogim lub starszym SSD.

SMART i kondycja HDD

Kolejną rzeczą był monitoring SMART.

Dysk danych to:

Seagate ST1000LM035-1RK172

To 2,5-calowy HDD 5400 rpm. Dysk ma już ponad:

44 000 godzin pracy

czyli mniej więcej pięć lat ciągłego działania.

Mimo tego SMART nadal wygląda bardzo dobrze:

Reallocated_Sector_Ct: 0
Current_Pending_Sector: 0
Offline_Uncorrectable: 0
UDMA_CRC_Error_Count: 0

Temperatura podczas kontroli wynosiła około:

32°C

SMART nie raportował błędów, a wcześniejsze krótkie self-testy kończyły się poprawnie.

Dysk ma spory przebieg, więc oczywiście nie traktuję go jako wiecznego. SMART jest bardzo dobrym narzędziem ostrzegawczym, ale nie zastępuje backupu.

SMART systemowego SSD

Systemowy XrayDisk 60 GB ma również spory przebieg:

41 454 godzin

SMART pokazuje jednak:

Reallocated_Sector_Ct: 0
Current_Pending_Sector: 0
Offline_Uncorrectable: 0
Program_Fail: 0
Erase_Fail: 0
Available_Reserved_Space: 100

Temperatura wynosi około:

41°C

Nie wszystkie atrybuty tego niedrogiego SSD są poprawnie opisane przez smartctl, ponieważ model nie znajduje się w jego bazie. Podstawowe wskaźniki nie pokazują jednak obecnie oznak problemów z pamięcią flash.

Harmonogram testów SMART

Dla HDD ustawiłem:

• short self-test raz w tygodniu,
• long self-test raz w miesiącu.

Dla SSD:

• short self-test raz w tygodniu,
• long self-test raz w miesiącu.

Pełny test Seagate’a trwa około:

165 minut

natomiast extended self-test XrayDiska około:

10 minut

W globalnych ustawieniach SMART włączyłem również monitoring temperatury i ustawiłem taki tryb sprawdzania, aby uśpiony HDD nie był bez potrzeby rozkręcany tylko po to, żeby odczytać SMART.

Powiadomienia mailowe z Gmaila

Sam monitoring niewiele daje, jeśli o problemie dowiem się dopiero po ręcznym wejściu do panelu.

Dlatego skonfigurowałem również powiadomienia mailowe OMV.

Do wysyłki używam Gmaila:

SMTP: smtp.gmail.com
Port: 587
Encryption: STARTTLS
Authentication: Yes

Google nie pozwala w takim przypadku używać zwykłego hasła konta. Po włączeniu uwierzytelniania dwuskładnikowego wygenerowałem osobne hasło aplikacji przeznaczone wyłącznie dla Vault13.

OMV wysyła teraz alerty między innymi dotyczące:

• SMART,
• systemów plików,
• problemów z uwierzytelnianiem,
• aktualizacji,
• istotnych zdarzeń systemowych.

Wyłączyłem natomiast maile o chwilowych skokach CPU, load average czy pamięci RAM. Na tak słabym procesorze krótkie wzrosty obciążenia są normalne i generowałyby więcej szumu niż użytecznych informacji.

Temperatury CPU i GPU

Do monitorowania temperatur doinstalowałem lm-sensors.

Na Fujitsu FUTRO S900 wykrywane są dwa główne sensory:

k10temp
radeon

Pierwszy odpowiada temperaturze procesora, drugi części graficznej APU.

Typowe wartości wynoszą u mnie około:

CPU: 53-55°C
GPU: 53-55°C

Radeon udostępnia dodatkowo napięcie i aktualny zegar układu graficznego.

Polecenie:

sensors -u

pokazuje między innymi dla procesora:

temp1_input: 53.500
temp1_max: 70.000
temp1_crit: 100.000

a dla Radeona:

in0_input: 0.888
temp1_input: 54.000
temp1_crit: 120.000
freq1_input: 276930000.000

TempMon zamiast starego CPU Temp

Początkowo używałem pluginu CPU Temp. Działał, ale jego drugi sensor był na dashboardzie automatycznie opisany jako CPU2, mimo że w rzeczywistości podłączyłem do niego temperaturę Radeona.

Ostatecznie przeszedłem więc na bardziej elastyczny TempMon.

Dzięki temu utworzyłem dwa własne sensory:

CPU
GPU

Każdy może mieć własną nazwę, widget i wykres.

Dla CPU używam skryptu:

#!/bin/sh
for h in /sys/class/hwmon/hwmon*; do
    if [ "$(cat "$h/name" 2>/dev/null)" = "k10temp" ]; then
        cat "$h/temp1_input"
        exit 0
    fi
done

Dla GPU:

#!/bin/sh
for h in /sys/class/hwmon/hwmon*; do
    if [ "$(cat "$h/name" 2>/dev/null)" = "radeon" ]; then
        cat "$h/temp1_input"
        exit 0
    fi
done

W obu przypadkach divisor wynosi:

1000

Dzięki wyszukiwaniu nazwy urządzenia zamiast wpisywania na sztywno np. /sys/class/hwmon/hwmon1/temp1_input konfiguracja jest odporniejsza na zmianę kolejności urządzeń po restarcie.

Własne etykiety lm-sensors

Standardowy wynik sensors zawiera techniczne nazwy. Żeby był czytelniejszy, utworzyłem dodatkowy plik:

/etc/sensors.d/vault13.conf

Można w nim nadać własne etykiety odczytom.

Przykładowa konfiguracja:

chip "k10temp-*"
    label temp1 "CPU Temperature"
chip "radeon-*"
    label temp1 "Radeon Temperature"
    label in0 "Radeon Voltage"
    label freq1 "Radeon Clock"

Dzięki temu wynik sensors jest znacznie czytelniejszy.

Nagłówki:

k10temp-pci-00c3
radeon-pci-0008

pozostają technicznymi nazwami urządzeń dostarczanymi przez kernel, ale same parametry są już opisane normalnie.

Diskstats – historia pracy dysków

Na koniec doinstalowałem jeszcze:

openmediavault-diskstats

Plugin dodaje do sekcji statystyk wydajności wykresy I/O dysków.

W panelu pojawia się między innymi:

Diagnostyka → Statystyki wydajności → Dysk We/Wy

Dzięki temu można obserwować aktywność HDD z danymi oraz systemowego SSD.

W moim przypadku jest to szczególnie ciekawe w połączeniu z WriteCache. Mogę sprawdzić, jak niewiele zapisów generuje systemowy SSD podczas normalnej pracy i jak zachowuje się HDD podczas kopiowania danych przez SMB.

Diskstats praktycznie nie komplikuje konfiguracji NAS-a, a daje dodatkową warstwę diagnostyki.

Dashboard OpenMediaVault

Po całej konfiguracji dashboard OMV pokazuje najważniejsze informacje bez konieczności logowania się przez SSH.

Mam tam między innymi:

• temperaturę CPU,
• temperaturę GPU,
• wykorzystanie CPU,
• temperatury HDD i SSD,
• wykorzystanie pamięci RAM,
• zajętość systemów plików,
• load average,
• informacje o interfejsie sieciowym,
• stan SMART,
• status usług,
• dostępne aktualizacje,
• uptime,
• wykres wykorzystania CPU.

Nie próbowałem zrobić z panelu centrum dowodzenia elektrownią. Ma pozwalać jednym spojrzeniem ocenić, czy z Vault13 wszystko jest w porządku.

Aktualizacja OpenMediaVault przez SSH

Po instalacji bieżące aktualizacje można wykonywać bezpośrednio z terminala.

Odświeżenie repozytoriów:

sudo apt update

Sprawdzenie dostępnych aktualizacji:

apt list --upgradable

Aktualizacja OMV i pakietów systemowych:

sudo omv-upgrade

Po większej aktualizacji, zwłaszcza jeśli zmienił się kernel, warto wykonać:

sudo reboot

Aktualną wersję OMV można sprawdzić:

dpkg -l | grep openmediavault

a wersję kernela:

uname -r

Czy FUTRO S900 nadal ma sens jako NAS?

Po kilku latach użytkowania moja odpowiedź nadal brzmi: tak, pod warunkiem że wymagania są rozsądne.

AMD G-T44R nie nadaje się do ciężkich kontenerów, transkodowania materiałów wideo czy bardziej wymagających usług. Nie taki jest jednak cel tego komputera.

Vault13 ma być przede wszystkim:

• serwerem plików,
• urządzeniem działającym przez całą dobę,
• łatwym w administracji,
• energooszczędnym,
• możliwie prostym.

W takiej roli FUTRO S900 nadal spełnia swoje zadanie.

Największą zmianą okazał się nie upgrade sprzętu, lecz odświeżenie całego środowiska programowego. Z kilkuletniego Debiana 10 i OMV 5 przeszedłem na Debian 13.7 i OMV 8.5.9, zachowując przy tym wszystkie dane na starym HDD.

Kluczowe okazało się wcześniejsze rozdzielenie systemu i danych na osobne fizyczne dyski. Dzięki temu reinstalacja systemu nie wymagała kopiowania setek gigabajtów plików. Wystarczyło zapisać UUID, UID/GID użytkownika i podstawową konfigurację SMB, odłączyć HDD na czas instalacji, a następnie zamontować go ponownie w świeżym OMV.

Po kilku godzinach pracy Vault13 wrócił na swoje miejsce z tymi samymi danymi i udziałem sieciowym, ale z aktualnym systemem, nowym monitoringiem, SMART, automatycznymi testami dysków, powiadomieniami mailowymi, WriteCache, TempMon i Diskstats.

I właśnie tak chciałem, żeby ten NAS działał – bez zbędnych usług i bez robienia z małego FUTRO kombajnu. Ma być prostym serwerem plików, który stoi w swoim miejscu, pobiera niewiele energii i po prostu robi swoją robotę.