Backup HestiaCP Gagal: Fix Not Enough Disk Space 2026

Bener-bener deh, aku capek lihat email kayak gini masuk ke mailbox. Backup gagal, semua orang panik, padahal sumber masalahnya sebenernya gampang banget ditemuin. Kamu baru aja dapet notifikasi ini?

“Not enough disk space available (20804 mb) to perform the backup of dennyrw3. ( 11619 mb * 2 = 23238 mb). https://hestiacp.com/docs/server-administration/backup-restore.html”

Tenang, kamu gak sendirian. Ini salah satu error backup HestiaCP yang paling sering muncul di dunia hosting. Dan yang bikin kesel, error kayak gini biasanya udah bisa dicegah dari jauh-jauh hari kalau aja ada yang rutin ngecek disk usage. Masalahnya, orang baru sadar pas email gagal backup udah nyampe. Kayak gini nih yang bikin aku pengen teriak tiap lihat ticket masuk.

Error-nya Sebenernya Bicara Apa Sih?

Jadi gini, sebelum panik, mari kita baca baik-baik isi pesan errornya. Angka pertama, 20804 mb, itu ruang kosong (free space) di disk server kamu saat backup dijalankan. Terus 11619 mb itu total ukuran akun dennyrw3 — semua file web, database, email, dan konfigurasi di dalamnya. Nah, 23238 mb (11619 x 2) itu estimasi ruang yang HestiaCP butuh buat menyelesaikan backup-nya.

Kenapa harus dua kali lipat? Ibarat pindah rumah: barang-barangmu masih di tempat lama, tapi kamu butuh ruang buat naruh kardus hasil packing. Sampai backup kelar dan file-nya aman, data asli gak bisa diusik. Jadi pas proses backup berjalan, ada dua set data yang makan tempat di waktu yang sama — data asli plus arsip hasil kompresi. Makanya butuh kira-kira 2x ukuran akun.

Dan inilah yang bikin gemes: coba itung selisihnya. Butuh 23238 mb, tersedia 20804 mb. Kurangnya cuma sekitar 2434 mb — kira-kira 2,4 GB aja! Padahal seringkali ngebersihin log atau buang backup lama udah cukup nutup gap segitu. Masalahnya kebanyakan orang nyerah sebelum nemu sumber utamanya. Jangan kayak gitu ya. Ini gampang kok, asal dibongkar pelan-pelan.

Yang juga perlu kamu pahami, error ini gak selalu artinya disk server beneran penuh. Bisa jadi root masih lega, tapi backup-nya gagal karena HestiaCP nyimpen backup di /backup yang ternyata partisi terpisah dan udah mepet. Makanya langkah pertamanya adalah cek dulu, jangan nebak-nebak.

Langkah 1: Cek Kondisi Disk Dulu

Buka SSH ke server kamu, lalu jalankan perintah paling simpel tapi sering dilupain ini:

df -h

Output yang diharapkan kurang lebih kayak gini:

Filesystem      Size  Used Avail Use% Mounted on
/dev/sda1        50G   30G   20G  60% /
/dev/sdb1        10G  8.5G  1.5G  85% /backup

Perhatiin kolom Avail (sisa ruang) sama Mounted on. Di HestiaCP, lokasi default backup lokal itu /backup. Kalau di server kamu partisi ini di-mount sendiri, ya yang dicek HestiaCP adalah free space di partisi /backup itu, bukan di root. Ini sumber kebingungan paling umum — di / masih sisa banyak, tapi backup tetep gagal karena partisi backup-nya yang mepet.

Jadi cek spesifik ke direktori backup-nya:

df -h /backup

Nah, dari sini langsung kelihatan partisi mana yang jadi biang kerok. Kalau butuh refresh singkat soal baca output df, aku pernah nulis ringkas di sini: Cara Cek Disk Usage di Linux.

Langkah 2: Tersangka Utama — Tumpukan Backup Lama di /backup

Penyebab paling umum error not enough disk space itu ya backup lama yang gak pernah dibersihin. HestiaCP sebenernya punya fitur rotasi backup, tapi kalau setelannya gak diatur atau gak pernah dicek, file .tar bakal numpuk tanpa ampun.

Lihat isi direktori backup:

ls -lah /backup/
du -sh /backup/*

Output du -sh /backup/* langsung nunjukin file mana yang paling gede. Format backup HestiaCP per user itu kayak gini: dennyrw3.2026-07-21_04-30-00.tar.

Kalau nemu backup lama yang udah gak relevan, hapus aja. Contoh, hapus semua backup bulan Mei dari user itu:

rm /backup/dennyrw3.2026-05-*.tar

Buat jangka panjang, setel rotasi backup di Hestia Web UI: menu Server > Backup. Atur berapa backup per user yang mau disimpen. Jangan cuma ngandelin hapus manual tiap bulan — itu kayak nyapu tanpa naruh tempat sampah, gak kelar-kelar.

Langkah 3: Bersihkan Sampah Sistem

Kalau /backup udah bersih tapi masih kurang, giliran nyari sampah di tempat lain. Beberapa lokasi yang paling sering nyembunyiin gigabyte:

a. Cache apt

du -sh /var/cache/apt/archives
apt-get clean
apt-get autoremove --purge

apt-get clean ngilangin semua paket .deb hasil download installer, dan autoremove --purge nyapu paket yang gak kepake. Dua-duanya aman dan jarang bikin masalah. Cek ukurannya dulu, kalau cuma puluhan MB mah gak ngaruh banyak — fokus ke yang gede-gede.

b. Log sistem yang numpuk

du -sh /var/log/*
journalctl --disk-usage

Kalau journald makan 1-2 GB (atau lebih), batasin ukurannya:

journalctl --vacuum-size=200M

Itu bakal nutup file journal lama yang lewat batas 200 MB. Aman kok, log yang penting udah diputar ke file lain. Terus liat /var/log satu-satu, cari yang ukurannya gak wajar. Log server yang numpuk bisa dibaca lengkap di: Bersihkan Log Server Linux Paling Efektif.

c. Kernel lama (Ubuntu/Debian)

dpkg -l 'linux-*' | grep '^ii' | awk '{print $2}'
uname -r

Bandingin kernel yang terinstall sama kernel yang lagi jalan. Kernel lama yang gak kepake bisa dibuang via apt-get autoremove --purge. Hati-hati, jangan hapus kernel yang lagi aktif.

d. Log web server

du -sh /var/log/nginx /var/log/apache2 /var/log/php* 2>/dev/null
truncate -s 0 /var/log/nginx/access.log

Log access nginx dari website yang trafficnya gede bisa tumbuh sampe beberapa GB — aku pernah nemu 6 GB karena digedor bot. Kalau ketemu yang gede, truncate atau rotate. Awas, jangan langsung rm log yang lagi dipakai web server, bisa bikin error file descriptor.

Langkah 4: Kurangi Ukuran Akun Kalau Emang Kegedean

Kadang masalahnya bukan disk yang kecil, tapi akun-nya yang gede banget. Cek ukuran akun dennyrw3:

du -sh /home/dennyrw3/web
du -sh /home/dennyrw3/mail
du -sh /home/dennyrw3/* 2>/dev/null | sort -rh | head -20

Yang paling sering bikin akun melar:

• Folder tmp di dalam direktori web yang isinya upload setengah jadi atau session
• Mailbox yang jarang dibersihin — ini diam-diam makan banyak
• Log aplikasi (framework kayak Laravel, atau CMS) yang gak di-rotate
• Backup lama yang ditaruh di dalam home directory — ironisnya, backup nimbun backup

Ingat aturan 2x tadi: setiap 1 GB yang kamu hemat di akun, itu 2 GB ruang yang dihemat HestiaCP pas backup. Jadi bersihin akun itu dobel manfaatnya.

Langkah 5: Pindah Backup ke Remote Storage

Nah, ini solusi jangka panjang yang paling aku saranin kalau disk kamu emang mepet permanen. Daripada tiap bulan berantem sama ruang disk, kenapa gak pindahin aja backup-nya ke tempat lain?

HestiaCP mendukung backup ke FTP/FTPS dan SFTP. Langkahnya:

1. Buka Hestia Web UI > Server > Backup
2. Ganti backup system ke FTP/SFTP
3. Isi host, username, password, dan direktori tujuan
4. Simpan, lalu tes backup sekali buat mastiin jalan

Alternatif dari CLI, daftarin host FTP dulu:

v-add-backup-ftp-host ftp-backup.example.com username password

Terus aktifin modenya: v-change-backup-mode ftp atau lewat UI. Cek juga konfigurasi backup-nya biar yakin:

grep -i backup /etc/hestiacp/hestia.conf

Dengan backup remote, HestiaCP gak lagi butuh ruang 2x di disk lokal. Bonusnya, backup kamu aman dari single point of failure — kalau disk server rusak, backup masih ada di tempat lain. Panduan lengkapnya bisa dibaca di sini: Backup VPS ke Storage FTP/SFTP.

Langkah 6: Tambah Kapasitas Disk — Pilihan Terakhir

Kalau semua cara di atas udah dicoba dan disk memang beneran mentok — misal VPS kamu cuma 20 GB dan data akunnya emang udah 11 GB — ya udah, waktunya naikin kapasitas. Untuk VPS KVM biasanya gampang:

1. Naikin ukuran disk di panel provider (misal dari 50 GB ke 80 GB)
2. Resize partisi dan filesystem di server

Proses resize-nya ada di: Cara Resize Disk VPS KVM Tanpa Data Hilang. Tapi inget, nambah disk itu solusi mahal kalau akar masalahnya cuma sampah yang gak pernah dibersihin. Urutin: bersihin dulu, baru mikir nambah.

Langkah 7: Pasang Alert Biar Gak Kena Dua Kali

Ini bagian paling penting yang hampir selalu dilupain: jangan nunggu email backup gagal datang dulu baru gerak. Pasang monitoring disk usage. Netdata cocok buat ini, dan aku udah nulis caranya di: Monitoring Disk VPS dengan Netdata.

Rule simpelnya: disk usage lewat 80% mulai waspada, 90% itu warning, dan 95% itu udah telat — backup bakal gagal dan kamu bakal dapet email yang sama kayak sekarang. Trust me, aku udah kelilingan banyak server yang nyampe 99% cuma karena gak ada yang ngecek.

Terakhir, biasakan cek log backup HestiaCP secara berkala:

tail -n 100 /var/log/hestia/backup.log

Log ini nyimpen semua jejak proses backup, jadi kalau ada yang aneh, keliatan dari sini.

Tabel Troubleshooting Cepat

Biar makin praktis, ini rangkuman gejalanya:

FAQ

Penutup

Jadi sebenernya gak ada yang ribet. Inti masalahnya satu: ruang kosong disk kurang 2,4 GB dari yang dibutuhkan. Urutannya gampang — cek df, bersihin backup lama, bersihin sampah sistem, terus kalau masih kurang pindahin backup ke remote atau resize disk. Kelar.

Tapi tolong ya, jangan berhenti di fix doang. Pasang monitoring, atur rotasi backup, dan biasakan cek disk usage tiap minggu. Backup yang gagal itu bahaya yang diam-diam — kamu gak sadar sampai suatu hari beneran butuh restore dan gak ada yang bisa dipulihkan. Take it seriously. Semoga kalian gak ngalamin yang lebih parah dari ini.