Безопасна ли е командата 'docker system prune -a'?

Тя премахва спрените контейнери, неизползваните мрежи, осиротелия build кеш и всеки image, който не се ползва от работещ контейнер. Данните ви остават, освен ако не добавите --volumes. С --volumes се изтриват и неизползваните volume-и — а volume на спрян контейнер с база данни се брои за неизползван. Не слагайте този флаг, ако не сте сигурни.

Изтрих голям лог файл, но df още показва пълен диск. Защо?

Работещ процес все още държи файла отворен, затова ядрото не освобождава мястото. Намерете го с 'lsof +L1' и рестартирайте услугата. Следващия път изпразнете активен лог с 'truncate -s 0 файл', вместо да го триете.

Колко свободно място да оставям?

Поне 10–15%. Базите данни, обновяванията на пакети и изтеглянията на Docker имат нужда от временно място, а диск на 100% може да повреди база данни по време на запис.

Мога ли да увелича диска без преинсталиране?

Да. Преминаването към по-голям план увеличава диска на място и запазва данните — Nano има 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Надграждането рестартира сървъра веднъж.

Какво обикновено запълва малък VPS?

По наш опит: image-ите и build кешът на Docker, journal-ът на systemd, логове на приложения, които никой не ротира, и забравени дъмпове на бази данни или архиви с копия в /root.

Как да освободите дисково пространство на VPS, без да счупите нещо

Дискът на VPS е пълен? Открийте с du и ncdu какво заема място и изчистете кеша на apt, journal, остатъците от Docker и логовете без загуба на данни.

„No space left on device" никога не идва в удобен момент. Базата данни спира да приема записи, apt не може да завърши обновяване, а Docker отказва да изтегли точно image-а, който ви трябва сега. Добрата новина: на малък VPS виновникът почти винаги е едно от пет неща и го намирате за две минути.

1. Колко е зле?

df -h /
df -i /

Първият ред показва заетото място. Вторият показва inode-ите — ако те стигнат 100%, а място уж има, значи имате милиони миниатюрни файлове (сесийни файлове, опашка за поща, кеш директория). Различен проблем, същият симптом.

2. Намерете какво е голямо

Обходете дървото отгоре и сортирайте по размер:

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

-x остава в една файлова система, така че не се губи в /proc. После влезте в най-голямото. За интерактивно разглеждане ncdu е много по-удобен:

apt install -y ncdu
ncdu -x /

Стрелки за навигация, d за изтриване. С последното внимавайте.

3. Бързите победи

Тези са безопасни на всеки сървър с Ubuntu или Debian:

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

apt autoremove чисти и старите ядра. Journal-ът на systemd е този, който изненадва хората — оставен сам, може да порасне до няколко гигабайта. За да го ограничите завинаги, задайте SystemMaxUse=200M в /etc/systemd/journald.conf и изпълнете systemctl restart systemd-journald.

4. Остатъци от Docker

Ако ползвате Docker, погледнете първо тук. Старите image-и и build кешът се трупат при всеки deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a изтрива image-ите, които не се ползват от работещ контейнер. Обикновено това искате, но следващият deploy ще ги изтегли отново.

Опасната е docker system prune -a --volumes. Volume-ите пазят данните ви, а volume, закачен към спрян контейнер, се брои за неизползван. Така хората губят бази данни. Не я копирайте от отговор във форум.

Другият скрит лакомник са логовете на контейнерите. Ограничете ги в /etc/docker/daemon.json:

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

След това рестартирайте Docker. Лимитът важи само за контейнери, създадени след това, затова пресъздайте шумните с docker compose up -d --force-recreate.

5. Логове и забравени файлове

Намерете големите файлове навсякъде по диска:

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

Обичайните находки: backup.tar.gz отпреди половин година в /root, дъмп на база, който някой е искал да свали, лог на приложение, който никога не се ротира.

Лог, в който услуга още пише, не трийте с rm — изпразнете го:

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

Ако вече сте изтрили такъв и мястото не се е върнало, някой процес все още го държи отворен:

lsof +L1

Рестартирайте посочената услуга и мястото се връща.

Когато чистенето не стига

Понякога данните просто са реални — растяща база, качени от потребители файлове, файл с модел. Тогава честното решение е повече диск. Надграждането на плана увеличава диска на място и запазва всичко: Nano има 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Сървърът се рестартира веднъж. Подробностите са в документацията за плановете.

Още нещо, което тихо изяжда място: swap файлът. Ако сте следвали нашето ръководство за swap, тези 1–2 GB са заделени нарочно. А ако Docker е най-големият консуматор, ръководството за инсталиране на Docker и ръководството за Compose стекове показват как да държите image-ите под контрол.

Навикът, който предотвратява всичко това: ограничете journal-а и логовете на Docker още първия ден. Два реда конфигурация и „пълен диск" на практика спира да се случва.