Resolve JetBackup 5 “Destination Storage Full” Errors Safely

JetBackup 5 is a widely used backup tool for cPanel servers, yet administrators sometimes hit the “Destination Storage Full” error. The message can be misleading: even when the target volume has free space, a corrupted backup index can make JetBackup believe the destination is full. This guide walks you through a safe, step‑by‑step process to resolve the issue without damaging existing backup data.

1. Why the Error Occurs

Before a backup starts, JetBackup checks:

• Physical space – the actual bytes available on the destination volume.
• Index integrity – a SQLite database that records every backup file.

If the index is truncated, has incorrect permissions, or contains stale entries, JetBackup may report a full destination even though space exists. Fixing the problem therefore requires:

1. Verifying real free space.
2. Repairing or rebuilding the index.
3. Removing orphaned temporary files that may be hiding unused space.

2. Confirm Real Disk Space

Log in via SSH and run df -h against the backup mount point (replace /backup with your path).

# df -h /backup
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        2T   1.2T  800G  60% /backup

If the Avail column shows ample space (e.g., >10 % of total), move to the next step. If the volume is truly full, free space first—delete old backups or expand the storage.

3. Inspect and Repair the JetBackup Index

The index is a SQLite database located in /var/jetbackup5/index (or the custom path you configured). Follow these checks.

3.1. Verify Ownership and Permissions

JetBackup runs as the jetbackup user. The index directory and file must belong to that user.

Debian/Ubuntu (apt)

# chown -R jetbackup:jetbackup /var/jetbackup5/index
# chmod 750 /var/jetbackup5/index
# chmod 640 /var/jetbackup5/index/index.db

AlmaLinux/Rocky/RHEL (dnf)

# chown -R jetbackup:jetbackup /var/jetbackup5/index
# chmod 750 /var/jetbackup5/index
# chmod 640 /var/jetbackup5/index/index.db

Correcting permissions often resolves the error immediately.

3.2. Run a SQLite Integrity Check

Install the SQLite command‑line tool if it isn’t already present.

Debian/Ubuntu

# apt-get update
# apt-get install -y sqlite3

AlmaLinux/Rocky/RHEL

# dnf install -y sqlite

Execute the integrity test:

# sqlite3 /var/jetbackup5/index/index.db "PRAGMA integrity_check;"

Output ok means the database is structurally sound. Any error such as “malformed database” indicates the index is corrupted.

3.3. Rebuild the Index Safely

JetBackup provides a built‑in command to regenerate the index from existing backup files. This process reads the backup directory, recreates entries, and writes a fresh index.db without deleting any data.

All supported Linux distributions

# /usr/local/jetapps/jetbackup5/bin/jetbackup5 --rebuild-index --destination /backup

Explanation of the options:

• /usr/local/jetapps/jetbackup5/bin/jetbackup5 – the main JetBackup binary.
• --rebuild-index – tells JetBackup to discard the old index and create a new one.
• --destination /backup – points to the verified storage location.

After the command finishes, check /var/log/jetbackup5.log for warnings. Run the integrity check again; it should now return ok.

4. Remove Orphaned Temporary Files

Even with a healthy index, leftover temporary chunks can consume space and trigger “full” warnings. JetBackup stores temporary data in /backup/tmp (or your configured path).

4.1. Find Large Orphaned Files

List files larger than 100 MB that are older than 7 days:

# find /backup/tmp -type f -size +100M -mtime +7 -ls

4.2. Delete Safely

Remove only the files that match the criteria. Use -exec rm -f {} \; with caution.

# find /backup/tmp -type f -size +100M -mtime +7 -exec rm -f {} \;

Re‑run df -h to confirm reclaimed space.

5. Prevent Future Index Corruption

Most “Destination Storage Full” incidents stem from abrupt termination of backup jobs (power loss, service crash, or cPanel restart). Adopt these best practices:

• Graceful shutdown – ensure JetBackup stops before the system reboots.
• Monitor backup duration – set reasonable time‑outs in the schedule to avoid overlapping runs.
• Log rotation – keep /var/log/jetbackup5.log under control to prevent disk‑full scenarios caused by log growth.
• Scheduled index verification – run a cron job that checks the SQLite integrity daily and alerts you if it fails.

Example cron entry (runs Sundays at 02:00):

# crontab -u jetbackup -e
0 2 * * 0 /usr/bin/sqlite3 /var/jetbackup5/index/index.db "PRAGMA integrity_check;" | grep -v ok && \
    echo "JetBackup index corruption detected on $(date)" | mail -s "JetBackup Alert" admin@example.com

6. Verify the Fix with a Test Backup

After completing the steps above, run a small manual backup to confirm the error is gone.

# /usr/local/jetapps/jetbackup5/bin/jetbackup5 --run --destination /backup --account testuser

Check the console output or /var/log/jetbackup5.log for a success message. If the job completes without the “Destination Storage Full” warning, the issue is resolved.

Conclusion

The “Destination Storage Full” error in JetBackup 5 is often caused by an index problem rather than a genuine capacity shortage. By confirming real disk space, repairing permissions, running a SQLite integrity check, rebuilding the index, and cleaning up orphaned temporary files, you can restore normal backup operation without risking data loss. Regular preventive measures—graceful service stops, log rotation, and scheduled index verification—help keep the backup environment healthy for the long term.