Backups are one of the most important parts of server and website maintenance in Plesk. Whether you manage a single site or multiple hosting accounts, having a reliable backup and restore process helps you recover quickly from accidental changes, broken updates, malware cleanup, or failed migrations. In a hosting environment, this is especially important because data loss can affect websites, mailboxes, databases, and application files at the same time.
Plesk includes built-in backup tools that let you create full or incremental backups, store them locally or remotely, and restore content at the server, subscription, or individual domain level. If you are using a managed hosting platform, understanding how Plesk backups work will help you choose the right backup method, reduce downtime, and avoid restoring the wrong data by mistake.
Why backups matter in Plesk hosting environments
Plesk hosts are typically used for websites, email services, databases, DNS zones, and file-based applications. A backup in this environment is more than just a copy of website files. It may include:
- Website files and application code
- Databases such as MySQL or MariaDB
- Email accounts and messages
- DNS records
- SSL/TLS settings and certificates in some backup types
- Scheduled tasks and certain configuration data
This is why a Plesk backup strategy should be part of every hosting setup. It protects against human error, extension issues, corrupted updates, and software conflicts. It also helps during site migrations or when you need to roll back to a stable version after deployment.
Types of backups in Plesk
Plesk supports several backup approaches. The right choice depends on how often your data changes, how much storage you have, and how quickly you need to restore.
Full backups
A full backup contains all selected data at the time the backup is created. This is the simplest type to restore because it includes everything needed to return the subscription or server to a previous state.
Full backups are ideal when:
- You want a complete recovery point
- Your environment changes infrequently
- You are preparing for a major update or migration
Incremental backups
An incremental backup stores only the changes made since the last backup. This saves disk space and can reduce backup time, but restore operations may depend on a chain of previous backups. If one backup in the chain is missing or damaged, recovery can become more complicated.
Incremental backups are useful when:
- You generate backups frequently
- You need to conserve storage
- Your hosting environment receives regular content updates
Manual and scheduled backups
You can create backups manually whenever needed, or schedule them to run automatically. In a managed hosting context, scheduled backups are usually the safer option because they reduce the risk of forgetting to create a recent restore point.
Manual backups are helpful before:
- Plugin or CMS updates
- Theme changes
- Configuration changes
- Server-level adjustments
How to create a backup in Plesk
The exact screen layout may vary slightly depending on your Plesk version and user role, but the backup workflow is usually similar. You can create backups for an entire server, a subscription, or a single domain if permissions allow it.
Create a backup from the subscription or domain level
- Log in to Plesk.
- Open the relevant subscription or domain.
- Go to Files, Backup Manager, or Websites & Domains depending on the interface.
- Click Back Up or Create Backup.
- Choose whether to back up:
- All content
- Only website files
- Only databases
- Only mail data, if available
- Select whether the backup should be full or incremental.
- Choose a destination, such as local storage or remote storage if configured.
- Decide whether to include protected data like passwords or other credentials, if the option is available and appropriate.
- Start the backup and wait for it to finish.
For production websites, it is usually best to create a full backup before making major changes. If your site includes a database-driven application such as WordPress, Joomla, Drupal, or a custom PHP app, make sure the database is included.
Create a backup from the server level
Server-level backups are managed by administrators and typically cover multiple subscriptions. This is useful for hosting providers or internal sysadmins who need a broader recovery point.
Common use cases include:
- Protecting an entire hosting server
- Preparing for system upgrades
- Moving to new hardware
- Restoring multiple accounts after an incident
To create a server-level backup, open the server administration tools in Plesk, navigate to the backup section, and configure the scope, storage, and schedule as needed.
How to schedule automatic backups in Plesk
Automatic backups are one of the most practical features in Plesk because they reduce operational risk and keep restore points current without manual intervention. For hosting customers, a good backup schedule often matters more than a backup taken once in a while.
Recommended backup schedule
A common approach is:
- Daily incremental backups for active websites
- Weekly full backups
- Additional manual backups before deployments or updates
If your website changes less frequently, a weekly full backup may be enough. If you run an e-commerce site or a busy content platform, more frequent backups may be necessary.
Setting a backup schedule
- Open the backup settings in Plesk.
- Choose the subscription, domain, or server scope.
- Select Scheduled backup or a similar option.
- Define how often the backup should run.
- Choose the backup type and retention policy.
- Set the time window to avoid peak traffic hours if possible.
- Save the schedule.
When possible, schedule backups during periods of low activity. This can reduce the performance impact on busy servers and may lower the risk of contention with application traffic or database writes.
Where to store Plesk backups
Backup storage location is just as important as backup creation. If backups are stored only on the same server that hosts your websites, a hardware failure or storage issue could affect both the live data and the backup copy.
Local storage
Local storage is easy to use and fast to restore from. However, it is not ideal as the only backup destination because it lives on the same machine or attached storage.
Use local storage for:
- Quick short-term restore points
- Operational convenience
- Temporary backups before maintenance
Remote storage
Remote storage improves resilience because the backup copy is stored off the main hosting server. Depending on your Plesk setup, this may include remote FTP/SFTP storage or cloud-based storage options supported by extensions or platform configuration.
Remote storage is recommended for:
- Disaster recovery planning
- Protecting against server-level incidents
- Longer retention periods
For managed hosting environments, a combination of local and remote backups is often the most reliable option.
How to restore a backup in Plesk
Restoring a backup in Plesk allows you to return a website, subscription, or server component to a previous state. The restore process is powerful, so it should be done carefully, especially if the current live data is newer than the backup you are restoring.
Restore a backup from the Backup Manager
- Log in to Plesk and open the relevant backup tool.
- Locate the backup you want to restore.
- Review the backup date, scope, and contents.
- Click Restore.
- Choose whether to restore all data or only selected parts.
- Confirm the restore action.
Depending on the backup type, you may be able to restore only files, only databases, only mail, or the full backup set. This is useful if only one part of the site is affected.
Restore a backup at the subscription level
Subscription-level restores are useful when you want to recover an entire customer account, including the domains, mailboxes, and data associated with that subscription. This option is common in hosting environments where a single customer owns multiple sites or applications.
Before restoring, verify:
- The correct subscription is selected
- The backup date matches the desired recovery point
- Any newer changes since that date are understood and accounted for
Restore only specific content
Sometimes a full restore is unnecessary. If you only need to recover a deleted file or a damaged database table, restoring a smaller scope is often safer and faster.
Examples include:
- Restoring a single website directory
- Recovering one database after a bad query
- Restoring email for a specific mailbox
This targeted approach reduces the chance of overwriting unrelated changes.
Best practices before restoring
Restoration is not just a technical action; it is also a change-management step. In hosting environments, a restore may overwrite live work, so it is important to prepare first.
Check the backup date and content
Make sure the backup actually contains the data you need. A backup that is too old may restore the site but remove recent content, orders, or emails.
Create a fresh backup of the current state
Before restoring, create a backup of the current live environment if possible. This gives you a rollback option in case the restore does not produce the desired result.
Notify stakeholders if needed
If the site is active and used by a team or customers, inform relevant users before restoring. This is especially important for e-commerce systems, membership portals, and transactional applications.
Check dependencies
Some applications depend on both files and databases. Restoring only one part may create version mismatches. For example, restoring files from an older backup while keeping a newer database can break a CMS or plugin setup.
Common backup and restore scenarios in Plesk
Website update failed
If a CMS update causes errors or a blank page, restore the backup taken before the update. If the issue is limited to files, you may not need to restore the database.
Accidental file deletion
If a developer or user deletes critical files, use the backup to recover the affected directory. This is one of the fastest uses of the Plesk backup system.
Database corruption
When a database becomes corrupted or data is overwritten, restoring the database from a known good backup can return the application to a working state.
Migration rollback
If a site migration or server move fails, a backup can be used to return the environment to the original server or to recover content on the destination server.
Backup limitations and things to watch for
While Plesk backups are very useful, they do have limitations. Knowing them helps prevent surprises during recovery.
- Large backups may take time to complete or restore.
- Incremental backup chains can make recovery more complex.
- Not all custom server settings are always included in every backup type.
- External services, such as third-party APIs or external object storage, may not be covered.
- Restoring a backup can overwrite newer live data.
If your hosting platform uses custom configurations, always test the restore process in a staging environment when possible.
Troubleshooting backup and restore issues
Backup fails to complete
Possible causes include insufficient disk space, permission issues, or timeouts during large data transfers. Check available storage and review Plesk logs for errors.
Restore takes too long
Large archives, heavy databases, or slow remote storage can increase restore time. If available, restore only the necessary parts of the backup rather than the full set.
Missing data after restore
This often means the backup did not include the affected item, or the selected backup date was older than expected. Verify the contents of the archive before restoring.
Permission errors
In shared hosting or restricted subscription environments, you may not have the required rights to restore certain content. In that case, contact the hosting provider or the server administrator.
Backup strategy recommendations for hosting customers
A reliable Plesk backup strategy should balance recovery speed, storage use, and operational simplicity. For most hosting environments, the following approach works well:
- Use scheduled backups instead of relying only on manual backups.
- Keep at least one off-server copy of your backups.
- Test restores periodically, not only backups.
- Retain several recovery points so you can roll back beyond a single day.
- Take a manual backup before major site changes.
If you manage client websites on a hosting platform, document which backups belong to which subscription or domain. Good naming and retention policies make recovery much faster during an incident.
FAQ
How often should I back up a website in Plesk?
For most active websites, daily backups are a good baseline. Busy e-commerce sites or frequently updated portals may need more frequent backups. Static or low-change sites may be fine with weekly full backups.
Can I restore only one database from a Plesk backup?
Yes, in many cases you can restore specific components such as a database, files, or mail data instead of the entire backup. The exact options depend on the backup type and your permissions.
Should backups be stored on the same server?
They can be, but it is safer to keep at least one copy off the server. Remote storage protects you if the hosting server has a hardware failure or a major incident.
Does Plesk backup include email?
It can, depending on the backup scope and settings. If you need mailbox messages and mail account data, verify that email content is selected before creating the backup.
Can I restore a backup without downtime?
It depends on the scope of the restore. Small file restores may have minimal impact, while full subscription or server restores can cause temporary service interruption. For important sites, plan the restore during low-traffic hours if possible.
What should I do before restoring a backup?
Check the backup date, create a fresh backup of the current state if possible, and confirm that you are restoring the correct subscription or domain. This helps prevent accidental data loss.
Conclusion
Backups and restores in Plesk are essential tools for maintaining reliable websites and hosting services. A well-planned backup strategy protects files, databases, email, and configuration data, while a careful restore process helps you recover quickly from errors, failed updates, and accidental changes.
For the best results, use scheduled backups, keep off-server copies, and verify restore procedures before an incident happens. In a hosting or managed hosting environment, that preparation can save time, reduce downtime, and protect business-critical data.