Proxmox Backup Fails: Storage Full Error Fix

Quick Fix: Prune Old Backups (30 Seconds)

You're staring at "backup failed: storage is full" — I know that knot in your stomach. This error usually hits when your backup storage hits 100% capacity, often after a few failed jobs or aggressive retention settings. Let's fix it fast.

Open the Proxmox web GUI. Go to your backup storage (e.g., local or backups). Click on the Content tab. Select all old backup files — anything older than your last good backup set. Hit Remove. This frees space instantly.

If that's not enough, SSH into your Proxmox server and run this to prune the backup storage directly:

pvesm prune-backups local --keep-last 3 --keep-daily 7 --keep-weekly 4

Replace local with your actual storage ID. This command nukes old backups while keeping your last 3, daily for a week, and weekly for a month. I've seen this free up 50GB+ in under 5 seconds.

Moderate Fix: Check Retention & Schedule (5 Minutes)

Cleaning once won't help if your retention settings are wrong. I've seen people set keep-all and wonder why storage fills in two days. Go to Datacenter > Backup > your backup job, and click Edit.

Under Retention, set reasonable values. For a home lab or small business, I recommend:

• Keep Last: 3-5 backups
• Keep Daily: 7
• Keep Weekly: 4
• Keep Monthly: 2

This keeps your data safe without eating disk. Also check the Schedule — if you're backing up every 15 minutes, that's 96 backups a day. That's insane. Set it to daily at 2 AM when nobody's using the VMs.

Another common mistake: backing up to the same disk that holds your ISO templates or CT templates. That's a recipe for disaster. Move your backup storage to a separate pool or mount a dedicated NFS share.

Run the prune command again after changing retention to clean up leftovers:

pvesm prune-backups backups --keep-last 3 --keep-daily 7 --keep-weekly 4 --keep-monthly 2

Advanced Fix: Deep Clean Logs & Temp Files (15+ Minutes)

If you're still stuffed, Proxmox itself might be holding onto logs and temp files from failed backups. I've seen a single failed job leave 20GB of temp VMA files sitting in /var/tmp.

SSH into your server and check disk usage:

df -h

Look for partitions at 90%+ — usually /var or /. If /var is full, it's likely Proxmox backup logs or old vzdump files. Run:

du -sh /var/log/pve/*

If you see files like tasks/active or backup.log taking up gigabytes, truncate them:

> /var/log/pve/backup.log
> /var/log/pve/tasks/active

Next, check /var/tmp for leftover VMA files from failed backups:

find /var/tmp -type f -name "*.vma" -delete

This alone frees up huge chunks of space.

Also check your Proxmox host's /var/lib/vz — that's the default storage for templates and ISOs. If you've been downloading CT templates without cleaning, you can prune them:

pveam available --section system
pveam remove local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst

Only keep what you use. I keep Ubuntu 22.04 and Debian 12 — that's it.

Prevent It From Happening Again

Once you've freed space, set up automatic pruning. Add a cron job:

crontab -e

Add this line to run nightly at 3 AM:

0 3 * * * /usr/sbin/pvesm prune-backups local --keep-last 3 --keep-daily 7 --keep-weekly 4

Also consider setting a backup storage quota in Proxmox if you're using ZFS. ZFS doesn't enforce quotas the same way, but you can set a dataset quota:

zfs set quota=200G rpool/data/backups

This caps the dataset at 200GB, so full backups stop cleanly instead of crashing the whole pool.

Final Thought

This error is almost always a retention or temp file issue. Start with pruning — that's the 30-second fix. If you're still stuck after the deep clean, check your disk health with smartctl. A dying disk fills slowly as reallocation sectors pile up. But 9 times out of 10, it's just old backups eating your space.