Backup Restore Fails Mid-Process on cPanel/Plesk – Fixes

1. Disk Space Runs Out Mid-Restore

This is the number one culprit. The restore process extracts files, imports databases, and creates temp files. If your /home or /var partition fills up, the process just dies. No error message, just a half-done restore.

Check it first – run df -h and look at available space. If it's under 10% free, that's your problem. The restore needs at least 1.5x the backup file size in free space, often more for databases.

Fix:

• Delete old backups – rm -rf /backup/*.tar.gz if you have them
• Clear temp directories – rm -rf /tmp/* 2>/dev/null
• If using cPanel, empty the trash: rm -rf /home/*/.trash/*
• Then restart the restore. Don't bother with disk cleanup tools – just free up space manually.

If you're on a VPS with a small root partition, check /var too. Many hosting panels install databases there.

2. PHP Maximum Execution Time Kills the Process

Hosting panels like cPanel and Plesk use PHP scripts to manage restores. The default PHP max_execution_time is 30 seconds. A restore of a 500MB site takes minutes, not seconds. PHP kills the script, and the restore stops.

Where to fix it:

For cPanel (via WHM):

• Go to WHM → Tweak Settings → PHP Configuration
• Set max_execution_time to 3600 (or 0 to disable it)
• Set memory_limit to 512M or higher
• Click Save. Then restart the restore.

For Plesk:

• Edit the PHP configuration file – usually /etc/php.ini or /opt/plesk/php/7.4/etc/php.ini
• Find max_execution_time = 30 and change it to max_execution_time = 3600
• Also increase max_input_time = 3600
• Restart Apache or nginx: systemctl restart httpd or systemctl restart nginx

Don't bother adjusting the PHP-FPM pool settings – it's almost never needed. Just increase the base PHP limits.

3. Corrupted Backup File or Database Dump

Sometimes the backup file itself is bad. A 2GB tar.gz with a partial MySQL dump inside. The restore starts, unpacks a few files, then hits a broken SQL line and stops.

Test the backup file:

• tar -tzf backup.tar.gz | head -20 – if it errors out, the archive is corrupt
• For the SQL dump: gunzip -c backup.sql.gz | head -100 – look for 'ERROR' or truncated lines

Fix: If the archive is corrupt, you're out of luck on that file. But try extracting it with tar -xzf backup.tar.gz --ignore-failed-read – sometimes you can salvage partial data. For the SQL dump, use sed -i '/^ERROR/d' backup.sql to skip broken lines, then retry the restore.

If you have a previous backup version, use that. This is why you keep 3 generations of backups.

4. MySQL/MariaDB Timeout During Import

Big databases with millions of rows can take hours to import. The MySQL server might hit its own timeout – wait_timeout or max_allowed_packet.

Check the error log: tail -100 /var/log/mysql/error.log – look for Lost connection to MySQL server or Packet too large.

Fix:

• Increase max_allowed_packet to 512M in /etc/my.cnf under [mysqld]
• Increase wait_timeout to 600
• Restart MySQL: systemctl restart mariadb or systemctl restart mysql

If the database is over 5GB, skip the panel's restore tool. Do it manually via command line: mysql -u root -p database_name < dump.sql. It's faster and less likely to timeout.

Quick-Reference Summary Table

Start with disk space – nine times out of ten that's it. If not, move to PHP limits. Skip the panel's restore tool for big databases and do it manually. And always verify your backup file before starting a restore.