Restoring a website from backup is one of the safest ways to recover after a failed update, accidental deletion, broken plugin, corrupted files, or a malware incident. In a hosting environment, the exact steps depend on where your backup is stored, whether you are using a control panel such as Plesk, and whether you need to restore only files, only the database, or the full website. The most important rule is to restore to a clean and verified state, not just to copy old data back without checking what caused the problem.
If your website is hosted on a managed hosting platform, backups are often available as scheduled restore points. In a typical Apache-based hosting environment, a website usually consists of web files, a database, and configuration values such as PHP version, cron jobs, and permissions. A proper restore must take these into account, especially if you are recovering after malware or a site crash. The steps below explain how to restore safely and minimize downtime.
When you should restore from backup
A backup restore is usually the fastest recovery method when the website has been damaged by a change that cannot be quickly reversed. Common cases include:
- Failed CMS or plugin updates
- Accidental deletion of files, images, or content
- Database corruption after an interrupted migration
- Broken theme changes or custom code deployment
- Malware infections or unauthorized file modifications
- Hosting-side issues that affected application files or databases
If the website was hacked, do not restore blindly and assume the problem is solved. If the compromised files or database are restored without cleanup, the infection may come back immediately. In security-related incidents, restore only after identifying the cause and confirming that the backup predates the compromise.
Before you start: check what needs to be restored
Most websites are made of several parts, and each one may need a different restore method. Before restoring, identify what is broken:
Website files
These include HTML, PHP, CSS, JavaScript, images, uploads, themes, and application files. If the site shows missing pages, broken layout, or a white screen, the files may be the issue.
Database
WordPress, Joomla, Drupal, Magento, and many custom applications store content and settings in a database. If posts are missing, logins fail, or the site shows database errors, you may need to restore the database.
Configuration and environment
Sometimes the problem is not the site content itself but a server-level setting, such as PHP version, file permissions, .htaccess rules, or a broken cron job. A backup restore may help, but you should still verify these settings afterward.
Email and related services
If your hosting backup includes mailboxes or application-related email data, confirm whether those also need to be restored. Website backups and email backups are often separate.
Choose the correct backup point
The best restore point is usually the most recent backup taken before the issue started. However, newer is not always better. If malware has been active for several days, a recent backup may already contain the infection.
When selecting a restore point, look for:
- The last known good version of the site
- A backup created before a failed update or deployment
- A backup that includes the correct files and database version
- Evidence that the backup completed successfully
If your hosting platform keeps multiple snapshots or restore points, compare the backup timestamps with the time the problem began. This is especially useful after a plugin update, theme change, or migration.
Restore a website from backup in Plesk
If your hosting plan uses Plesk, website restoration is usually done from the backup manager. The exact menu names can vary slightly by version, but the process is generally similar.
Step 1: Log in to Plesk
Sign in to your Plesk control panel using an account with the necessary permissions. If you manage multiple domains, select the correct subscription or domain first.
Step 2: Open the backup manager
Go to the backup section for the domain or subscription. You should see available backups, dates, sizes, and possibly the type of data included in each one.
Step 3: Select the correct restore point
Choose the backup taken before the issue started. If you are recovering from a malware incident, use a backup that predates the compromise.
Step 4: Choose what to restore
You may be able to restore:
- All data
- Website files only
- Databases only
- Mail data only
- Selected files or directories
For a full site outage, restoring all data is usually the simplest option. For a partial issue, such as a broken theme or a corrupted database, restore only what is needed to reduce the chance of overwriting recent content.
Step 5: Confirm overwrite behavior
Restoring a backup often replaces current files and database contents. Read the confirmation carefully. If you have made changes since the backup, they may be lost. When possible, export or copy current data before starting the restore.
Step 6: Start the restore and wait for completion
Depending on the size of the site, the process may take several minutes. Do not close the browser too early if the control panel requires the session to remain active. If the backup is large, monitor progress and check for errors after completion.
Step 7: Test the website
After the restore completes, verify that the homepage loads, login works, key pages are available, forms submit correctly, and images display properly. If the site uses caching, clear both application cache and any hosting cache before testing again.
Restore website files from backup
If only the files were damaged, you can restore the file system without touching the database. This is useful when the website layout is broken, files were deleted, or malicious code was injected into theme or plugin files.
Typical file restore steps include:
- Open the backup archive or file restore tool in your control panel
- Locate the document root, usually
httpdocs,public_html, or a similar directory - Restore the required folders, such as themes, uploads, or application core files
- Check permissions after restore so Apache and the application can read the files correctly
If you are using a CMS like WordPress, it is often safer to restore the core files and theme files first, then compare the uploads directory separately. Restoring user-uploaded media can be important, but you should avoid overwriting newer content unless you have confirmed it is safe.
Restore a database from backup
Database restore is essential when content, settings, or login data have been lost. This can happen after a bad import, a failed update, or a corrupted table.
Before restoring the database, consider the following:
- Back up the current database, even if it is damaged
- Confirm the database name and table prefix used by the application
- Check whether the restored database must match a specific file version
- Make sure application credentials are still valid
In Plesk, database restore is usually available through the backup manager or database tools. In other environments, you may need to import a SQL dump using phpMyAdmin, command line tools, or the hosting platform’s restore function.
After restoring the database, test the front end and admin area. If the site returns a database connection error, the issue may be incorrect credentials in the configuration file, not the restored data itself.
Restore only selected files or folders
Sometimes the best solution is a partial restore. This is common when only one plugin folder is broken, a media folder was deleted, or a single configuration file was changed incorrectly.
Use a selective restore when:
- You want to recover one directory without replacing everything else
- You need to preserve recent content changes
- You are restoring a single deleted file
- You want to compare damaged files with known good versions
Partial restores are especially useful on managed hosting platforms where restore points can be mounted or browsed. Always check file timestamps and names carefully to avoid overwriting unrelated content.
How to restore after malware or hacking
Recovering from malware requires more than a normal rollback. A clean backup can help, but only if the attack is removed first and the restored data is verified.
Recommended recovery order
- Put the site into maintenance mode or restrict access if possible
- Change passwords for hosting, control panel, CMS admin, database, and FTP/SFTP
- Scan the current files and identify suspicious changes
- Choose a backup from before the compromise
- Restore clean files and database content
- Update the CMS, plugins, and themes after restoring
- Check logs for repeated access attempts or reinfection indicators
If you restore a backup that still contains a vulnerable plugin or outdated component, the site may be infected again. After the restore, apply security updates and remove unused extensions. In some cases, you may need to compare the restored site with a security scan to ensure no hidden backdoors remain.
Restore after a failed update or deployment
Failed updates are one of the most common reasons to restore a website. A plugin update may break the layout, a theme change may cause errors, or a code deployment may make the site unavailable.
Before restoring, check whether the issue can be fixed by reverting just the change that caused it. If not, use the nearest known good backup. After recovery, note what changed so the same update can be tested more safely next time.
Useful checks after a failed update restore include:
- PHP compatibility with the current CMS version
- Whether the theme or plugin version is still supported
- Whether cache layers need to be cleared
- Whether custom code changes were lost and need to be reapplied
What to verify after the restore
A successful restore is not complete until the website is tested. Use a practical checklist:
- Homepage loads without errors
- Main pages and category pages open correctly
- Login and password reset work
- Forms submit and send notifications
- Images, styles, and scripts load normally
- Database-driven content appears complete
- Admin area is accessible
- Scheduled tasks or cron jobs still run
- SSL certificate and redirects behave as expected
If the site uses a CDN, reverse proxy, or server cache, purge it after restore so visitors do not see outdated or broken content.
Common problems during restore
Backup file is missing or incomplete
If the backup does not contain all expected data, check whether the backup job was configured to include files, databases, and mail separately. Some backups only include one part of the site.
Restore fails because of size or timeout
Large sites may fail if the restore exceeds execution limits. In that case, use the hosting platform’s native restore feature instead of manual upload, or restore the database and files separately.
Database import fails
This may happen because of a corrupted dump, wrong character set, or database size limits. Verify the file integrity and confirm that the destination database exists and has the correct permissions.
Website still shows the old error after restore
Clear application cache, server cache, browser cache, and any CDN cache. Also verify that the restored files are in the correct directory and that the web server is using the expected document root.
Permissions are wrong after restore
Incorrect file ownership or permissions can break uploads, logins, and updates. Make sure the web server user can read the files and write only where necessary.
Best practices for safer website recovery
Good backup habits make restoration much faster and less risky. For hosting environments in Europe, where reliability and data protection are often important, a structured backup policy is especially useful.
- Keep multiple restore points, not just one backup
- Test restores periodically on a staging copy when possible
- Store backups separately from the live site
- Record what each backup includes: files, database, mail, or full account
- Document the restore process for your CMS and control panel
- Use access control so only authorized users can restore backups
- Update software after recovery to reduce repeat incidents
It is also a good idea to keep a short incident note that records when the issue started, what backup was used, and what was restored. This helps if you need to troubleshoot later.
Frequently asked questions
Will restoring a backup delete newer changes?
Yes, it can. Restoring files or a database usually replaces the current version. If you made changes after the backup date, export them first if they are important.
Can I restore only one deleted page?
If the page content is stored in the database, you may need to restore the relevant database table or a full database backup. If it is a static file, you may be able to restore only that file from the backup archive.
What is the safest restore point after malware?
Use the last backup made before the infection started, not the most recent backup. If you are unsure, inspect several restore points and choose the cleanest one.
Should I restore files or database first?
It depends on the problem. For a visual or code issue, restore files first. For missing content or login problems, restore the database first. For a full outage, restoring both together is usually best.
Do I need technical skills to restore a website from backup?
Basic restores can often be done from a control panel such as Plesk. However, if the site uses custom code, large databases, or has been hacked, a more careful recovery process may be needed.
What if my backup is older than I expected?
Choose the newest backup available, but check whether it contains the problem. If the latest good backup is old, restore it and then manually reapply recent content changes if possible.
Conclusion
Restoring a website from backup is the most reliable recovery method after failed updates, deletions, corruption, or malware incidents. The key is to restore the right data, from the right point in time, and then verify that the site is clean and functional. In a managed hosting or Plesk-based environment, the process is usually straightforward, but careful selection of files, databases, and restore points makes the difference between a quick recovery and a repeated incident.
If you handle the restore methodically, test the site afterward, and update the affected software, you can bring the website back online with minimal downtime and lower risk of future problems.