E sigur să rulez 'docker system prune -a'?

Șterge containerele oprite, rețelele nefolosite, cache-ul de build orfan și toate imaginile nefolosite de un container care rulează. Datele tale rămân, dacă nu adaugi --volumes. Cu --volumes șterge și volumele nefolosite — iar volumul unui container de bază de date oprit contează ca nefolosit. Nu folosi flagul ăsta dacă nu ești sigur.

Am șters un fișier de log mare, dar df tot arată discul plin. De ce?

Un proces care rulează are încă fișierul deschis, așa că kernelul păstrează spațiul. Găsește-l cu 'lsof +L1' și repornește serviciul respectiv. Data viitoare golește un log activ cu 'truncate -s 0 fișier' în loc să-l ștergi.

Cât spațiu liber să păstrez?

Păstrează cel puțin 10–15% liber. Bazele de date, actualizările de pachete și descărcările Docker au nevoie de spațiu temporar, iar un disc la 100% poate corupe o bază de date în mijlocul unei scrieri.

Pot adăuga mai mult disc fără reinstalare?

Da. Trecerea la un plan mai mare mărește discul pe loc și îți păstrează datele — Nano are 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Upgrade-ul repornește serverul o dată.

Ce umple de obicei un VPS mic?

Din experiența noastră: imaginile Docker și cache-ul de build, jurnalele systemd, logurile aplicațiilor pe care nu le rotește nimeni și dumpurile de baze de date sau arhivele de backup uitate în /root.

Cum eliberezi spațiu pe disc pe un VPS fără să strici nimic

S-a umplut discul VPS-ului? Află ce mănâncă spațiul cu du și ncdu, apoi curăță cache-urile apt, jurnalele, resturile Docker și logurile fără să pierzi date.

„No space left on device” nu apare niciodată la un moment convenabil. Baza de date nu mai acceptă scrieri, apt nu poate termina o actualizare, iar Docker refuză să descarce imaginea de care ai nevoie chiar acum. Vestea bună: pe un VPS mic, vinovatul e aproape întotdeauna unul din cinci lucruri și îl găsești în două minute.

1. Cât de rău e?

df -h /
df -i /

Prima linie arată spațiul folosit. A doua arată inodurile — dacă inodurile ajung la 100% cât spațiul pare în regulă, ai milioane de fișiere minuscule (fișiere de sesiune, o coadă de e-mail, un director de cache). Altă problemă, același simptom.

2. Află ce e mare

Parcurge arborele de sus și sortează după mărime:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x îl ține pe un singur sistem de fișiere, ca să nu rătăcească prin /proc. Apoi intră în ce e mai mare. Pentru navigare interactivă, ncdu e mult mai plăcut:

apt install -y ncdu
ncdu -x /

Săgețile ca să navighezi, d ca să ștergi. Ai grijă cu ultima.

3. Câștigurile rapide

Sunt sigure pe orice server Ubuntu sau Debian:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove curăță și kernelurile vechi. Jurnalul systemd e cel care îi surprinde pe oameni — lăsat în pace, poate crește la câțiva gigaocteți. Ca să-l plafonezi definitiv, setează SystemMaxUse=200M în /etc/systemd/journald.conf și rulează systemctl restart systemd-journald.

4. Resturile Docker

Dacă rulezi Docker, uită-te întâi aici. Imaginile vechi și cache-ul de build se adună la fiecare deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a șterge imaginile pe care nu le folosește niciun container care rulează. De obicei asta vrei, dar următorul deploy le va descărca din nou.

Cea periculoasă e docker system prune -a --volumes. Volumele îți țin datele, iar un volum atașat unui container oprit contează ca nefolosit. Oamenii își pierd bazele de date așa. Nu o lipi dintr-un răspuns de pe un forum.

Logurile containerelor sunt celălalt consumator ascuns. Plafonează-le în /etc/docker/daemon.json:

{
  "log-driver": "json-file",
  "log-opts": { "max-size": "10m", "max-file": "3" }
}

Repornește Docker după asta. Limita se aplică doar containerelor create ulterior, așa că recreează-le pe cele gălăgioase cu docker compose up -d --force-recreate.

5. Loguri și fișiere uitate

Găsește fișierele mari de oriunde de pe disc:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Descoperirile obișnuite: un backup.tar.gz de acum șase luni în /root, un dump de bază de date pe care cineva voia să-l descarce, un log de aplicație care nu se rotește niciodată.

Pentru un log în care un serviciu încă scrie, nu-l șterge cu rm — golește-l:

truncate -s 0 /var/log/myapp/app.log

Dacă ai șters deja unul și spațiul nu s-a eliberat, un proces încă îl ține deschis:

lsof +L1

Repornește serviciul listat acolo și spațiul revine.

Când curățenia nu ajunge

Uneori datele sunt pur și simplu reale — o bază de date care crește, fișiere urcate de utilizatori, un fișier de model. Atunci soluția cinstită e mai mult disc. Upgrade-ul planului mărește discul pe loc și păstrează tot: Nano are 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Serverul repornește o dată. Detaliile sunt în documentația planurilor.

Încă un lucru care mănâncă spațiu pe tăcute: un fișier swap. Dacă ai urmat ghidul nostru de swap, cei 1–2 GB sunt socotiți intenționat. Iar dacă Docker e principalul consumator, ghidul de instalare Docker și ghidul pentru stackuri Compose arată cum ții sub control înmulțirea imaginilor.

Obiceiul care previne toate astea: plafonează jurnalul și logurile Docker din prima zi. Două linii de configurare, iar „disc plin” aproape că nu se mai întâmplă.