Restoring a backup in Plesk is one of the most important tasks when you need to recover a website, mailbox, database, or a full subscription after a mistake, failed update, malware incident, or configuration problem. In a managed hosting environment, Plesk makes this process straightforward, but the exact steps depend on whether you want to restore the entire subscription, a single domain, selected files, a database, or mail data. Knowing how to use the built-in backup tools correctly can save time and help you avoid unnecessary downtime.
This guide explains how to restore a backup in Plesk, how to choose the right restore scope, what to check before and after recovery, and what to do if the backup is stored remotely or created by the server administrator. It is written for everyday hosting tasks in the Plesk control panel and is especially useful when you manage email accounts, logs, backups, and site data in a European hosting environment.
What Plesk backups can restore
Plesk backups can contain different types of data depending on how they were created. Before starting a restore, it helps to understand what may be included in the archive.
Common items included in a Plesk backup
- Website files and directories
- Databases such as MySQL or MariaDB
- Mail accounts, messages, and mail settings
- DNS settings
- Hosting configuration
- SSL/TLS certificates
- Cron jobs or scheduled tasks, depending on setup
- Application settings and some platform-specific data
Not every backup contains every item. For example, some backups are limited to a single subscription or domain, while others are full server backups created by the administrator. If you restore the wrong backup type, you may only recover part of the data you expected.
When to restore a backup in Plesk
You may need to restore a backup after:
- Accidental deletion of files or email messages
- A failed CMS update such as WordPress, Joomla, or Drupal
- A broken plugin or theme installation
- Incorrect DNS or hosting configuration changes
- Database corruption or content loss
- Malware cleanup or site compromise
- Migration issues after moving a site
- An unsuccessful deployment or code push
If the issue is limited to one area, such as one database table or one mailbox, it is usually better to restore only that part instead of the entire subscription. This reduces the risk of overwriting recent changes.
Before you restore a backup
Restoring a backup can overwrite newer data. A few checks before recovery help prevent avoidable loss.
Check the backup date and contents
Confirm when the backup was created and what it includes. In many cases, the most recent backup is not the best choice if it was taken after a problem already started. For example, if malware infected the site before the backup was created, restoring that archive will not solve the issue.
Create a fresh backup first if possible
If the current state of the site still has some useful data, create a new backup before restoring an older one. This gives you a fallback in case the restore does not produce the expected result.
Warn users about possible downtime
Full restores may temporarily affect the website, email flow, or database availability. If the site is active for customers, schedule the restore during a quieter period when possible.
Confirm storage location and permissions
Backups may be stored on the server, in remote storage, or in the Plesk backup repository. Make sure the account has permission to access the backup archive and enough disk space to unpack it.
How to restore a backup in Plesk as a subscription or domain owner
The exact interface can vary slightly by Plesk version and hosting plan, but the general flow is similar across installations.
Step 1: Open the backup manager
Log in to Plesk and open the subscription or domain you want to restore. Then go to the backup section, usually found under tools such as Backup Manager or Websites & Domains depending on the interface layout.
Step 2: Choose the backup archive
Select the backup you want to restore. Pay attention to:
- Backup creation date and time
- Backup type: full or incremental
- Whether it includes mail, files, databases, or configuration
- Whether it was created locally or stored remotely
If several backups are available, choose the one that best matches the state you want to recover.
Step 3: Select restore options
Plesk may allow you to restore:
- The entire subscription
- Only website files
- Only databases
- Only mail data
- Only selected configuration elements
If you only need one component, restore just that component. For example, if your website content is fine but the database was damaged, restoring only the database is often the safest approach.
Step 4: Decide how existing data should be handled
During restore, Plesk may ask whether to replace existing files and settings. In most cases, a restore overwrites current data in the selected scope. If newer files exist, they may be replaced by the backup version.
Review these options carefully before confirming. If you are unsure, restore to a test subscription or ask your hosting provider for guidance.
Step 5: Start the restore process
Confirm the selection and start the restore. Depending on the backup size, the process may take from a few minutes to a longer period. Large mailboxes or multi-gigabyte file archives will naturally take more time.
Step 6: Wait for completion and check the result
Do not close the browser or interrupt the process unless the interface specifically allows background operation. Once the restore finishes, verify that the website loads correctly, databases are working, and mail accounts can send and receive messages.
How to restore only specific parts of a backup
One of the most useful features in Plesk is the ability to restore a single component instead of the whole site. This is especially helpful for managed hosting customers who want to reduce downtime and avoid overwriting recent updates.
Restore only website files
Use this option if:
- Static files were deleted or replaced
- A theme or template caused layout issues
- Core application files were modified incorrectly
After restoring files, clear the site cache and test the homepage, contact forms, image loading, and navigation.
Restore only a database
This is useful when:
- The CMS content is broken
- Tables were deleted or corrupted
- Plugin or application data became inconsistent
After a database restore, check whether the application configuration still points to the correct database name, username, and password. If needed, update the config file before testing the site.
Restore only mail data
If your Plesk backup includes email, you may be able to restore:
- Specific mailboxes
- Mail messages
- Mailbox settings and quotas
This is useful when messages were deleted accidentally or a mailbox needs to be recovered after a migration issue. After restoration, verify IMAP/SMTP access from your email client.
Restore configuration only
Sometimes the content is fine, but the hosting configuration is not. In that case, restoring DNS or hosting settings only may be enough. This can help if a record was changed by mistake or a virtual host configuration was altered.
How to restore a backup from the server administrator side
In many hosting environments, especially managed hosting platforms, backups are created and controlled by the server administrator. If you do not see restore options in your Plesk account, the backup may be managed centrally.
In that case, the administrator can restore:
- Full server backups
- Subscriptions
- Individual domains
- Selected mailboxes or databases
If you are not sure which restore method applies to your plan, contact support and provide the following details:
- Domain or subscription name
- Approximate date and time of the problem
- What exactly needs to be restored
- Whether you want files, database, mail, or configuration
- Any relevant error messages
This helps the hosting team choose the correct restore point and reduce the risk of overwriting recent changes.
Restoring incremental backups in Plesk
Some setups use incremental backups instead of only full backups. An incremental backup contains changes made after the last full backup. This can save storage space and make backup jobs faster.
When restoring an incremental backup, Plesk typically uses the full backup as a base and then applies one or more incremental layers. Because of that, you should confirm that all related backup files are still available. If one layer is missing, the restore may fail or produce incomplete data.
For reliable recovery, avoid deleting older backup sets unless you are certain they are no longer needed and your retention policy allows removal.
How to restore a backup to a test environment first
When possible, restore the backup to a staging site or test subscription before applying it to a live site. This is particularly useful for larger websites, e-commerce stores, and business email environments.
Why testing is recommended
- It confirms the backup is valid
- It reduces the risk of breaking the live site
- It helps you check compatibility with plugins or updates
- It allows you to verify mail and database content safely
If your hosting plan supports staging or additional subscriptions, this is often the safest recovery workflow.
Common restore issues and how to handle them
The backup does not appear in Plesk
If the archive is missing, check whether you are looking at the correct subscription, storage location, or backup repository. Also confirm that the backup was not removed by retention rules or a cleanup task.
Restore fails because of insufficient disk space
Plesk needs enough free space to unpack and apply the backup. Free up space by removing unused files, old logs, or unnecessary archives, then run the restore again.
Mail restore completes, but messages are missing
Make sure the backup actually included the mailbox data. Some backups contain only configuration, not message content. It is also possible that mail was restored to a different mailbox name or account format.
The website shows an older version after restore
This usually means the backup date predates recent changes. Check the archive timestamp and verify whether the right restore point was selected. Clear application caches, CDN cache, and browser cache before testing again.
Database restore succeeds, but the site still does not work
After a database restore, the application may still need updated connection settings, corrected file permissions, or cache clearing. Review the configuration file and check the site logs for detailed error messages.
Best practices for backup and restore in Plesk
Good backup habits make recovery much easier. In a hosting environment, these practices are especially important for websites that handle customer data, lead forms, or business email.
- Keep regular automated backups enabled
- Store at least one backup copy off-server when possible
- Use a clear retention policy so important restore points are not deleted too early
- Test restores periodically on a staging environment
- Protect backup archives with proper access control
- Document which backup contains the last known good version of the site
- After major updates, create a fresh backup manually
If you manage several domains in Plesk, label critical restore points clearly. This can be especially helpful when you need to recover a single customer site or mailbox quickly.
Recommended restore workflow for hosting users
If you need a simple process to follow, use this order:
- Identify what is broken: files, database, mail, DNS, or full subscription
- Choose the latest backup created before the issue began
- Back up the current state if any useful data remains
- Restore only the component you need, if possible
- Check the site, mail, and database after completion
- Review logs if anything still does not work
- Confirm the issue is resolved before making further changes
This workflow helps reduce unnecessary data loss and makes the recovery process more predictable.
FAQ
Can I restore only one mailbox in Plesk?
In many cases, yes, if the backup contains mailbox data and the restore interface supports partial recovery. If the option is not visible, the backup may be controlled at the server level or may not include individual mailbox content.
Will restoring a backup delete my current website changes?
It can, depending on what you restore. A full restore may replace current files, database content, and mail data with the version stored in the backup. Always check the restore scope before confirming.
How long does a Plesk restore take?
Small restores may finish in a few minutes. Larger backups with many files, databases, or mailboxes can take longer. The exact time depends on backup size, server load, and storage location.
Can I restore a backup from an external storage location?
Yes, if the backup was configured to use remote storage and Plesk can access it. Availability depends on how the backup system was set up by the account owner or hosting provider.
What should I do if the restore fails?
Check the error message, confirm there is enough disk space, verify the backup archive is complete, and review whether the restore target is correct. If the issue continues, contact hosting support with the backup date, domain name, and exact error text.
Is it safe to restore a backup on a live site?
It is safe if you understand what will be overwritten. For important or high-traffic sites, restoring first to a staging environment is usually safer. If you must restore live, do it during a maintenance window and notify users if needed.
Conclusion
Restoring a backup in Plesk is a practical and reliable way to recover from site errors, email loss, database issues, and configuration problems. The key is to restore the correct backup, choose the right scope, and check the result carefully after the process completes. For hosting users working in a managed Plesk environment, a disciplined backup and restore routine is one of the best ways to keep websites and mail services stable.
If you regularly manage backups, logs, and email accounts in Plesk, it is worth testing your restore process before an incident occurs. A verified backup is far more valuable than an untested one, especially when fast recovery matters.