A backup routine is only as good as its restore verification. In JetBackup 5 on cPanel and Linux servers, job failures typically arise from destination authentication timeouts, exhausted temporary staging space in /tmp, or cPanel database locks during live mysqldump exports.
Production Warning: Never initiate a large multi-account account restore directly onto a live production cPanel server without first checking available disk capacity and verifying whether existing databases will be dropped.
At a Glance
- Inspect active JetBackup daemon processes and job queue status from the CLI.
- Check S3, Wasabi, or SSH backup destination connectivity and authentication.
- Verify that the staging directory has sufficient space outside the
/tmppartition. - Execute granular restores for single files, cron jobs, or database tables.
- Verify restored cPanel account ownership and DNS records.
Prerequisites
Before troubleshooting or running JetBackup restores, confirm:
- Root SSH access to the cPanel / WHM server.
- Valid JetBackup 5 license and active
jetbackup5ddaemon. - Working remote backup destination (AWS S3, Wasabi, Backblaze B2, or SSH storage box).
- Sufficient free disk space on
/homeor dedicated backup staging volume.
Step 1: Diagnose Active JetBackup Queue and Service State
Check the status of the master JetBackup 5 daemon and review recent queue activity:
# Check JetBackup daemon status
systemctl status jetbackup5d
# Display recent JetBackup job queue statuses
jetbackup5 --list-queueTo tail live daemon logs during an active job execution:
# Tail the JetBackup master log
tail -f /usr/local/jetapps/var/log/jetbackup5/jetbackupd.logStep 2: Inspect Destination Health and S3 Connectivity
Destination failures occur when API keys rotate, endpoints change, or server firewalls block outbound HTTPS traffic.
Run a destination health check:
# Inspect all configured backup destinations
jetbackup5 --check-destinationIf testing an Amazon S3, Wasabi, or Backblaze B2 endpoint, verify HTTPS network connectivity directly:
# Test S3 DNS and HTTPS handshake directly
curl -Iv https://s3.wasabisys.com:443Step 3: Configure Dedicated Staging Directories to Prevent /tmp Fill-Ups
During account backups and restorations, JetBackup extracts archives to a temporary directory. If this directory defaults to /tmp, large MySQL databases can fill the RAM-disk partition and crash the server.
Create a dedicated staging directory on your largest storage partition:
# Create dedicated staging workspace
mkdir -p /home/jetbackup_tmp
chmod 700 /home/jetbackup_tmp
# Update JetBackup configuration path in Settings >> General via WHMStep 4: Execute Account and Database Restores via CLI
You can initiate restores directly from the command line without opening the WHM graphical interface.
# List available recovery points for a specific cPanel account
jetbackup5 --list-backups -account username
# Initiate a restore of database items only
jetbackup5 --restore -account username -items dbTroubleshooting
Problem: “Destination S3 connection timed out”
Possible cause: ConfigServer Security & Firewall (CSF) or iptables is blocking outbound connections to the S3 storage endpoint IP range.
Check:
csf -g S3_ENDPOINT_IPSolution: Add the storage provider’s domain or CIDR blocks to /etc/csf/csf.allow and reload CSF:
csf -raProblem: “No space left on device (/tmp/jetbackup)”
Possible cause: The /tmp partition is mounted with limited size (e.g., 4GB) and cannot accommodate large uncompressed database dumps.
Check:
df -h /tmpSolution: Reconfigure JetBackup’s temporary workspace path to /home/jetbackup_tmp in WHM >> JetBackup 5 >> Settings >> General.
Problem: “Database restore failed: MySQL server has gone away”
Possible cause: The max_allowed_packet or wait_timeout limits in MariaDB/MySQL are too low for large database inserts.
Check:
mysql -e "SHOW VARIABLES LIKE 'max_allowed_packet';"Solution: Increase the packet limit in /etc/my.cnf:
[mysqld]
max_allowed_packet=256M
wait_timeout=600Then restart the database service: systemctl restart mariadb.
Verify the Configuration
- Verify Restored File Permissions: Ensure restored public HTML files are owned by the cPanel user:
ls -la /home/username/public_html/ - Verify Database Table Count: Check that all tables are restored intact:
mysql -u root -e "SHOW TABLES FROM username_dbname;" - Verify Queue Completion: Confirm the restore task exits with status
Completedinjetbackup5 --list-queue.
Production Checklist
- JetBackup daemon is active and running (
jetbackup5d). - Outbound port 443 permitted for S3 storage endpoints.
- Staging workspace configured on a partition with over 50GB free space.
- Tested single-item restore before executing full account rollbacks.
- Verified MySQL
max_allowed_packetaccommodates large database restores.
Frequently Asked Questions
Can I restore a single MySQL table instead of the entire database in JetBackup 5?
Yes. JetBackup 5 allows granular database restorations where you can select individual tables from any point-in-time snapshot.
Does JetBackup 5 support incremental backups to Wasabi and Backblaze B2?
Yes. JetBackup 5 supports block-level incremental snapshots to S3-compatible cloud storage providers, significantly reducing daily bandwidth consumption.
Related Guides & Services
- How to Restore a Server Backup Using R1Soft
- How to Install SSL on R1Soft Backup Manager Using Certbot
- Server Backup Management Services
- cPanel & WHM Server Administration
Need Help Configuring Automated Server Backups?
If you manage cPanel fleets and need enterprise offsite backup pipelines with automated integrity checks, connect with our server management team.