Plesk Backup Failed: How to Fix It

Plesk backups can fail silently or with an error notification — either way, a failed backup means your data is unprotected. The most common causes are insufficient disk space, a backup storage destination that is unavailable, a database that is too large to dump within the timeout, or a permissions problem preventing Plesk from writing the backup files. This guide covers each cause and how to resolve it.

Where to Find Backup Error Details

Before attempting any fix, locate the specific error. In Plesk, navigate to Backup Manager, find the failed backup entry, and click the failure icon or select View Log. The log breaks the backup down by component — files, databases, mail — and shows exactly where the process stopped and why.

Common log entries to look for include No space left on device, Connection refused, mysqldump: Error, and Permission denied. Each of these points to a distinct cause covered below. Do not skip this step — guessing at the cause wastes time and risks missing the actual problem.

Cause 1: Not Enough Disk Space

This is the most frequent reason Plesk backups fail. Plesk writes backup files to /var/lib/psa/dumps/ by default before moving them to the final destination. Both the temporary working directory and the final storage location must have adequate free space. If either fills up mid-backup, the process fails.

To check available space from the Plesk UI, go to Tools & Settings > Server Health > Disk Usage. To check via SSH:

1. Connect to the server via SSH.
2. Run df -h to see disk usage across all mounted filesystems. Pay attention to the partition that hosts /var/lib/psa/dumps/ and your backup destination.
3. If space is low, identify large files with du -sh /var/lib/psa/dumps/* to see whether old backup archives are consuming space.
4. Delete or move old backups to free up space, or reconfigure the backup destination to a volume with more capacity.
5. Retry the backup once sufficient space is available.

As a general rule, ensure the backup destination has at least 1.5 times the size of the data being backed up as free space before starting.

Cause 2: Backup Destination Unavailable (FTP or Remote Storage)

If Plesk is configured to send backups to a remote FTP server or cloud storage bucket, the backup will fail if that destination is unreachable at the time the job runs. Network outages, expired credentials, and changed firewall rules are common culprits.

1. In Plesk, go to Backup Manager > Remote Storage Settings and confirm the host, port, username, and storage path are correct.
2. From the server via SSH, test connectivity to the remote backup server manually: ftp the-backup-server — replace the-backup-server with the actual hostname or IP address. If the connection is refused or times out, the network path is blocked.
3. Check whether the server’s outbound firewall permits connections to the FTP port (typically port 21, or 22 for SFTP).
4. Verify that the credentials have not expired or been changed on the remote storage service.
5. Once connectivity is confirmed, return to Plesk and use the Test Connection button in the Remote Storage Settings before retrying the backup.

Cause 3: MySQL Database Dump Failing

Large or corrupted databases are a frequent source of backup failures. Plesk uses mysqldump internally, which can time out on very large databases or fail entirely if a table is corrupted. Check the backup log for lines containing mysqldump errors or references to specific databases.

1. Connect to the server via SSH.
2. Check for corrupted tables across all databases: mysqlcheck -u root -p --all-databases --check
3. If corrupted tables are found, attempt a repair: mysqlcheck -u root -p --all-databases --repair
4. For a very large database that is timing out, test a manual dump to confirm it completes: mysqldump -u root -p database_name > /tmp/database_name.sql — replace database_name with the actual database name.
5. If the manual dump succeeds but the Plesk backup still times out, the Plesk backup timeout may need to be extended. This is configurable in Tools & Settings > Advanced Settings > Backup on some Plesk versions.

Cause 4: Permissions on the Backup Directory

Plesk runs its backup process as the psaadm user. If the backup directory or a custom storage path is owned by a different user or has restrictive permissions, Plesk will be unable to write backup files and the job will fail with a Permission denied error.

1. Connect via SSH and check the ownership of the default backup directory: ls -la /var/lib/psa/dumps/
2. If the directory is not owned by psaadm, correct it: chown psaadm:psaadm /var/lib/psa/dumps/
3. Set appropriate permissions: chmod 700 /var/lib/psa/dumps/
4. If you are using a custom backup path, apply the same ownership and permission corrections to that directory.
5. Retry the backup from Plesk.

Cause 5: Plesk Backup Service Not Running

If the Plesk Backup Manager service itself has stopped, no backups will run — scheduled or manual. Check the service status in Tools & Settings > Services Management and look for Plesk Backup Manager. If it shows as stopped, start it from the UI.

Alternatively, check and restart the service via SSH on systemd-based systems:

1. Check the current status: systemctl status psa-backup-manager
2. If stopped, start it: systemctl start psa-backup-manager
3. To ensure it starts automatically after a reboot: systemctl enable psa-backup-manager

Cause 6: Scheduled Backup Not Triggering

Scheduled backups can stop running without any obvious error if the scheduled task has been removed or if a previous failed backup left a lock file in place. Plesk uses lock files to prevent overlapping backup jobs, and a stale lock from a crashed backup will block all subsequent attempts.

1. In Plesk, go to Tools & Settings > Scheduled Tasks and confirm the backup task still exists and has a valid schedule.
2. Via SSH, check for lock files in the backup directory: ls /var/lib/psa/dumps/*.lock
3. Before removing a lock file, confirm no backup is currently running: ps aux | grep backup
4. If no backup process is active, remove the stale lock file: rm /var/lib/psa/dumps/*.lock
5. Trigger a manual backup from Plesk to confirm the scheduled task will now run correctly.

Manual Backup via SSH as a Workaround

If the Plesk UI backup continues to fail and you need an immediate copy of your data while you diagnose the root cause, you can trigger a full backup directly from the command line. This bypasses the Plesk UI entirely and writes a backup archive using the same underlying tool.

1. Connect to the server via SSH.
2. Run the following command to back up all domains: plesk bin pleskbackup domains all --output-file /tmp/manual_backup.tar
3. Once the command completes, verify the archive was created and is not empty: ls -lh /tmp/manual_backup.tar
4. If the file exists and has a non-zero size, the backup completed successfully. Transfer the file to a safe off-server location immediately.
5. To restore from this archive later, use: plesk bin pleskrestore --restore /tmp/manual_backup.tar -level server

This method is useful as an emergency workaround but should not replace resolving the underlying cause. A backup that only runs when triggered manually provides no protection against overnight failures or server events that occur outside working hours. Work through the causes above to restore reliable scheduled backups as quickly as possible.

Related articles: Plesk Troubleshooting Guide