Powiększyłem dysk VPS, ale OS nadal widzi za mało miejsca

Zamawiasz więcej miejsca na dysku, panel potwierdza zmianę, ale df -h w systemie dalej pokazuje stary rozmiar. Panel powiększa dysk wirtualny, ale system operacyjny widzi tylko tyle, ile wynosi partycja. Dla systemów zainstalowanych z naszego obrazu z działającym qemu-guest-agent partycja rozszerza się automatycznie po restarcie. W pozostałych przypadkach trzeba to zrobić ręcznie, a poniżej wyjaśniamy jak.

Dlaczego tak się dzieje

VPS ma dysk wirtualny (np. 80 GB po upgrade), ale partycja na tym dysku (np. 40 GB) i system plików na niej nie zajmują całego dostępnego miejsca, dopóki ich nie rozszerzysz. To dwa osobne kroki: panel robi ten pierwszy, a Ty drugi.

Kiedy rozszerzenie następuje automatycznie

Jeśli system operacyjny na VPS był instalowany z naszego gotowego obrazu i ma działający qemu-guest-agent, rozszerzenie partycji i systemu plików odbywa się automatycznie po restarcie serwera. Nie musisz wtedy uruchamiać żadnych dodatkowych poleceń, bo po ponownym uruchomieniu df -h pokaże od razu nową, pełną pojemność.

Możesz sprawdzić, czy agent jest aktywny:

systemctl status qemu-guest-agent

Jeśli usługa działa (active (running)), restart wystarczy. Jeśli agent nie jest zainstalowany (np. zainstalowałeś system z własnego ISO lub go odinstalowałeś), rozszerzenie trzeba przeprowadzić ręcznie poleceniami opisanymi niżej.

Jak sprawdzić sytuację

Zaloguj się przez SSH i uruchom:

df -h

Zobaczysz aktualne użycie systemu plików. Potem sprawdź, jak wygląda tabela partycji:

lsblk

Jeśli rozmiar dysku (vda) jest większy niż partycja (vda1), to właśnie tyle niezagospodarowanego miejsca zostało do wzięcia.

Żeby sprawdzić typ systemu plików:

df -T

Rozszerzenie partycji i systemu plików

Na VPS dysk systemowy to zwykle /dev/vda, a główna partycja /dev/vda1. Przed rozszerzeniem upewnij się, że masz zainstalowane narzędzie growpart:

# Debian/Ubuntu
apt install cloud-guest-utils

# CentOS / AlmaLinux / Rocky
dnf install cloud-utils-growpart

Dla systemu plików ext4 (Debian, Ubuntu i pochodne)

growpart /dev/vda 1
resize2fs /dev/vda1

Dla systemu plików XFS (CentOS, AlmaLinux, Rocky i pochodne)

growpart /dev/vda 1
xfs_growfs /

Po chwili df -h powinno pokazać pełną, nową pojemność. Restart serwera nie jest potrzebny.

Limit plików (inode)

Każdy system plików ma limit liczby plików, jaką może przechowywać (tzw. inode). Powiększenie dysku proporcjonalnie zwiększa ten limit, ale nie bezgranicznie.

Objawia się to zaskakująco: serwer zwraca błąd No space left on device, aplikacje przestają działać, ale df -h pokazuje wiele gigabajtów wolnego miejsca. Przyczyna jest inna: zabrakło nie miejsca, lecz slotów na pliki.

Jak sprawdzić

df -i

Zwróć uwagę na kolumnę IUse%. Jeśli wynosi 100%, dysk jest pełny pod względem liczby plików, nie bajtów:

Filesystem      Inodes   IUsed   IFree IUse% Mounted on
/dev/vda5      2616320 2616320       0  100% /

Co to powoduje i gdzie szukać

Winowajcą są zazwyczaj bardzo małe pliki, których z czasem nagromadziły się miliony. Typowi sprawcy:

• Sesje PHP przechowywane jako pliki (katalog /tmp lub /var/lib/php/sessions)
• Logi aplikacji lub logi systemd (katalog /var/log)
• Cache aplikacji (np. Magento, Symfony, WordPressa z dużą ilością transient options)
• Katalogi poczty z wielką liczbą drobnych wiadomości (np. MailDir)
• GitLab, npm, Composer, pip: narzędzia deweloperskie mogą tworzyć tysiące małych plików w cache i modułach

Żeby znaleźć, który katalog ma ich najwięcej:

# Pokaż top 10 katalogów z największą liczbą plików
find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

lub szybciej, katalog po katalogu:

for i in /*; do echo $(find "$i" -xdev 2>/dev/null | wc -l) "$i"; done | sort -rn | head -10

Co zrobić

1. Wyczyść cache i sesje aplikacji (np. php -r "session_start(); session_destroy();" lub skasuj zawartość katalogu sesji).
2. Wyczyść stare logi: journalctl --vacuum-size=200M dla logów systemd.
3. Jeśli problem jest strukturalny (aplikacja produkuje miliony plików), rozważ zmianę jej konfiguracji (np. przejście z sesji plikowych PHP na Redis/Memcached).

Powiększenie dysku proporcjonalnie zwiększa limit inode, ale jeśli przyczyną jest specyfika aplikacji, nowe miejsce tylko odsuwa problem w czasie. Najlepszym rozwiązaniem jest eliminacja nadmiaru małych plików.

Błąd „GPT PMBR size mismatch" po rozszerzeniu dysku

Jeśli Twój serwer używa tablicy partycji GPT (sprawdzisz poleceniem fdisk -l /dev/vda), po rozszerzeniu dysku w panelu możesz napotkać taki błąd:

GPT PMBR size mismatch (X != Y) will be corrected by write

Oznacza to, że nagłówek GPT nie zgadza się z nowym rozmiarem dysku. Naprawisz to narzędziem gdisk:

gdisk /dev/vda

Po uruchomieniu gdisk wpisz w (write) i potwierdź. Narzędzie samo naprawi rozbieżność i zapisze poprawny nagłówek. Potem możesz normalnie rozszerzyć partycję poleceniem growpart i system plików poleceniem resize2fs lub xfs_growfs, jak opisano wyżej.

Kiedy się zgłosić

Jeśli po poleceniach powyżej coś nie wychodzi, napisz do nas przez panel klienta. W zgłoszeniu podaj wyniki df -h, lsblk i df -T, bo pozwoli nam to szybko ocenić sytuację.

Więcej o upgrade dysku i pozostałych zasobów VPS znajdziesz w artykule o zmianie zasobów VPS.