Restoring a website from a backup is one of the most important recovery tasks in hosting. Whether the problem comes from a failed update, accidental file deletion, malware, or a broken migration, a clean restore can bring the site back online quickly and safely. In a managed hosting or control panel environment such as Plesk, the exact steps may differ slightly depending on your setup, but the recovery workflow is usually the same: identify the correct backup, prepare the destination, restore the files and database, then verify that the website works as expected.
This guide explains how to restore a website from a backup in a practical way, including what to check before restoring, how to handle files and databases, and what to do after the restore is complete. It is written for hosting customers, site administrators, and support teams working with shared hosting, VPS, or managed hosting platforms.
When you should restore a website from backup
A restore is usually the fastest and safest option when the current site is damaged or unsafe. Common situations include:
- The website was hacked or infected with malware.
- A plugin, theme, or core update broke the site.
- Files were deleted or overwritten by mistake.
- The database became corrupted.
- A migration or deployment failed.
- You need to roll back to a known good version after a bad change.
In hosting environments, backups are often available through a control panel, backup manager, or server-side snapshot system. If you use Plesk, you may have access to account-level or subscription-level backups that can be restored without using command line tools.
Before you restore: important checks
Before starting the recovery process, take a few minutes to verify the backup and the target environment. This can prevent data loss and reduce downtime.
Confirm which backup you need
Not every backup is suitable for every recovery. Choose the one that best matches the point in time before the issue started. Ideally, select a backup created before:
- the site was compromised,
- the last failed update or deployment,
- the file deletion or database error,
- the introduction of corrupted content or configuration changes.
If multiple backups are available, prefer the most recent healthy version that predates the problem.
Check what the backup contains
A complete website backup should include both website files and the database. Depending on the application, it may also include:
- configuration files, such as wp-config.php or .env,
- media uploads,
- email accounts and mail data,
- cron jobs or scheduled tasks,
- SSL-related settings or application-specific configuration.
If your backup only includes files but not the database, the site may still be incomplete after restoration.
Decide whether to restore everything or only part of the site
In some cases, you may not need a full restore. For example:
- If only images were deleted, restore the uploads directory.
- If the database was damaged, restore only the database.
- If a theme update caused errors, restore only the site files or the affected directory.
Partial restores are useful, but they require care. Make sure the correct version of each component is restored.
Take a current backup first
Even if the site is broken, create a backup of the current state before you restore anything. This gives you a rollback option if the restore does not go as planned or if you need to recover a missing piece of content later.
In a hosting control panel, this may be available as a new manual backup, export, or snapshot. If the site is heavily compromised, isolate it first so the current infected files do not continue to spread.
How to restore a website from a backup in a hosting control panel
Most hosting platforms offer a backup restore feature in the control panel. The exact menu names differ, but the general process is similar.
1. Open the backup tool
Log in to your hosting control panel and locate the backup or restore section. In Plesk, this is commonly found under the subscription or domain tools, depending on the hosting plan and permissions.
2. Select the correct backup point
Choose the backup date and time that you want to restore. Pay attention to timezone differences and backup retention periods. If the backup list is long, use the available metadata to find the latest clean version.
3. Choose what to restore
Depending on the platform, you may be able to restore:
- website files only,
- database only,
- mail data,
- full subscription or account data.
For a standard website recovery, restore both files and the database. If you only restore one of them, the application may not load correctly.
4. Review restore options
Some control panels offer options such as:
- overwrite existing files,
- keep current data and merge,
- restore to a separate folder or staging location,
- restore only selected directories or databases.
For incident recovery, overwriting the damaged production files is usually required. However, if you are unsure, restore to a staging location first and test the result before replacing the live site.
5. Start the restore
Begin the restore operation and wait for it to complete. Larger sites can take several minutes or longer, especially if the backup includes media libraries, many database tables, or mail archives. Do not interrupt the process unless the control panel indicates that it is stuck or has failed.
6. Verify the restore status
Once the restore finishes, check the logs or status messages. A successful restore does not always mean the site is fully healthy, so you still need to test the application, database connection, and front-end pages.
How to restore website files and database separately
Many websites, especially CMS platforms such as WordPress, rely on both filesystem content and a database. If your backup and recovery workflow allows separate restoration, treat each component carefully.
Restoring website files
Website files usually include application code, themes, plugins, uploads, and configuration files. When restoring files:
- make sure you are restoring to the correct document root,
- check file permissions after the restore,
- avoid leaving old infected files in other folders,
- verify that the restored configuration matches the database and environment.
If you use Plesk or another hosting panel, file restore may be available through a file manager, backup tool, or subscription restore feature. If the website is dynamic, remember that file changes alone may not be enough to return the site to a working state.
Restoring the database
The database stores content, settings, product data, posts, users, and other dynamic information. When restoring the database:
- identify the correct database name,
- restore to the right database user and credentials,
- make sure the restored database replaces the broken one if required,
- check for character set or collation differences if the application shows errors.
If the database backup is from before a recent content update, that content may be lost. If possible, export the current database first so you can recover any missing entries later.
How to restore a WordPress site from backup
WordPress is one of the most common cases in hosting backup recovery. A full WordPress restore usually includes:
- the wp-content directory,
- the wp-config.php file if needed,
- the WordPress database,
- media uploads and any custom assets.
If your backup solution supports full account restore, that is often the simplest option. If not, restore the files and database manually through the control panel or your hosting panel’s database tools.
After restoring, check these items:
- the site homepage loads correctly,
- admin login works,
- permalinks resolve without errors,
- plugins and themes are compatible with the restored version,
- media files appear correctly,
- no malware warning or unexpected redirects remain.
How to restore a website in Plesk
In Plesk-based hosting, backup and restore is typically handled at the subscription or domain level. The exact interface may vary, but the workflow is generally:
- Log in to Plesk.
- Open the domain or subscription you want to recover.
- Go to the backup manager or backup menu.
- Select the backup archive and date.
- Choose whether to restore the full site or specific items.
- Confirm whether the restore should overwrite existing content.
- Start the restore and wait for completion.
If your hosting plan includes managed support, the provider may also be able to perform the restore for you. This can be helpful if the site is down, the panel is inaccessible, or you need assistance choosing the right backup point.
What to do after the restore
Restoring the backup is only part of the job. Afterward, validate the site carefully to make sure it is fully functional.
Test the front end
Open the website in a browser and check:
- homepage and key landing pages,
- navigation menus,
- images and media files,
- forms and checkout flow if applicable,
- mobile responsiveness.
Test the admin area
Log in to the CMS or application admin panel. Confirm that:
- authentication works,
- content is present and correct,
- plugins or extensions load properly,
- scheduled tasks or cron jobs are functioning.
Check for errors and security issues
Review error logs, access logs, and security alerts if available. Look for:
- database connection errors,
- file permission problems,
- missing assets,
- malware remnants,
- unexpected redirects or injected code.
If the restore was done after a security incident, change passwords and review all accounts, plugins, and admin users. A backup restore can return the site to a working state, but it does not automatically eliminate the reason the compromise happened.
Common problems during website restore
The restored site still shows a white screen or error
This usually indicates a PHP error, plugin conflict, version mismatch, or incomplete restore. Check the error log and verify that both the files and database were restored from the same era.
Images or uploads are missing
The backup may not have included the uploads directory, or the restore may have targeted the wrong path. Confirm that media files were included in the archive and that the restored directory structure is correct.
The database is restored but content is outdated
This means the backup was taken before recent changes. If the old version is necessary for recovery, you may need to re-enter missing content manually from other sources, such as exports, order records, or content drafts.
Permissions are wrong after restore
Incorrect ownership or permissions can prevent the site from loading or writing cache and upload files. In a hosting control panel, file permissions may need to be reset after recovery.
The site is restored but still infected
This can happen if the backup already contained malicious files or if other compromised files were left outside the restore scope. In this case, scan the site, compare files against a clean source, and rotate credentials immediately.
Best practices for safer restore procedures
To make future recovery easier, use a backup strategy that supports quick restore operations and minimal data loss.
- Keep multiple restore points, not just one backup.
- Use automated backups with clear retention policies.
- Test restores periodically, not only after an incident.
- Store at least one backup copy offsite or outside the primary hosting account.
- Document your restore steps for each site or application.
- Track which backups are full, incremental, or database-only.
- Protect backup access with strong authentication.
For hosting and managed hosting environments, restore planning should be part of the standard maintenance routine. A backup is only truly useful if you can restore it quickly and confidently.
FAQ
How long does it take to restore a website from backup?
The time depends on the site size, database size, backup type, and hosting platform. A small site may restore in a few minutes, while a large e-commerce site can take significantly longer.
Can I restore only part of a website?
Yes, if your backup tool supports partial recovery. You can often restore only files, only a database, or only specific directories. This is useful when only one component is damaged.
Will restoring a backup delete my current content?
It can, if the restore is configured to overwrite current files or replace the database. Always create a current backup first so you can recover any new content if needed.
Do I need to restore the database for WordPress?
In most cases, yes. WordPress content and settings are stored in the database, so restoring files alone is usually not enough for a complete recovery.
What should I do if the backup restore fails?
Check the restore log, verify available disk space, confirm that the archive is not corrupted, and make sure you have the correct permissions. If you are using managed hosting, contact support with the backup date and error details.
Can I test a restore before putting it live?
Yes. The safest approach is to restore into a staging environment or separate directory first. This allows you to confirm that the site works before overwriting the live version.
Conclusion
Restoring a website from a backup is one of the most reliable ways to recover from outages, failed updates, or security incidents. The key is to choose the right backup point, restore the correct components, and verify the result carefully. In hosting environments with a control panel such as Plesk, the process is often straightforward, but it still requires attention to files, databases, permissions, and post-restore checks.
A well-planned backup and recovery strategy reduces downtime, protects content, and makes incident response much easier. If you restore regularly tested backups and keep clear recovery steps for each site, website recovery becomes a controlled process rather than an emergency.