HestiaCP Backup Failed: Fix Not Enough Disk Space 2026

Alright, let’s cut the small talk — you’re here because HestiaCP just emailed you something like this:

“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”

I’ll keep this short and practical. Your backup failed because the free disk space (20804 MB, about 20.3 GB) is smaller than what HestiaCP needs for this account (23238 MB, about 22.7 GB). The shortfall is roughly 2.4 GB. The fix is usually simpler than you think. Here are the steps, in order.

Why HestiaCP Needs 2x the Account Size

Local backups in HestiaCP are written to /backup. While a backup runs, the original data is still on disk and the compressed archive is being written at the same time. Both sets of data exist simultaneously, so the space requirement is roughly 2x the account size — that’s where the 11619 * 2 = 23238 MB in the error message comes from.

One important detail: the free-space check runs against the partition where /backup lives, not the root partition. If /backup is a separate mount point, you can have tons of space on / and still hit this exact error. So don’t assume — check.

Here’s the good news hidden in that email: you’re not short by gigabytes and gigabytes. The disk had 20804 MB free and needed 23238 MB. That’s a gap of just ~2.4 GB. Cleaning a few logs or deleting one old backup archive is often enough to close it. Most people panic and resize the VPS before realizing a 2-minute cleanup would have solved it. Don’t be that person.

Also worth knowing: this error doesn’t mean the server is full. It means the partition holding your backups doesn’t have enough room at the moment the backup started. If you fix the space issue, the same scheduled backup will just run again next time — no reconfiguration needed.

Step 1: Check Disk Space

SSH into the server and run the most underused command in sysadmin:

df -h

Expected output, roughly:

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

Pay attention to the Avail and Mounted on columns. Then check the backup partition specifically:

df -h /backup

Now you know exactly which partition is the bottleneck. Quick refresher on reading df output: How to Check Linux Disk Usage.

Step 2: Clean Out Old Backups in /backup

This is the number one cause of this error. Old .tar archives pile up in /backup and nobody notices until the space check fails.

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

Backups are stored per user in this format: dennyrw3.2026-07-21_04-30-00.tar. The du -sh /backup/* output tells you which file is eating the most space.

Delete old backups you no longer need. For example, everything from May:

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

For the long term, set a rotation policy in Server > Backup in the Hestia web UI. Manual cleanup alone never works — it’s like sweeping the floor without emptying the bin.

Step 3: Clean System Junk

If /backup is clean and you still need room, look at these usual suspects:

a. APT cache

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

b. System logs

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

If journald is eating multiple GB, cap it:

journalctl --vacuum-size=200M

Then scan /var/log for anything that looks bloated. Full guide here: Cleaning Up Linux Server Logs.

c. Old kernels (Ubuntu/Debian)

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

Compare installed kernels against the running one, then apt-get autoremove --purge to drop the old ones. Don’t remove the kernel that’s currently running.

d. Web server logs

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

Access logs on busy sites grow fast — I’ve seen 6 GB from bot traffic alone. Truncate instead of rm to avoid breaking the open file descriptor.

Step 4: Check What’s Eating the Account

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

Common culprits:

• tmp folders with half-finished uploads or session files
• Mailboxes nobody cleans
• Application logs that never rotate (Laravel, CMSes, you name it)
• Old backups stored inside the home directory — backups piling on backups

Remember the 2x rule: every 1 GB you free inside the account frees 2 GB of backup space. Worth the effort.

Step 5: Move Backups to Remote Storage

This is the sustainable fix if your disk is permanently tight. HestiaCP supports FTP/FTPS and SFTP backups:

1. Hestia web UI > Server > Backup
2. Switch the backup system to FTP/SFTP
3. Enter host, credentials, and target directory
4. Save, then run a test backup

Or register an FTP host from the CLI:

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

Then switch the mode with v-change-backup-mode ftp. Verify your current config:

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

Remote backups don’t need 2x local space, and they survive a disk failure. Full walkthrough: Backing Up a VPS to FTP/SFTP Storage.

Step 6: Resize the Disk (Last Resort)

If the disk is genuinely too small for the data — say a 20 GB VPS holding 11 GB of one account — increase the size at your provider and grow the partition:

1. Increase the disk size in the provider panel (e.g. from 50 GB to 80 GB)
2. Resize the partition and filesystem on the server

Step-by-step here: How to Resize a VPS KVM Disk Without Data Loss. But ordering matters — clean up first, then consider spending money on more disk.

Step 7: Monitor So It Never Happens Again

The part everyone skips: don’t wait for the backup failed email to show up before you act. Set up disk usage monitoring. Netdata works great for this: Monitoring VPS Disk Usage with Netdata.

Simple thresholds: 80% used = pay attention, 90% = warning, 95% = too late — the backup will fail and you’ll get the same email you’re reading right now.

Also make it a habit to check the HestiaCP backup log:

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

Quick Troubleshooting Table

FAQ

Wrapping Up

That’s really all there is to it. The root cause here is a single number: the disk was short about 2.4 GB. Check df, clear old backups, clear system junk, and only then look at moving backups off-server or resizing the disk.

One last thing: don’t stop at the fix. Set up monitoring, configure backup rotation, and check disk usage weekly. A silently failing backup is dangerous — you don’t find out until the day you actually need that restore. Done reading? Go free up that space and run the backup again.