Apakah 'docker system prune -a' aman dijalankan?

Perintah ini menghapus container yang berhenti, jaringan yang tidak dipakai, cache build yatim, dan setiap image yang tidak dipakai container yang sedang berjalan. Data Anda tetap aman, kecuali Anda menambahkan --volumes. Dengan --volumes, volume yang tidak dipakai juga terhapus — dan volume milik container database yang berhenti dianggap tidak dipakai. Jangan pakai flag itu kalau ragu.

Saya sudah menghapus file log besar, tapi df masih menunjukkan disk penuh. Kenapa?

Ada proses yang masih membuka file itu, jadi kernel belum melepas ruangnya. Cari dengan 'lsof +L1' lalu restart layanan tersebut. Lain kali, kosongkan log yang aktif dengan 'truncate -s 0 file' alih-alih menghapusnya.

Berapa banyak ruang kosong yang sebaiknya disisakan?

Setidaknya 10–15%. Database, pembaruan paket, dan pull Docker butuh ruang sementara, dan disk yang penuh 100% bisa merusak database di tengah proses menulis.

Bisakah saya menambah disk tanpa instal ulang?

Bisa. Upgrade ke paket yang lebih besar memperbesar disk di tempat dan menyimpan data Anda — Nano punya 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Upgrade me-restart server sekali.

Apa yang biasanya memenuhi VPS kecil?

Dari pengalaman kami: image dan cache build Docker, journal systemd, log aplikasi yang tidak pernah dirotasi, serta dump database atau arsip backup yang terlupakan di /root.

Cara mengosongkan ruang disk di VPS tanpa merusak apa pun

Disk VPS penuh? Cari tahu apa yang memakan ruang dengan du dan ncdu, lalu bersihkan cache apt, journal, sisa Docker, dan log tanpa kehilangan data.

"No space left on device" tidak pernah muncul di saat yang tepat. Database berhenti menerima penulisan, apt tidak bisa menyelesaikan upgrade, dan Docker menolak menarik image yang justru Anda butuhkan sekarang. Kabar baiknya: di VPS kecil, penyebabnya hampir selalu satu dari lima hal, dan Anda bisa menemukannya dalam dua menit.

1. Seberapa parah?

df -h /
df -i /

Baris pertama menunjukkan ruang terpakai. Baris kedua menunjukkan inode — kalau inode mencapai 100% padahal ruang terlihat aman, berarti ada jutaan file kecil (file sesi, antrean surat, direktori cache). Masalahnya beda, gejalanya sama.

2. Temukan yang besar

Telusuri pohon direktori dari atas dan urutkan berdasarkan ukuran:

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

-x tetap berada di satu sistem file, jadi tidak nyasar ke /proc. Lalu masuk ke yang paling besar. Untuk menjelajah secara interaktif, ncdu jauh lebih nyaman:

apt install -y ncdu
ncdu -x /

Tombol panah untuk navigasi, d untuk menghapus. Hati-hati dengan yang terakhir.

3. Kemenangan cepat

Perintah ini aman di server Ubuntu atau Debian mana pun:

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

apt autoremove juga membersihkan kernel lama. Journal systemd adalah yang paling sering mengejutkan orang — kalau dibiarkan, ukurannya bisa mencapai beberapa gigabyte. Untuk membatasinya secara permanen, atur SystemMaxUse=200M di /etc/systemd/journald.conf lalu jalankan systemctl restart systemd-journald.

4. Sisa-sisa Docker

Kalau Anda memakai Docker, periksa di sini dulu. Image lama dan cache build menumpuk di setiap deploy:

docker system df
docker image prune -a
docker builder prune

docker image prune -a menghapus image yang tidak dipakai container mana pun yang sedang berjalan. Biasanya itu yang Anda mau, tapi deploy berikutnya akan menariknya lagi.

Yang berbahaya adalah docker system prune -a --volumes. Volume menyimpan data Anda, dan volume yang terpasang ke container yang berhenti dianggap tidak dipakai. Begitulah orang kehilangan database. Jangan tempel perintah ini dari jawaban forum.

Pemakan ruang tersembunyi lainnya adalah log container. Batasi di /etc/docker/daemon.json:

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

Setelah itu restart Docker. Batasnya hanya berlaku untuk container yang dibuat sesudahnya, jadi buat ulang container yang berisik dengan docker compose up -d --force-recreate.

5. Log dan file yang terlupakan

Cari file besar di mana pun di disk:

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

Temuan yang biasa: backup.tar.gz dari enam bulan lalu di /root, dump database yang tadinya mau diunduh seseorang, log aplikasi yang tidak pernah dirotasi.

Log yang masih ditulisi sebuah layanan jangan dihapus dengan rm — kosongkan saja:

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

Kalau sudah terlanjur menghapus dan ruangnya tidak kembali, berarti masih ada proses yang membukanya:

lsof +L1

Restart layanan yang tercantum di sana dan ruangnya akan kembali.

Kalau bersih-bersih tidak cukup

Kadang datanya memang nyata — database yang terus bertambah, unggahan pengguna, file model. Kalau begitu, solusi yang jujur adalah disk yang lebih besar. Upgrade paket memperbesar disk di tempat dan menyimpan semuanya: Nano punya 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Server restart sekali. Detailnya ada di dokumentasi paket.

Satu hal lagi yang diam-diam memakan ruang: file swap. Kalau Anda mengikuti panduan swap kami, 1–2 GB itu memang sengaja disisihkan. Dan kalau Docker adalah pemakan terbesar, panduan instalasi Docker dan panduan stack Compose menunjukkan cara menjaga jumlah image tetap terkendali.

Kebiasaan yang mencegah semua ini: batasi journal dan log Docker sejak hari pertama. Dua baris konfigurasi, dan "disk penuh" hampir tidak pernah terjadi lagi.