Är 'docker system prune -a' säkert att köra?

Det tar bort stoppade containrar, oanvända nätverk, lös build-cache och varje image som ingen körande container använder. Din data finns kvar, om du inte lägger till --volumes. Med --volumes raderas även oanvända volymer — och volymen till en stoppad databascontainer räknas som oanvänd. Hoppa över den flaggan om du inte är säker.

Jag raderade en stor loggfil men df visar fortfarande full disk. Varför?

En körande process har fortfarande filen öppen, så kärnan håller kvar utrymmet. Hitta den med 'lsof +L1' och starta om tjänsten. Nästa gång tömmer du en aktiv logg med 'truncate -s 0 fil' i stället för att radera den.

Hur mycket ledigt utrymme bör jag ha kvar?

Minst 10–15 %. Databaser, paketuppdateringar och Docker-hämtningar behöver tillfälligt utrymme, och en disk på 100 % kan skada en databas mitt i en skrivning.

Kan jag få mer disk utan att installera om?

Ja. En uppgradering till en större plan växer disken på plats och behåller din data — Nano har 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Uppgraderingen startar om servern en gång.

Vad brukar fylla en liten VPS?

Enligt vår erfarenhet: Docker-images och build-cache, systemd-journalen, applikationsloggar som ingen roterar och bortglömda databasdumpar eller backuparkiv i /root.

Så frigör du diskutrymme på en VPS utan att förstöra något

Full disk på din VPS? Hitta vad som tar plats med du och ncdu, och rensa apt-cache, journal, Docker-rester och loggar utan att förlora data.

"No space left on device" dyker aldrig upp vid ett bra tillfälle. Databasen slutar ta emot skrivningar, apt kan inte slutföra en uppgradering och Docker vägrar hämta just den image du behöver nu. Den goda nyheten: på en liten VPS är boven nästan alltid en av fem saker, och du hittar den på två minuter.

1. Hur illa är det?

df -h /
df -i /

Första raden visar använt utrymme. Den andra visar inoder — om inoderna når 100 % medan utrymmet ser okej ut har du miljontals pyttesmå filer (sessionsfiler, en e-postkö, en cachekatalog). Annat problem, samma symtom.

2. Hitta det som är stort

Gå igenom trädet uppifrån och sortera efter storlek:

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

-x håller sig på ett filsystem, så den irrar inte in i /proc. Borra sedan ner i det som är störst. För att bläddra interaktivt är ncdu mycket trevligare:

apt install -y ncdu
ncdu -x /

Piltangenter för att navigera, d för att radera. Var försiktig med den sista.

3. De snabba vinsterna

De här är säkra på alla Ubuntu- och Debian-servrar:

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

apt autoremove rensar även gamla kärnor. Systemd-journalen är den som överraskar folk — lämnad åt sig själv kan den växa till flera gigabyte. För att begränsa den för gott, sätt SystemMaxUse=200M i /etc/systemd/journald.conf och kör systemctl restart systemd-journald.

4. Docker-rester

Kör du Docker, titta här först. Gamla images och build-cache staplas på varandra vid varje deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a raderar images som ingen körande container använder. Oftast är det vad du vill, men nästa deploy hämtar dem igen.

Den farliga är docker system prune -a --volumes. Volymer innehåller din data, och en volym kopplad till en stoppad container räknas som oanvänd. Det är så folk förlorar databaser. Klistra inte in den från ett forumsvar.

Den andra dolda slukaren är containerloggar. Begränsa dem i /etc/docker/daemon.json:

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

Starta om Docker efter det. Gränsen gäller bara containrar som skapas efteråt, så återskapa de pratsamma med docker compose up -d --force-recreate.

5. Loggar och bortglömda filer

Hitta stora filer var som helst på disken:

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

De vanliga fynden: en backup.tar.gz från för ett halvår sedan i /root, en databasdump som någon skulle ladda ner, en applikationslogg som aldrig roteras.

En logg som en tjänst fortfarande skriver till ska du inte ta bort med rm — töm den:

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

Har du redan raderat en och utrymmet inte kom tillbaka, håller en process den fortfarande öppen:

lsof +L1

Starta om tjänsten som listas där så kommer utrymmet tillbaka.

När städning inte räcker

Ibland är datan helt enkelt verklig — en växande databas, uppladdningar från användare, en modellfil. Då är den ärliga lösningen mer disk. En uppgradering av planen växer disken på plats och behåller allt: Nano har 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Servern startar om en gång. Detaljerna finns i dokumentationen om planer.

En sak till som tyst äter utrymme: en swapfil. Om du följde vår swap-guide är de 1–2 GB avsatta med flit. Och om Docker är den största förbrukaren visar guiden för att installera Docker och guiden för Compose-stackar hur du håller images i schack.

Vanan som förhindrar allt det här: begränsa journalen och Docker-loggarna dag ett. Två rader konfiguration, och "full disk" slutar i stort sett att hända.