Configuring Reliable Automated Backups in Plesk

Plesk's Backup Manager makes it easy to schedule a backup and forget about it, which is exactly the problem. A backup that runs on schedule but is never verified, never sent offsite, and never checked for failure is a false sense of security rather than a real safety net. Configuring backups properly in Plesk takes a few extra steps beyond the default setup, and those steps are what actually make the difference during a real recovery.

Understand the two backup levels Plesk offers

Plesk distinguishes between server-level backups, covering the entire server's configuration, all domains and all accounts, and domain-level backups, covering a single website's files, databases and mail. Most production setups need both: server-level backups for full disaster recovery, and domain-level backups for fast, targeted restores when a single site has a problem.

plesk bin pleskbackup server --output-file=/backups/server-full.tar --description "Nightly full backup"
plesk bin pleskbackup domain example.com --output-file=/backups/example-com.tar

Configure the schedule through Backup Manager, not just cron

Plesk's own Backup Manager, under Tools & Settings, handles scheduling natively and integrates with the panel's own logging and notification system, which a raw cron job calling pleskbackup directly does not. Set the schedule to run during a genuine low-traffic window, since a full backup does place real load on disk I/O while it runs.

For domain owners managing their own backup schedule through their control panel, the same scheduling options are available at the domain level under their own Backup Manager view, letting you delegate routine backup management without giving domain owners server-level access.

Send backups to remote storage, not just local disk

A backup stored on the same physical server it protects is not a backup in any meaningful disaster recovery sense, since a hardware failure, ransomware event, or accidental deletion at the server level takes the backup down with the data it was meant to protect.

Plesk's Backup Manager supports remote storage destinations directly, including FTP, and cloud storage backends depending on your Plesk version and installed extensions. Configure this under Tools & Settings, Backup Manager, Remote Storage Settings, and confirm a test backup actually reaches the remote destination successfully rather than assuming the configuration is correct because no error appeared during setup.

For environments where the built in remote storage options do not cover your preferred provider, a scheduled task that syncs the local backup directory to external object storage after each backup completes closes the same gap:

0 4 * * * aws s3 sync /backups s3://your-plesk-backup-bucket --storage-class STANDARD_IA

Set up failure notifications, not just success confirmations

A backup schedule with no failure alerting will fail silently, often for weeks, before anyone notices during an actual restore attempt. Plesk can be configured to send notification emails on backup completion or failure under the Backup Manager settings. Confirm this notification actually reaches an inbox someone monitors, not an address nobody reads, and treat a missing routine notification with the same suspicion as an explicit failure notice, since a backup job that silently stopped running produces neither.

Exclude what does not need backing up

Full server backups that include large, easily regenerated files, such as cached files, session data or large log archives, take longer to run and cost more to store than necessary. Plesk's Backup Manager allows excluding specific content types and file patterns from the backup scope. Reviewing what is actually included periodically keeps backup windows reasonable as sites grow, rather than discovering years later that a large chunk of every backup has been cache files that add no recovery value.

Testing a restore, not just trusting the backup exists

The step most Plesk backup configurations skip entirely is an actual test restore. A backup file that exists and completed without error is not proof it can be restored correctly, particularly for large or complex sites with multiple databases.

plesk bin pleskrestore --restore /backups/example-com.tar -level domain

Run this against a throwaway domain or a staging environment, never directly overwriting a live production site during a test. Confirm the restored site loads correctly, the database connects and contains expected data, and mail configuration, if included, restored properly. Doing this quarterly, at minimum, catches corruption or configuration drift long before an actual emergency forces you to discover it under pressure.

Retention: how long backups actually need to live

A common mistake is keeping either too few backup generations, leaving no recovery point before a problem that went unnoticed for a while, or too many, consuming storage indefinitely without a clear reason. A reasonable default is daily backups retained for one to two weeks, combined with a weekly backup retained for one to three months, giving both a short-term rollback window and a longer-term recovery point for issues discovered later.

find /backups -name "*.tar" -mtime +14 -delete

Putting it together

A reliable Plesk backup setup combines both server and domain level backups, sends copies offsite automatically, alerts on failure rather than only confirming success, and includes a scheduled test restore rather than assuming the backup file itself is proof of recoverability. Each piece is straightforward on its own; the difference between a working safety net and a false sense of security is whether all of them are actually configured together.

iServerSupport provides Plesk server management including backup strategy design, remote storage configuration and scheduled restore verification, so a backup failure is caught immediately rather than discovered during an actual emergency.