If you have restored a Java hosting backup in Plesk and need to bring your application back online, the process is usually straightforward: recover the files, confirm the Tomcat or private JVM service settings, and verify that the application context, database connection, and logs are all in place. In a managed hosting environment, a backup restore is only part of the job. For a hosted Java application, you also need to make sure the runtime configuration matches the restored code and that any custom service settings are still valid.
This guide explains how to restore a hosted Java application from backup in Plesk for UK hosting customers using a Java hosting setup with My App Server. It covers both the file restore process and the checks you should perform after the restore so your WAR, JSP, or servlet-based application runs correctly again.
Before you restore the Java application
Before starting, confirm what the backup contains. For a hosted Java application, a complete recovery may need more than just application files. Depending on how your site is built, the backup may include:
- the application source or deployed files
- a WAR file or exploded application directory
- Tomcat configuration files
- custom JVM or service settings
- database dumps or credentials
- static assets, uploads, and logs
If you are using ITA’s My App Server extension in Plesk, remember that the Java service is managed separately from regular website files. This means a restore of files alone may not restart the application automatically or may not restore a custom Java version, Tomcat instance, or private JVM configuration.
It is also a good idea to note the following before restoring:
- the domain name or subdomain where the app runs
- the application context path
- the Java version in use
- the Tomcat version in use
- the database name and user
- any scheduled tasks or cron jobs tied to the app
Restore the backup in Plesk
Most Plesk environments let you restore backups from the backup manager. If your hosting provider gives you a full account backup, this is usually the fastest way to recover the site files and related hosting data.
Step 1: Open the backup manager
Sign in to Plesk and go to the subscription or domain where the Java application is hosted. Open the backup section and locate the available backups. Depending on your setup, you may see a full subscription backup, a domain-level backup, or a custom backup file.
Step 2: Choose the correct restore point
Select the backup created before the issue occurred. If the application was broken after a deployment, code change, or file deletion, choose the most recent known-good restore point. If the problem relates to corrupted data, make sure the backup includes the database snapshot as well.
Step 3: Restore the required items
During restore, choose the items you need:
- website files
- databases
- mail data, if relevant
- configuration files, if included in the backup type
For a hosted Java application, the most important parts are usually the application files and the database. If your deployment uses a WAR file, confirm that the restored WAR is placed in the correct deployment location. If you use an exploded directory, ensure the full app directory is restored with the expected structure.
Step 4: Wait for the restore to complete
Large Java applications may take some time to restore, especially if there are uploaded files or a database backup included. Do not interrupt the process. Once the restore finishes, review any restore summary or warnings shown by Plesk.
Check the My App Server service after restore
After restoring files, the Java service should be checked separately. In ITA’s hosting environment, My App Server allows you to manage your own Apache Tomcat or private JVM inside a shared hosting account. If the service is stopped or the wrong version is active, the application may restore successfully but still fail to load.
Step 1: Open the service control area
In Plesk, open the My App Server extension or the Java service management area. Check whether the application server is running. If service control is available, confirm that the correct instance is started for the domain.
Step 2: Verify the Java and Tomcat version
If the backup was created when the app was running on a specific Java version, restore and use the same or a compatible runtime. A mismatch between Java versions is a common reason for startup errors after a restore. The same applies to Tomcat: if the app was built for a certain Tomcat release, make sure the restored environment matches it as closely as possible.
Step 3: Confirm the service path and deployment directory
Make sure the service still points to the correct deployment path. If the restore placed the files in a different directory or the account structure changed, Tomcat may not find the application. Check whether the WAR file, context configuration, and application root are still aligned.
Restore the database if your Java app uses one
Many Java applications depend on MySQL, MariaDB, PostgreSQL, or another database. If the backup includes a database dump, restore it before testing the app in detail. A successful file restore with a missing database will often result in errors, empty pages, login failures, or connection exceptions.
Common database recovery checks
- restore the correct database dump
- check that the database user still exists
- confirm the password in the application configuration
- verify the hostname and port in the JDBC string
- check character set and collation if the app stores multilingual content
If the database credentials changed after the backup was taken, update the application configuration file before starting the service again. For example, this may be in a properties file, XML configuration, or environment-specific settings file used by the application.
Restore application configuration carefully
Hosted Java applications often store critical settings outside the codebase. If your backup includes configuration files, review them before putting the application back into production. Some values may need updating if the environment has changed since the backup was made.
What to check in configuration files
- database connection string
- session or cache settings
- file upload paths
- email delivery settings
- API keys or external service endpoints
- file permissions or temp directory paths
If the restored app uses environment-specific settings, make sure the backup did not overwrite newer values that are required on the current server account. In a managed hosting setup, a restore should bring back the app state, but some local values may need to be adjusted manually.
Restart the Java application
Once the files, database, and configuration are restored, restart the Java service from the My App Server control area or restart Tomcat if the interface provides that option. A restart helps reload the deployment and apply the restored configuration.
If the application was restored to the correct place but still does not load, a restart is often the first action to try. This is especially true for WAR deployments, where Tomcat needs to re-scan the application and rebuild the working directories.
Test the restored application
After the restore, test the application in a structured way instead of only checking the homepage. A Java app may appear online while specific functions are still broken.
Recommended test list
- open the main URL in a browser
- test login and logout
- check form submission
- verify file uploads and downloads
- test database-driven pages
- confirm API calls or integrations
- review admin pages or secured endpoints
If the application has scheduled background tasks, confirm they still run after the restore. Also check whether the app creates files in the expected location and has the permissions needed to write to uploads, temp, or cache directories.
Use logs to find restore-related problems
If the restored Java application does not start correctly, logs are the fastest way to identify the issue. In Plesk, check the web server logs, Tomcat logs, and application logs if they are available. Since this article belongs to the logs and tools area of Plesk, logs should be one of your first troubleshooting steps after a restore.
Look for these common messages
- port already in use
- class not found
- JDBC connection failed
- permission denied
- unsupported Java version
- context path not found
- deployment failed
Tomcat startup logs can reveal whether the application deployed correctly, whether the WAR unpacked successfully, and whether any servlet or JSP errors happened during startup. If the application is restored but fails immediately, the log usually shows the reason.
Common restore scenarios for hosted Java applications
Restoring a WAR file
If your app is deployed as a WAR, restore the WAR into the correct deployment folder and restart Tomcat. If the application exploded automatically before, verify that the unpacked directory is created again after restart.
Restoring an exploded application
If your app uses an exploded directory, restore the full directory tree, not just a few selected files. Missing folders such as WEB-INF or resource directories can prevent deployment or cause runtime errors.
Restoring only application data
Sometimes you only need to restore uploads, exports, or a database dump. In that case, keep the current codebase but replace the data layer carefully. This is useful when the code has been updated but user content was lost or corrupted.
Restoring after a failed deployment
If a deployment failed and the site became unusable, you may need to restore both the application files and the previous working deployment configuration. Check whether the restore brought back the correct context path, and make sure no partial files from the failed deployment remain.
Best practices for restoring Java hosting backups
A few simple practices can make restoration safer and faster for Java hosting users:
- take a fresh backup before restoring anything
- restore to a staging subdomain first if possible
- match the Java version to the backup environment
- restore the database together with the application files
- check logs immediately after the restore
- keep a record of the working Tomcat and JVM settings
- test the app before making it public again
If you are using a shared hosting account with private JVM or Tomcat management, these steps help avoid downtime and reduce the chance of configuration drift after a restore.
Troubleshooting when the application does not come back online
If the restore completed but the application still does not work, focus on the most common causes first.
1. The Java service is not running
Start the service from the Plesk extension and confirm the status changes to running. If it stops immediately, check the logs for startup errors.
2. The restored files are in the wrong path
Check whether the deployment directory matches what Tomcat expects. A restore to the wrong folder often looks like a missing app or a blank page.
3. The database settings are outdated
If the restored app cannot connect to the database, compare the current credentials with the ones used in the backup. Update the config if needed.
4. The Java version is incompatible
Some applications are sensitive to Java updates. If the backup was tied to an older runtime, restore the matching version or use a compatible one.
5. Permissions are wrong
Make sure the app can read its files and write to required folders. Permission issues can block deployment, uploads, and log creation.
When to contact support
Contact support if the restore finished but you still cannot identify the issue, especially if:
- the backup appears incomplete
- the Tomcat instance will not start
- you see repeated startup failures in the logs
- the restore changed the deployment path unexpectedly
- you need help matching the Java version to the application
Provide the support team with the restore time, domain name, error messages from the logs, and details about the Java and Tomcat setup. That makes troubleshooting much faster.
FAQ
Can I restore only the Java application files and not the whole hosting account?
Yes, if your backup tool and Plesk backup structure support partial restore. For many Java hosting cases, restoring just the app files and database is enough. This is useful when only one application needs recovery.
Do I need to restart Tomcat after restoring files?
Usually yes. Tomcat often needs a restart to reload restored WAR files, configuration changes, or updated classes. Without a restart, the application may continue using stale files.
What if my app uses a private JVM in My App Server?
Check the service status and Java version after restore. Because the JVM is managed separately, restoring files alone does not guarantee the runtime is active or compatible.
Why does my site show errors after a successful restore?
The most common reasons are missing database data, incorrect configuration, Java version mismatch, or incomplete deployment files. Logs usually show which one is causing the problem.
Can I restore an older backup over a newer deployment?
Yes, but do it carefully. Restoring an older backup may overwrite recent code or data. If the app has changed since the backup, compare the files first or restore to a test location before replacing the live version.
Conclusion
Restoring a hosted Java application from backup in Plesk is not only about getting the files back. For a Java hosting setup with My App Server, you should also confirm the Tomcat or private JVM service, the Java version, the application path, and the database connection. When those pieces match, a restore is usually quick and reliable.
For the best results, restore the backup in Plesk, verify the Java service, check logs, test the application functions, and only then put the site back into normal use. This approach keeps your Java hosting recovery process predictable and helps reduce downtime for WAR, JSP, servlet, and private JVM applications.