How to fix JetBackup restore issues on Plesk

JetBackup restores can fail silently or leave a site broken when Plesk is running an NGINX reverse proxy in front of Apache or PHP-FPM. The restore process may complete without errors, but the site remains inaccessible due to proxy configuration conflicts, incorrect file ownership or a disconnected database.

Working through the steps below in order will resolve the most common causes of restore failures on Plesk with NGINX. Each section targets a specific failure point so you can identify where the problem lies.

Disable NGINX and test with Apache directly

When Plesk uses NGINX as a reverse proxy, NGINX handles incoming requests before passing them to Apache or PHP-FPM. A restored site may serve stale cached content or fail to route requests correctly if NGINX retains its previous configuration. Disabling NGINX for the domain forces traffic directly to Apache, which confirms whether NGINX is the source of the problem.

1. Log in to the Plesk admin panel.
   Navigate to your Plesk control panel and go to Websites & Domains.
2. Open the Apache & nginx Settings for the domain.
   Click the domain name, then select Apache & nginx Settings from the available options.
3. Disable the nginx reverse proxy.
   Locate the Proxy mode toggle and switch it off. This routes traffic directly to Apache without passing through NGINX.
4. Clear the NGINX cache.
   Scroll to the nginx section and click Clear cache if the option is available. Cached responses from before the restore can cause the old site to appear even after a successful restore.
5. Save and test the site.
   Click OK to save, then load the domain in a browser. If the site loads correctly, NGINX configuration was the cause.

If the site loads after disabling the proxy, you can re-enable it once you have confirmed the restored files and configuration are correct. If the site still does not load, continue to the next section.

Check PHP-FPM handler assignment

JetBackup restores the site files but does not always restore the PHP handler assignment. If the domain was using PHP-FPM before the restore, Plesk may revert it to a different handler, which can cause blank pages or 500 errors. Reassigning PHP-FPM to Apache corrects this.

1. Go to PHP Settings for the domain.
   In Websites & Domains, click the domain, then select PHP Settings.
2. Check the PHP handler.
   Confirm the Run PHP as setting matches what the site requires. For most Plesk setups, FPM application served by Apache is the correct option.
3. Apply the setting.
   Select the correct handler from the dropdown and click OK. Plesk will reconfigure the domain’s virtual host.

Once the handler is set, reload the site to confirm the error has cleared before moving on.

Verify file ownership and permissions

Restored files may have incorrect ownership if the backup was taken from a different server or user context. Apache and PHP-FPM run as the subscription’s system user in Plesk, so files owned by a different user will not be readable by the web server.

Connect to your server via SSH and run the following command to check the ownership of the restored site’s document root, replacing example.com with your domain:

ls -la /var/www/vhosts/example.com/httpdocs/

The files should be owned by the Plesk subscription user for that domain, typically matching the username shown in Websites & Domains under the domain’s subscription details. To correct ownership across the entire document root, run:

chown -R username:psacln /var/www/vhosts/example.com/httpdocs/

Replace username with the subscription’s system username. The group psacln is the standard Plesk client group. For directories, permissions should be 755 and for files 644. Correct these with:

find /var/www/vhosts/example.com/httpdocs/ -type d -exec chmod 755 {} \;
find /var/www/vhosts/example.com/httpdocs/ -type f -exec chmod 644 {} \;

Confirm the database connection

A restored site’s configuration file may reference a database user or password that no longer matches what exists in Plesk after the restore. This causes database connection errors, which typically appear as a white screen or a specific error message from the CMS.

1. Check the site’s database configuration file.
   For WordPress, this is wp-config.php in the document root. Confirm the values for DB_NAME, DB_USER and DB_PASSWORD match an existing database and user in Plesk.
2. Verify the database exists in Plesk.
   In the Plesk panel, go to Websites & Domains, click the domain, then select Databases. Confirm the database listed in the config file appears here.
3. Check the database user credentials.
   Click Manage Users next to the database. If the password does not match the config file, update it here or update the config file to match.

Once the credentials match, reload the site to confirm the database connection is working.

Run the Plesk repair command

If the site still does not load after the steps above, the Plesk repair utility can rebuild the domain’s configuration from scratch. This resolves issues where Plesk’s internal records are out of sync with the restored files, such as missing virtual host configuration or broken DNS zone entries.

Run the following command via SSH, replacing example.com with your domain name:

plesk repair all example.com -y

The -y flag confirms all repair actions automatically without prompting. Plesk will output a list of checks and repairs performed. Once the command completes, test the site in a browser.

Wrapping up

You have worked through the main causes of JetBackup restore failures on Plesk with NGINX: proxy and cache conflicts, PHP handler mismatches, file ownership problems, database credential mismatches and broken Plesk configuration. In most cases, one of these steps will bring the restored site back online.

If the site is still not loading after all steps above, check the Plesk error logs under Websites & Domains > Logs for specific error messages that may point to a remaining issue. You can also review our guide on using JetBackup to back up and restore sites and our article on fixing website error codes for further context.