Salutare, prieteni!

Umplerea bruscă a spațiului de pe disc pe un server Linux este una dintre cele mai frecvente cauze ale avariilor de sistem. Această problemă poate duce la oprirea bazelor de date, erori în funcționarea serverelor web și blocarea proceselor.

Administratorii se confruntă adesea cu o situație paradoxală: utilitarele standard afișează 100% spațiu ocupat, însă navigarea vizuală prin directoare nu indică fișiere de dimensiuni mari. În acest ghid, vom analiza cauzele de sistem pentru pierderea spațiului de pe disc și vom învăța cum să găsim datele „ascunse”. Folosind acest ghid, veți putea elibera spațiu pe disc și veți evita posibila oprire a serviciilor.

Key Takeaways: Concluzii cheie

Fișiere șterse, dar deschise (Deleted Open Files): Dacă ștergeți un fișier de log în care un proces (cum ar fi Nginx sau MySQL) scrie activ în acel moment, spațiul de pe disc nu se va elibera până când procesul nu este repornit sau oprit.
Epuizarea Inode-urilor (descriptorii de index): Discul se poate bloca chiar și atunci când există gigabiți liberi, dacă sistemul a epuizat limita numărului de fișiere create (de exemplu, din cauza milioanelor de sesiuni PHP mici sau fișiere de cache).
Puncte de montare ascunse: Dacă montați un disc nou sau o partiție nouă peste un director existent care conține fișiere, datele vechi vor fi „ascunse” sub noua montare și vor continua să ocupe spațiu.

Cele 5 cauze principale ale pierderii „invizibile” de spațiu pe disc

1. Descriptori deschiși ai fișierelor șterse (Unlinked Open Files)

Când ștergeți un fișier folosind comanda rm, se șterge doar înregistrarea din sistemul de fișiere. Dacă un proces (de exemplu, systemd-journald, nginx sau mysqld) ține acel fișier deschis, sistemul de operare nu eliberează blocurile de pe disc.

Cum le găsiți și remediați: Identificați fișierele „blocate” cu ajutorul utilitarului lsof:

Bash
sudo lsof +L1

Sau cu comanda alternativă:

Bash
sudo lsof | grep deleted

În rezultate veți vedea PID-ul procesului și dimensiunea fișierului reținut. Pentru a elibera spațiul fără repornirea întregului server, este suficient să reporniți serviciul respectiv:

Bash
sudo systemctl restart <service_name>

2. Epuizarea Inode-urilor (Descriptorilor de index)

Sistemul de fișiere Linux stochează metadatele fiecărui fișier într-o structură numită Inode. Numărul acestora este fixat la formatarea discului. Dacă pe server s-au generat milioane de fișiere mici (cache, fișiere de sesiune, loguri mici), Inode-urile se termină, iar sistemul afișează o eroare de scriere, în ciuda gigabiților liberi.

Cum le găsiți și remediați: Verificați statusul Inode-urilor cu comanda:

Bash
df -i

Dacă valoarea IUse% atinge 100%, identificați directorul cu cel mai mare număr de fișiere:

Bash
sudo find / -xdev -printf '%h\n' | sort | uniq -c | sort -nr | head -n 10

Curățați directoarele identificate care conțin cache sau fișiere temporare mici.

3. Journald plin și logurile serviciilor de sistem

Rotația logurilor (logrotate) poate eșua, sau jurnalul standard systemd poate umple gigabiți de disc cu rapoarte detaliate de erori (debug logs).

Cum le găsiți și remediați: Verificați volumul ocupat de jurnalele systemd:

Bash
journalctl --disk-usage

Reduceți în siguranță volumul logurilor, lăsând, de exemplu, doar ultimii 500 MB:

Bash
sudo journalctl --vacuum-size=500M

4. Containere, imagini și volume Docker uitate

Mediul Docker încarcă cel mai activ și invizibil discurile. Imaginile neutilizate (dangling images), containerele oprite și volumele anonime pot acumula zeci de gigabiți.

Cum le găsiți și remediați: Evaluați utilizarea discului de către Docker:

Bash
docker system df

Efectuați o curățare profundă și sigură a resurselor Docker neutilizate:

Bash
docker system prune -a --volumes

5. Fișiere „ascunse” sub punctul de montare

Dacă în directorul /mnt/data s-au scris 50 GB de fișiere, iar apoi în același director /mnt/data s-a montat un disc nou separat, cei 50 GB inițiali devin invizibili pentru utilitarele standard, dar continuă să ocupe spațiu pe partiția principală /.

Cum le găsiți: Verificați dimensiunea partiției inițiale montând temporar sistemul de fișiere rădăcină într-un alt punct (bind mount):

Bash
sudo mount --bind / /mnt/root_check
sudo du -sh /mnt/root_check/mnt/data
sudo umount /mnt/root_check

Checklist: Căutare rapidă a fișierelor gigantice pe server

Dacă spațiul s-a terminat chiar acum, executați acești pași pentru localizarea problemei:

Verificați volumul total al partițiilor și Inode-urile:
Bash
df -h df -i

Găsiți TOP 10 cele mai mari fișiere de pe server:

Bash
sudo find / -xdev -type f -size +100M -exec ls -lh {} \; | awk '{ print $5, $9 }' | sort -n -r | head -n 10

Utilizați scannerul interactiv ncdu: Instalați utilitarul simplu ncdu pentru analiza vizuală a directoarelor:
Bash
sudo apt install ncdu -y # Ubuntu/Debian sudo dnf install ncdu -y # AlmaLinux/Rocky sudo ncdu -x /
(Flag-ul -x indică utilitarului să rămână în cadrul aceluiași sistem de fișiere și să nu scaneze discurile de rețea montate).

FAQ: Pe scurt despre ce este mai important

De ce comenzile du și df arată un volum diferit de spațiu ocupat? Comanda df (Disk Free) interoghează nucleul și ia în calcul toate blocurile blocate (inclusiv fișierele șterse reținute de procese). Comanda du (Disk Usage) parcurge recursiv arborele de directoare și numără doar fișierele existente fizic. Diferența dintre valorile lor reprezintă volumul fișierelor „șterse, dar deschise”.
Se pot curăța logurile cu comanda rm? Nu se recomandă ștergerea simplă a fișierelor .log active prin rm, deoarece serviciul va continua să scrie în descriptorul șters. Este corect să goliți conținutul fișierului fără a-l șterge:
Bash
sudo truncate -s 0 /var/log/nginx/access.log
Ce să fac dacă spațiul se umple constant în doar câteva ore? Configurați monitorizarea proceselor cu ajutorul fatrace sau al utilitarului integrat auditd pentru a urmări ce proces efectuează un volum anormal de scriere pe disc (Disk I/O) în timp real.

Concluzie

Umplerea discului este întotdeauna o consecință a controlului insuficient asupra proceselor automate: rotația logurilor, curățarea datelor temporare și extinderea bazelor de date. Configurarea corectă a logrotate, curățarea periodică Docker (prune) și identificarea rapidă a descriptorilor deschiși permit prevenirea a 99% din opririle neprevăzute.

Totuși, pentru serviciile critice și proiectele în creștere, rezerva subsistemului de discuri și posibilitatea de scalare rapidă a stocării fără timpi de indisponibilitate joacă un rol vital.

Dacă proiectul dvs. necesită o infrastructură flexibilă cu resurse garantate, descoperiți serviciile NVMe VPS de la MivoCloud. Oferim extinderea rapidă a spațiului de stocare în doar câteva clicuri, virtualizare pură KVM și stocare Enterprise NVMe ultra-rapidă, rezistentă la sarcini I/O ridicate.

Autorul articolului: Anatolie Cohaniuc

De ce discul de pe server se revarsă și cum se găsesc fișierele "ascunse"?