Spațiul epuizat pe disc este cea mai frecventă cauză pentru care un server încetează să funcționeze fără nicio rea-voință. Site-ul returnează 500, baza de date nu scrie, poșta nu pleacă — iar df -h arată între timp câțiva gigaocteți liberi. Să parcurgem trei cazuri în care se întâmplă asta și, în trecere, ce merită știut despre SMART.

Primul caz: s-au terminat inode-urile

Un sistem de fișiere ține două resurse limitate: spațiu pentru conținut și înregistrări despre fișiere. A doua se epuizează independent de prima:

df -h
df -i

Dacă la a doua comandă IUse% este 100, e vorba de inode-uri. Spațiu există, dar nu se poate crea niciun fișier, nici măcar unul gol.

Vinovații sunt mereu aceiași: milioane de fișiere minuscule. Sesiuni PHP în /var/lib/php/sessions, cărora li s-a stricat curățarea. Cache-ul aplicației fără curățare. O coadă de poștă blocată. Un director cu miniaturi. Se găsesc astfel:

sudo find / -xdev -type f -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -20

Comanda afișează directoarele cu cele mai multe fișiere. Pe un sistem mare rulează câteva minute — este normal.

Al doilea caz: fișierul șters, dar spațiul nu s-a întors

O situație mai perfidă. Cineva a șters cu rm un jurnal umflat, dar procesul care scria în el îl ține în continuare deschis. Fișierul nu mai este în director, spațiul rămâne ocupat, și așa va fi până la repornirea procesului.

sudo lsof +L1

Comanda arată fișierele fără referințe în sistemul de fișiere, ținute totuși de un proces. Se rezolvă prin repornirea sau reîncărcarea lină a acelui proces, nu prin căutarea „unde au dispărut gigaocteții”.

De aici regula: un jurnal umflat nu se șterge, ci se golește — atunci descriptorul deschis rămâne funcțional:

sudo truncate -s 0 /var/log/huge.log

Și imediat după aceea se configurează rotația, altfel peste o săptămână totul se repetă.

Al treilea caz: au mâncat jurnalele

Unde anume s-a dus spațiul se vede coborând nivel cu nivel:

sudo du -x -h --max-depth=1 / | sort -h
sudo du -x -h --max-depth=1 /var | sort -h

Opțiunea -x nu permite coborârea în alte sisteme de fișiere; fără ea, numărătoarea se afundă în /proc și în resursele de rețea montate. Este mai comod să faci toate acestea în ncdu, dacă este disponibil.

Mâncătorii obișnuiți:

  • journald. Decide o singură comandă: journalctl --disk-usage. Se limitează cu linia SystemMaxUse=500M în /etc/systemd/journald.conf, curățare unică cu journalctl --vacuum-size=200M;
  • jurnalele instrumentelor de securitate. Suricata, cu configurația implicită, scrie treizeci de tipuri de evenimente și nu configurează rotația după sine — pe un server real au ieșit 15 GB în două zile. La fel se întâmplă cu audit.log și cu jurnalele de depanare ale nginx;
  • copiile de rezervă puse pe același disc și niciodată șterse;
  • cache-ul apt — apt clean întoarce uneori câțiva gigaocteți.

Separat despre /boot

O partiție mică, umplută de nucleele vechi. În sine nu doboară site-ul, în schimb oprește complet actualizările: noul nucleu nu se instalează, iar în spatele lui stă întreaga coadă de pachete. Se rezolvă cu apt autoremove --purge și se previne activând ștergerea automată a nucleelor nefolosite în setările actualizărilor automate.

SMART: ce atribute contează

O precizare din start: pe un server virtual, SMART este de obicei inaccesibil — discul este virtual, iar cel fizic nu se vede sub el. Nu este o defecțiune, pur și simplu nu există date. Tot ce urmează se referă la servere dedicate și la hardware propriu.

sudo smartctl -a /dev/sda

Linia SMART overall-health self-assessment test result: PASSED nu este motiv de liniște: rămâne verde practic până la defecțiune. Trebuie privite contoarele concrete:

  • 5, Reallocated_Sector_Ct — sectoare realocate. O valoare diferită de zero înseamnă că discul deja se degradează; dacă crește în timp — schimbă fără amânare;
  • 197, Current_Pending_Sector — sectoare ilizibile în așteptarea unei decizii. Cel mai îngrijorător dintre toate: de obicei înseamnă că o parte din date deja nu mai poate fi salvată;
  • 198, Offline_Uncorrectable — același lucru, confirmat printr-o verificare;
  • SSD: Percentage Used / Media_Wearout_Indicator — resursa de scriere consumată. O mărime previzibilă, după care se planifică înlocuirea.

În schimb, temperatura și orele de funcționare nu spun nimic prin ele însele: un disc cu cinci ani de funcționare și contoare de erori la zero este mai sigur decât unul nou cu un 1 în atributul 197.

Rostul supravegherii

Tot ce s-a spus mai sus este o reacție la ceea ce s-a întâmplat deja. Între timp, și umplerea discului, și uzura SSD-ului sunt procese lente și perfect previzibile: un grafic al ocupării pe două săptămâni arată data la care se va termina spațiul cu mult înainte de a se întâmpla. Diferența dintre „site-ul e picat de la trei noaptea” și „joi trebuie curățate jurnalele” stă doar în a avea o cifră în fața ochilor. Cum arată asta în ansamblu arată pagina demonstrativă de mai jos.