Extindere disc, partitie si filesystem dupa upgrade de VPS

Ai dat click pe upgrade, planul nou e activ si panoul spune 80 GB. Te loghezi, rulezi df -h si filesystem-ul root arata tot 40 GB. Nu s-a stricat nimic si nu s-au pierdut date. Hypervisorul a marit discul virtual, dar tabela de partitii, partitia si filesystem-ul de deasupra descriu in continuare dimensiunea veche. Linux nu le intinde singur, pentru ca a rescrie partitii fara sa fie rugat e exact genul de lucru pe care un sistem de operare nu ar trebui sa-l faca niciodata.

In ghidul asta ducem spatiul nou pe tot lantul: de la disc la partitie, prin LVM daca il folosesti, si in final in filesystem. Uneltele sunt growpart, pvresize, lvextend, resize2fs si xfs_growfs. Totul se face online, pe sistemul pornit, fara reinstalare, si de obicei dureaza sub cinci minute. Am inclus si verificarile pe care le facem noi inainte si dupa, ca in fiecare moment sa stii la ce strat lucrezi si nimic sa nu fie lasat la noroc.

De ce spatiul nou nu apare singur

Ca sa intelegi de ce df arata inca dimensiunea veche, ajuta sa vezi cum e organizata stocarea pe un server Linux. Fiecare strat are propria idee despre “cat de mare sunt”, salvata in metadatele lui, iar upgrade-ul schimba doar stratul de jos.

• Discul virtual (numit si block device) e ce primeste VPS-ul de la hypervisor. Pe un VPS KVM apare de obicei ca /dev/vda (disc virtio), uneori ca /dev/sda (virtio SCSI) sau /dev/nvme0n1. Acesta e stratul care creste la upgrade.
• Tabela de partitii e o harta mica la inceputul discului (si, la GPT, si la final). Ea spune unde incepe si unde se termina fiecare partitie. Exista doua formate: modernul GPT si mai vechiul MBR (afisat si ca “dos”).
• O partitie e o felie din disc descrisa in tabela, de exemplu /dev/vda1. Sfarsitul ei e scris in tabela, deci ramane unde era, chiar daca discul din spate s-a dublat.
• LVM (Logical Volume Manager) e un strat optional. O partitie devine physical volume (PV), unul sau mai multe PV-uri formeaza un volume group (VG), iar din VG decupezi logical volumes (LV) care contin filesystem-uri. Installerul de Ubuntu Server foloseste LVM implicit, multe imagini cloud nu.
• Filesystem-ul (sistemul de fisiere: ext4, XFS, Btrfs) e structura care organizeaza fisierele si directoarele. Isi noteaza propria dimensiune in superblock, iar df raporteaza exact acel numar.

Asadar dupa upgrade ai un disc mare, o partitie mica si un filesystem mic. Treaba noastra e sa crestem fiecare strat in ordine, de jos in sus, cu singura unealta care stie sa-l creasca.

Vestea buna: marirea e directia sigura. ext4, XFS si Btrfs pot fi marite cat timp sunt montate, iar niciuna dintre unelte nu muta datele existente. Ele rescriu doar metadate (sfarsitul unei partitii in tabela, dimensiunea unui PV sau LV, numarul de blocuri al unui filesystem). Micsorarea e cu totul alta poveste si nu o facem aici.

De ce ai nevoie

• Un VPS KVM al carui disc virtual a fost deja marit prin upgrade (daca esti pe un container LXC, citeste intai sectiunea urmatoare).
• Debian 13 sau Ubuntu 24.04, acces SSH si un utilizator cu drepturi sudo.
• Un snapshot sau backup proaspat al serverului. Marirea are risc mic, dar mic nu inseamna zero.
• Cam zece minute, ideal in afara orelor de trafic maxim.
• Pachetul cloud-guest-utils, care contine growpart (il instalam la Pasul 3).

Debian, Ubuntu si LXC: ce difera

Procedura e aceeasi pe ambele distributii, dar punctul de plecare de multe ori nu e. Iata la ce sa fii atent:

• Numele pachetelor sunt identice. growpart vine din cloud-guest-utils atat pe Debian, cat si pe Ubuntu. lvm2 e deja instalat daca sistemul foloseste LVM, iar xfsprogs e instalat daca filesystem-ul root e XFS.
• Imaginile cloud pot face treaba in locul tau. Imaginile cloud de Debian si Ubuntu vin cu cloud-init, ale carui module growpart si resizefs maresc partitia si filesystem-ul root la boot. Daca VPS-ul a fost repornit in timpul upgrade-ului, ruleaza intai df -h /: s-ar putea ca spatiul sa fie deja acolo.
• Layout-urile implicite difera. O imagine cloud de Debian are de obicei ext4 pe /dev/vda1, care e fizic ultima partitie, cazul simplu. Un Debian instalat din ISO cu optiunea “guided, use entire disk” pune root pe vda1 si apoi o partitie de swap (vda5 intr-o partitie extinsa vda2) dupa ea, ceea ce blocheaza marirea, vezi sectiunea de depanare. Debian cu LVM din ISO pune PV-ul pe vda5, in interiorul partitiei extinse vda2. Ubuntu 24.04 instalat din ISO-ul de server foloseste GPT, un PV pe partitia 3 si un logical volume numit ubuntu-vg/ubuntu-lv, iar installerul lasa des o buna parte din volume group nealocata.
• Numele dispozitivelor difera. Poti vedea vda, sda sau nvme0n1. Foloseste mereu numele afisate de propriul tau lsblk, nu copia orbeste nume de dispozitive dintr-un ghid (inclusiv din acesta).
• Containerele LXC sunt alta lume. Un container nu are block device propriu: filesystem-ul lui root e un volum gestionat de host. In interiorul unui container LXC, mai ales unul neprivilegiat (unprivileged), growpart si resize2fs nu pot functiona si nici nu sunt necesare. Hostul mareste volumul, iar df -h / arata noua dimensiune imediat sau dupa un restart al containerului. Daca nu, contacteaza suportul. Verifici pe ce rulezi cu systemd-detect-virt: afiseaza kvm pe un VPS KVM si lxc intr-un container.

Procedura pe scurt

Acestia sunt cei sapte pasi pe care ii urmam. Primii trei doar citesc informatii si nu schimba nimic. Pasii 4-6 scriu metadate, cate un strat fiecare, iar Pasul 7 verifica rezultatul.

Extindere partitie Linux: growpart, LVM si resize2fs pas cu pas

Pasul 1: Backup si inregistrarea layout-ului curent

Marirea unei partitii e una dintre cele mai sigure operatii pe disc, dar “sigur” nu e o strategie de backup. Daca planul tau include snapshot-uri sau backup-uri, fa unul acum. Daca nu, copiaza intai de pe server tot ce nu iti permiti sa pierzi.

Apoi fa o “poza” a layout-ului curent, ca sa ai cu ce compara mai tarziu:

lsblk -i -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -hT /
findmnt -n -o SOURCE,FSTYPE /

lsblk listeaza discurile si partitiile sub forma de arbore (-i foloseste caractere ASCII simple pentru liniile arborelui), df -hT / arata dimensiunea si tipul filesystem-ului root, iar findmnt iti spune exact ce dispozitiv e montat pe /. Pe o imagine cloud tipica de Debian, dupa un upgrade de la 40 la 80 GB, vei vedea ceva de genul:

NAME     SIZE TYPE FSTYPE MOUNTPOINTS
vda       80G disk
|-vda1  39.9G part ext4   /
|-vda14    3M part
`-vda15  124M part vfat   /boot/efi

/dev/vda1 ext4

Discul are deja 80G, dar vda1 si filesystem-ul au tot vreo 40G. Exact situatia pe care o rezolva ghidul asta. Pe o instalare cu LVM, findmnt afiseaza in schimb ceva ca /dev/mapper/ubuntu--vg-ubuntu--lv ext4, semn ca Pasul 5 se aplica si la tine.

Salveaza imaginea completa intr-un fisier din directorul tau home:

{ date; lsblk -i -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS; df -hT; cat /etc/fstab; sudo blkid; } > ~/disk-before.txt

In final, verifica ce partitie e fizic ultima pe disc, pentru ca growpart poate mari o partitie doar in spatiul liber aflat imediat dupa ea. Numerele partitiilor nu urmeaza ordinea fizica (pe imaginea Debian de mai sus, vda1 sta dupa vda14 si vda15):

sudo parted /dev/vda unit GiB print free

Pe un disc GPT tocmai marit, parted poate avertiza ca nu tot spatiul e folosit si intreaba Fix/Ignore?. Raspunsul Fix e sigur: doar muta header-ul GPT de backup la adevaratul final al discului, lucru pe care oricum l-ar face si growpart. Cauta o linie Free Space imediat sub partitia root (sau LVM):

Number  Start    End      Size     File system  Name  Flags
14      0.00GiB  0.00GiB  0.00GiB                     bios_grub
15      0.00GiB  0.12GiB  0.12GiB  fat16              boot, esp
 1      0.12GiB  40.0GiB  39.9GiB  ext4
        40.0GiB  80.0GiB  40.0GiB  Free Space

Daca intre partitia ta si spatiul liber sta altceva (de obicei swap), opreste-te si citeste “O partitie de swap sta dupa partitia root” in sectiunea de depanare.

Pasul 2: Verifica daca kernelul vede discul marit

Kernelul trebuie sa cunoasca noua dimensiune a discului inainte ca orice altceva sa o poata folosi. Daca VPS-ul a fost oprit si pornit in timpul upgrade-ului, deja o cunoaste. Daca discul a fost marit cu serverul pornit, verifica:

lsblk -d -o NAME,SIZE
sudo dmesg | grep -i capacity

lsblk -d arata doar discurile intregi. La discurile virtio (vda), kernelul observa de obicei schimbarea pe loc, iar dmesg contine o linie ca vda: detected capacity change from 83886080 to 167772160. La discurile SCSI (sda) poti cere kernelului sa rescaneze dispozitivul:

echo 1 | sudo tee /sys/class/block/sda/device/rescan

Daca discul arata in continuare dimensiunea veche, reporneste VPS-ul. Un reboot ii da si lui cloud-init sansa sa mareasca totul singur, asa ca verifica din nou df -h / dupa aceea.

Pasul 3: Instaleaza growpart si fa un test (dry run)

growpart e un script mic care muta sfarsitul unei partitii la finalul spatiului liber disponibil. Merge atat cu tabele GPT, cat si MBR, si e sigur de rulat pe o partitie montata. Instaleaza-l:

sudo apt update
sudo apt install -y cloud-guest-utils

Acum intreaba-l ce ar face, fara sa atinga nimic. Atentie la spatiul dintre disc si numarul partitiei: e /dev/vda 1, nu /dev/vda1.

sudo growpart --dry-run /dev/vda 1

O linie care incepe cu CHANGE: inseamna ca partitia poate fi marita si arata dimensiunile veche si noua, in sectoare:

CHANGE: partition=1 start=262144 old: size=83623903 end=83886046 new: size=167509983 end=167772126

O linie care incepe cu NOCHANGE: inseamna ca nu exista spatiu in care sa creasca. Fie kernelul nu vede inca noua dimensiune a discului (intoarce-te la Pasul 2), fie alta partitie e in cale (vezi depanarea). Pentru discuri NVMe sintaxa e sudo growpart --dry-run /dev/nvme0n1 1. Pe o instalare cu LVM, ruleaza-l pe partitia care contine PV-ul, de exemplu sudo growpart --dry-run /dev/sda 3.

Pasul 4: Mareste partitia cu growpart

Cand testul arata corect, ruleaza comanda pe bune:

sudo growpart /dev/vda 1

Output-ul repeta linia CHANGE:. growpart rescrie tabela de partitii si anunta kernelul despre noul sfarsit al partitiei, deci nu ai nevoie de reboot. Verifica:

lsblk -i -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS

vda1 ar trebui sa aiba acum in jur de 79.9G. df arata in continuare dimensiunea veche, si e normal: filesystem-ul inca nu a aflat.

Pe o instalare cu LVM, mareste in schimb partitia PV-ului, de exemplu sudo growpart /dev/sda 3. Pe un Debian instalat din ISO cu LVM, unde PV-ul e partitia logica vda5 din partitia extinsa vda2, mareste intai containerul si apoi partitia din interior:

sudo growpart /dev/vda 2
sudo growpart /dev/vda 5

Pasul 5: Extinde LVM (doar daca il folosesti)

Daca findmnt de la Pasul 1 a aratat o partitie simpla, ca /dev/vda1, treci direct la Pasul 6. Daca a aratat un dispozitiv /dev/mapper/..., mai ai doua straturi de marit. Intai, uita-te la ele:

sudo pvs
sudo vgs
sudo lvs -o lv_name,vg_name,lv_size,lv_path

Uita-te la coloana VFree din vgs inainte de orice altceva. Pe instalarile Ubuntu e frecvent sa gasesti spatiu liber deja existent in volume group, lasat nealocat de installer. In acest caz poti sari peste pvresize si mergi direct la lvextend.

Anunta LVM ca physical volume-ul e acum mai mare (foloseste partitia PV afisata de pvs):

sudo pvresize /dev/sda3

Output asteptat: Physical volume "/dev/sda3" changed si 1 physical volume(s) resized or updated. Ruleaza din nou sudo vgs si VFree arata acum spatiul nou. Apoi da-l logical volume-ului care contine filesystem-ul root (foloseste calea din coloana lv_path):

sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

-l +100%FREE adauga tot spatiul liber din volume group. Daca preferi sa pastrezi o rezerva pentru mai tarziu sau pentru snapshot-uri LVM, foloseste o valoare fixa ca -L +30G. Optiunea -r (forma lunga --resizefs) face ca lvextend sa mareasca filesystem-ul imediat dupa LV, atat pentru ext4, cat si pentru XFS, deci pe LVM Pasul 6 se face automat. Pe Debian, numele implicite arata ca /dev/<hostname>-vg/root, motiv pentru care citim mereu calea din lvs in loc sa o ghicim.

Pasul 6: Mareste filesystem-ul cu resize2fs sau xfs_growfs

Acesta e pasul care il face pe df fericit. Foloseste unealta potrivita pentru FSTYPE-ul notat la Pasul 1. Toate trei functioneaza online, pe filesystem-ul montat.

Pentru ext4 (implicit pe Debian si Ubuntu), da-i lui resize2fs dispozitivul, fie partitia, fie calea LV-ului:

sudo resize2fs /dev/vda1

Output asteptat:

Filesystem at /dev/vda1 is mounted on /; on-line resizing required
old_desc_blocks = 5, new_desc_blocks = 10
The filesystem on /dev/vda1 is now 20938747 (4k) blocks long.

Pentru XFS, da-i lui xfs_growfs punctul de montare, nu dispozitivul:

sudo xfs_growfs /

Afiseaza geometria filesystem-ului si se termina cu o linie ca data blocks changed from 10468352 to 20938496.

Pentru Btrfs, echivalentul e sudo btrfs filesystem resize max /.

Daca ai folosit lvextend -r la Pasul 5, asta s-a facut deja, iar o noua rulare doar raporteaza ca nu mai e nimic de facut.

Pasul 7: Verifica rezultatul

Compara rezultatul cu ce ai notat la Pasul 1:

df -hT /
lsblk -i -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
sudo dmesg | tail -n 20

df ar trebui sa arate acum aproape toata dimensiunea discului (putin mai putin decat partitia, pentru ca filesystem-ul pastreaza spatiu pentru propriile metadate). In dmesg nu trebuie sa apara erori de I/O sau de filesystem. Ca sa ai o evidenta, salveaza si imaginea “dupa” si compara:

{ date; lsblk -i -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS; df -hT; cat /etc/fstab; sudo blkid; } > ~/disk-after.txt
diff ~/disk-before.txt ~/disk-after.txt

Dimensiunile se schimba, dar UUID-urile din blkid si continutul din /etc/fstab raman identice, pentru ca marirea nu schimba niciodata identitatea unui filesystem. De aceea serverul porneste normal si dupa.

Un reboot nu e obligatoriu. Daca vrei liniste completa, programeaza unul intr-un moment linistit ca sa confirmi ca serverul revine curat. Iar daca ai rulat si apt upgrade intre timp, reporneste daca s-a instalat un kernel nou: Ubuntu creeaza in acest caz /var/run/reboot-required, Debian nu il creeaza intotdeauna, asa ca pe Debian reporneste pur si simplu daca s-a instalat un pachet linux-image nou.

Depanare si greseli frecvente

growpart raspunde NOCHANGE

NOCHANGE: partition 1 is size ... it cannot be grown inseamna ca nu exista spatiu liber imediat dupa partitia respectiva. Verifica doua lucruri: ca lsblk -d arata noua dimensiune a discului (Pasul 2) si ca partitia aleasa e chiar ultima inainte de spatiul liber (parted ... print free de la Pasul 1). O greseala des intalnita e sa maresti partitia 1 cand partitia root sau PV e de fapt numarul 3.

O partitie de swap sta dupa partitia root

Acesta e layout-ul clasic al unui Debian instalat din ISO: root pe vda1, apoi o partitie extinsa vda2 care contine swap pe vda5. growpart nu poate sari peste swap. Solutia curata e sa stergi partitia de swap si sa folosesti un fisier de swap. Fa intai un snapshot si confirma numerele partitiilor cu lsblk, pentru ca aceste comenzi sterg partitii:

sudo swapoff -a
sudo sed -i.bak '/\sswap\s/ s/^/#/' /etc/fstab
sudo parted /dev/vda rm 5
sudo parted /dev/vda rm 2
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1

sed comenteaza linia de swap din /etc/fstab si pastreaza o copie in /etc/fstab.bak. Apoi recreeaza swap-ul ca fisier:

sudo fallocate -l 2G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfile
echo '/swapfile none swap sw 0 0' | sudo tee -a /etc/fstab

Daca exista /etc/initramfs-tools/conf.d/resume, el inca indica partitia stearsa si la urmatorul boot sistemul va astepta dupa ea. Rezolvi cu echo 'RESUME=none' | sudo tee /etc/initramfs-tools/conf.d/resume urmat de sudo update-initramfs -u.

resize2fs: Bad magic number in super-block

Ai rulat resize2fs pe ceva ce nu e un filesystem ext4: discul intreg (/dev/vda), un physical volume LVM (/dev/sda3) in loc de logical volume, sau un filesystem XFS. Verifica cu findmnt -n -o SOURCE,FSTYPE / si foloseste exact acel dispozitiv si unealta potrivita.

xfs_growfs spune ca nu e un filesystem XFS montat

xfs_growfs asteapta punctul de montare (/, /var, /data), nu calea dispozitivului. Ruleaza sudo xfs_growfs /.

df arata tot dimensiunea veche

Ai marit partitia (sau LV-ul), dar nu si filesystem-ul. Fa Pasul 6. Invers, daca resize2fs raporteaza ca filesystem-ul are “deja” dimensiunea maxima, dar df e mic, partitia nu a fost marita niciodata: intoarce-te la Pasul 4.

growpart esueaza cu o eroare de sfdisk sau de locale

Unele versiuni de growpart interpreteaza gresit output-ul lui sfdisk cand limba sistemului nu e engleza. Ruleaza-l cu locale-ul C: sudo LC_ALL=C growpart /dev/vda 1. Daca raporteaza ca tabela a fost modificata, dar kernelul nu a putut fi anuntat, ruleaza sudo partx -u /dev/vda sau reporneste, apoi continua cu Pasul 6.

Discul are peste 2 TiB si foloseste MBR

O tabela MBR (“dos”) nu poate adresa spatiu dincolo de 2 TiB, asa ca growpart se opreste acolo. Conversia la GPT e posibila, dar delicata pe un disc de boot. Fa un backup complet si ia in calcul sa ceri ajutor.

Configuratii criptate (LUKS)

Daca PV-ul tau sta intr-un container LUKS, exista un strat in plus intre Pasii 4 si 5: dupa growpart, ruleaza sudo cryptsetup resize <nume-mapare> (numele din lsblk), apoi continua cu pvresize.

Note de securitate si siguranta

• Intai snapshot, mereu. Fiecare comanda de aici e gandita sa fie sigura, dar o greseala de tastare in numele dispozitivului nu e. Un snapshot transforma un dezastru intr-un rollback de zece minute.
• Citeste de doua ori numele dispozitivelor. vda si vdb, partitia 1 si 3, sunt la o tasta distanta. Copiaza numele din propriul output lsblk, nu din memorie.
• Nu micsora niciodata cu aceste unelte. XFS nu poate fi micsorat deloc, iar micsorarea ext4 cere un filesystem demontat si o ordine precisa. Daca ai nevoie de mai putin spatiu, migreaza pe un disc nou.
• Tine backup-urile in afara serverului. ~/disk-before.txt e o evidenta, nu un backup. Backup-urile reale stau pe alta masina sau alt storage.
• Atentie la permisiunile fisierului de swap. Un fisier de swap trebuie sa aiba chmod 600, altfel alti utilizatori ar putea citi pagini de memorie scrise in el.
• Lasa rezerva in LVM. Cativa GB liberi in volume group iti permit pe viitor sa faci snapshot-uri LVM inainte de modificari riscante.

Deci, gata sa folosesti tot spatiul nou?

Dupa un upgrade, extinderea unei partitii in Linux se reduce la un lant previzibil: confirmi discul, maresti partitia cu growpart, rulezi pvresize si lvextend daca folosesti LVM, apoi resize2fs sau xfs_growfs. Notezi layout-ul inainte, il compari dupa si nu te vei mai intreba niciodata ce strat ai uitat. Totul merge online, fara reinstalare si de obicei fara reboot.

Daca ai nevoie de mai mult spatiu pentru proiectele tale, poti mari un VPS de la noi in cateva click-uri si urma apoi ghidul asta. Iar daca preferi sa nu umbli singur la partitii pe un server de productie, echipa noastra de administrare servere se poate ocupa de redimensionare, de layout-ul de swap si de reglajele LVM in locul tau.

Intrebari frecvente

Trebuie sa repornesc serverul dupa marirea partitiei?

Nu. growpart anunta kernelul despre noul sfarsit al partitiei, iar ext4, XFS si Btrfs pot fi marite cat timp sunt montate. Un reboot ajuta doar daca kernelul nu a observat noua dimensiune a discului (Pasul 2) sau nu a putut reciti tabela de partitii.

Pot folosi aceleasi comenzi ca sa micsorez un disc?

Nu. Aceste unelte doar maresc. XFS nu poate fi micsorat deloc, iar micsorarea ext4 trebuie facuta offline, in ordine inversa, cu un backup pregatit. In practica, mutarea datelor pe un disc nou, mai mic, e mai sigura.

Ce fac daca spatiul in plus vine ca un al doilea disc?

Daca upgrade-ul a adaugat un disc nou (de exemplu /dev/vdb) in loc sa-l mareasca pe cel existent, nu ai nimic de extins. Creezi un filesystem pe el, il montezi si il adaugi in /etc/fstab, sau il adaugi in volume group ca PV nou cu pvcreate si vgextend. Daca a fost marit un disc de date existent fara tabela de partitii, sari peste growpart si ruleaza direct resize2fs /dev/vdb (sau xfs_growfs pe punctul lui de montare).

E sigur sa fac asta pe un server de productie?

Marirea e una dintre operatiile pe disc cu cel mai mic risc, se face online si nu muta date. Totusi, fa un snapshot, lucreaza in afara orelor de varf si ruleaza intai testul de la Pasul 3. Cea mai mare parte din risc vine din tastarea gresita a numelui de dispozitiv, nu din unelte.