If you need to restore a hosted Java application in Plesk, the key is to recover both the application files and the Java service configuration that makes the app run correctly. In a typical Java hosting setup with My App Server, your application may depend on a Tomcat instance, a selected Java version, deployed WAR files, custom context settings, uploaded libraries, and database data. Restoring only one part is usually not enough.
This guide explains how to restore a Java application from backup in a Plesk-based hosting environment, with a focus on practical steps for hosted Tomcat and private JVM setups. It is especially useful if you use Java hosting, JSP hosting, servlet hosting, or a private Apache Tomcat service managed through Plesk.
What should be included in a Java application backup
Before restoring anything, it helps to understand what a complete backup should contain. A hosted Java application often has several layers, and each layer may be stored in a different place.
- Application package — usually a WAR file, an exploded application directory, or custom application files.
- Tomcat or Java service configuration — service settings, Java version selection, context configuration, environment variables, and startup options.
- Uploaded libraries — JAR files placed in
WEB-INF/libor in custom library locations. - Static content — images, CSS, JavaScript, and other web assets.
- Database backup — MySQL, MariaDB, PostgreSQL, or another database used by the app.
- Scheduled tasks and cron jobs — if your application depends on jobs for imports, email processing, or cache refresh.
- Logs and diagnostics — useful for troubleshooting after restore, though not always required for the application itself.
If your backup was created through the hosting control panel, it may include account-level data. If you created a manual backup, check whether it contains the web root, application directory, database dumps, and any custom Tomcat configuration files.
When to restore a hosted Java application from backup
You may need to restore a Java app after several common events:
- a failed deployment or broken WAR upload
- accidental file deletion
- bad code changes pushed to production
- database corruption or accidental data loss
- incorrect Tomcat or Java version changes
- restore after migration or environment rebuild
- recovery after plugin, extension, or configuration changes in Plesk
For hosted Java applications, it is usually safer to restore to a staging copy first when available. This allows you to verify that the app starts correctly, connects to the database, and serves the expected pages before replacing the live version.
Before you start the restore
To reduce the risk of overwriting the wrong data, gather the following information first:
- the name of the Java application or Tomcat instance
- the backup date and scope
- the Java version used before the problem happened
- the deployed application type: WAR, JSP, servlet app, or custom structure
- database name and credentials, if the app uses a database
- any custom service settings, ports, or environment variables
If the application was running on My App Server, note whether it used a ready-made Tomcat version installed with one click or a custom app server configuration uploaded manually. That detail matters because the restore process may need to preserve the same service type and version.
Restore options in a Plesk hosting environment
Depending on how the backup was created, you may have one of these restore methods:
- Full account restore — recovers files, databases, mail, and hosting settings from a Plesk backup.
- Website or subscription restore — useful when the Java app is tied to a single hosting subscription.
- Manual restore — for file-level backups, database dumps, or exported Tomcat configurations.
- Application-level restore — if your deployment process keeps a separate copy of the WAR file or application folder.
In a managed hosting setup, the exact restore method depends on what access is available in your Plesk panel and how the backup was stored. If you are unsure, review the backup details before overwriting the current application.
How to restore a hosted Java application from a Plesk backup
1. Stop the application service if needed
If the Java app is currently running and actively serving traffic, stop the Tomcat service first if you expect the restore to replace live files. This prevents file locks, partial writes, and inconsistent content while the restore is taking place.
In My App Server, service control is normally handled through Plesk. Stop the app server instance only if the restore affects its deployed files or configuration. If the restore is limited to a database or static assets, the service may not need to be stopped, although a short downtime window is still recommended.
2. Restore the application files
Recover the main application content from backup. This usually includes one of the following:
- the WAR file that was deployed to Tomcat
- the exploded application directory
- the web application source tree if you deploy unpacked files
- supporting folders such as
WEB-INF,lib, or custom resource directories
If you are restoring manually, upload the files to the same location the application used before the incident. Keep the directory structure unchanged unless you intentionally want to redeploy to a different path.
For Tomcat hosting, the application location typically matters. A mismatch between the restored files and the configured context path can lead to 404 errors or application startup failures.
3. Restore the database
If the application uses a database, restore that backup next. This step is often essential because the app may start without errors but still show missing content, broken logins, or invalid data if the database is not restored.
Typical database restore steps include:
- create or select the correct database in Plesk
- import the SQL dump or database backup
- verify the database user and password
- confirm that the JDBC connection string still matches the environment
If the restore comes from a different point in time than the application files, you may see data mismatches. When possible, restore the file backup and database backup from the same backup set.
4. Restore Tomcat or Java service settings
This is a common step that is overlooked. A hosted Java application may depend on specific service settings that are not included in a simple file restore.
Check the following after restore:
- selected Java version
- Tomcat version or custom app server version
- service start mode
- heap or JVM memory options
- environment variables
- context path and deployment path
- custom ports or connector settings
With My App Server, you can normally manage a private JVM or Apache Tomcat instance through Plesk. If your previous setup used a particular Java version, restore or reselect the same version whenever possible. Changing the Java version during restore can introduce compatibility issues, especially with older JSP or servlet applications.
5. Re-deploy the WAR file if required
If your application was backed up as a WAR package, redeploy it after files and database data are restored. Depending on your setup, you may need to upload the WAR again through the Plesk interface or place it into the app’s deployment folder and trigger a restart.
After redeployment, confirm that:
- the application expands correctly
- the context path is the same as before
- the app starts without deployment exceptions
- all dependent resources are available
6. Restart the Java service
Once the restore is complete, start the Tomcat or Java service again. In Plesk, this is usually done from the service control area for the app server.
After startup, wait for the service to stabilize, then test the application homepage, login flow, and any key business functions. A Java application can appear to start correctly but still fail later because of a missing database entry, incorrect permissions, or an outdated configuration file.
How to restore only part of a Java application
Sometimes a full restore is not necessary. You may only need to recover one component of the app.
Restore only application files
Use this when:
- the code was overwritten by a bad deploy
- the app content is damaged
- the database is still intact
Upload the missing or replaced files, then restart Tomcat if the application server needs to reload them.
Restore only the database
Use this when:
- the app code is fine
- users report missing records or broken transactions
- you need to roll back data after an error
After database import, clear or refresh any application caches if the app stores cached database records.
Restore only Tomcat configuration
Use this when:
- the application files and database are correct
- the app stopped working after a service setting change
- the wrong Java version was selected
Restore the service settings, then restart the app server and review logs for startup warnings or unsupported options.
Common restore problems and how to check them
Application starts but shows errors
This often means the files were restored, but one of these is still wrong:
- database connection settings
- missing JAR library
- incorrect Java version
- wrong file permissions
- broken context path
Check the logs in Plesk and Tomcat first. The logs usually show whether the failure comes from deployment, database access, or JVM startup.
404 not found after restore
This can happen if the app was deployed to a different path than before. Verify the context path, deployment folder, and whether the WAR file expanded properly.
Database connection fails
After restore, the database user may no longer match the restored application settings. Check the JDBC URL, credentials, host name, and database name. If you restored from an older backup, confirm that the schema version is still compatible with the application code.
Permission issues on uploaded files
Some restore methods preserve file content but not the expected ownership or permissions. If Tomcat cannot read the restored files, the app may fail to load static assets or compiled classes. Recheck permissions on the application directory and any uploaded resource folders.
Java version mismatch
If your app was developed for an older Java runtime, restoring it to a newer version without testing can cause class loading errors or unsupported API problems. Use the same Java version that was active before the incident whenever possible.
How to restore a Java app safely in production
For live hosted applications, follow these good practices:
- take a fresh backup before restoring anything
- restore during a low-traffic period if possible
- keep a note of the original Java and Tomcat versions
- test the app after restore before announcing completion
- check both the application and database after the first start
- review logs immediately after restart
If the app is business-critical, consider restoring to a separate staging domain first. That gives you a safer way to confirm that the hosted Java application runs properly after the backup is applied.
Using My App Server in Plesk for restore and recovery
In an ITA Java hosting environment, My App Server is designed to make Java deployment and recovery more practical inside a shared hosting account. You can install and manage a private Tomcat or JVM instance, choose from available Java versions, and control the service from Plesk.
That is helpful during a restore because you can:
- restart the application server without leaving the hosting panel
- reselect the correct Java version after recovery
- reapply custom app server settings
- deploy WAR files for JSP and servlet applications
- keep the Java service isolated from other hosting tasks in the account
If you uploaded a custom app server version manually, make sure the restored files still match the version you installed. A restore from backup should bring back the app content, but it should not silently change the runtime behavior of your Tomcat service.
Checklist after restoration
After the restore, verify the following before closing the incident:
- the correct Java version is active
- Tomcat or the private JVM is running
- the app opens on the expected URL
- login, forms, and core actions work
- database reads and writes succeed
- static files and uploaded assets load correctly
- logs do not show startup errors
- scheduled jobs run if the app depends on them
If something is not working, compare the restored setup with your previous configuration notes. In Java hosting, small differences in service settings can have a bigger effect than in a simple static website restore.
FAQ
Can I restore only the Java application without the whole hosting account?
Yes. In many cases you can restore only the application files, only the database, or only the Tomcat settings. The exact method depends on how the backup was created and what access you have in Plesk.
Do I need to restore Tomcat separately?
Usually you do not restore the Tomcat binary itself unless you changed to a different custom app server version. More often, you need to restore the application files and then recheck the Java version, service settings, and deployment path.
What if my backup contains a WAR file only?
Upload or redeploy the WAR file to the correct Tomcat instance, then restart the service and verify the database connection. If the application uses external configuration files, you may need those as well.
Will the restore bring back my database automatically?
Only if the backup includes the database. File backups and application archives do not always contain database data, so check the backup contents before assuming the app is fully recoverable.
Why does the app fail after restore even though the files look correct?
Common causes are a wrong Java version, missing database credentials, permission problems, a different context path, or missing libraries. Review the logs in Plesk and Tomcat to identify the exact cause.
Can I restore a Java app from an older backup onto a newer server setup?
Yes, but you should test compatibility first. Older Java applications may depend on a specific runtime version, library set, or Tomcat behavior. If possible, match the original environment before going live.
Summary
Restoring a hosted Java application from backup in Plesk is more than copying files back into place. For a reliable recovery, restore the application package, database, and Java service settings together, then verify the Tomcat or private JVM configuration before reopening the site. In a My App Server environment, this process is more manageable because Java deployment, service control, and version selection are available in the hosting panel.
For the best results, always confirm what your backup contains, keep the same Java version where possible, and review logs after the service restarts. That approach helps you recover Java hosting, Tomcat hosting, and JSP or servlet applications with less downtime and fewer surprises.