If you have a hosted Tomcat application running in Plesk, restoring it from backup usually means bringing back three things in the right order: the application files, the Tomcat configuration, and any database data it depends on. In a managed hosting environment, the exact restore method can vary slightly depending on whether you use a Plesk backup, a file-level archive, or the My App Server extension for Java hosting.
For most Tomcat hosting accounts, the safest approach is to restore the application into the same subscription or domain where it was originally deployed, then verify the Java version, Tomcat instance, and service settings before putting the site back online. This helps avoid mismatches between the WAR file, JVM, database connection settings, and the app server configuration.
What you need before restoring a Tomcat application
Before you start, make sure you have access to the Plesk panel for the hosting subscription and that you know which backup source you are using. In a typical Tomcat hosting setup, a full restore may include:
- The application archive, such as a WAR file or unpacked web application directory.
- Tomcat-related configuration files, if they were stored separately.
- Any custom JVM or service settings used by My App Server.
- Database backups, if the Java application uses MySQL, MariaDB, or another supported database.
- Uploaded static files, images, documents, and user content.
If your application uses external services, such as SMTP credentials, API keys, or payment gateway settings, have those details ready as well. These are often not restored automatically from a file backup.
Check how the application was backed up
There are usually three common backup scenarios in Plesk hosting:
1. Full Plesk subscription backup
This is the easiest option. A full subscription backup may include website files, databases, mail settings, and, depending on how the Tomcat app is deployed, application data tied to the hosting account.
2. File-only backup
If only the web root or application directory was archived, you may need to restore the Tomcat deployment files manually and then reconnect the application to its database.
3. My App Server or custom Tomcat backup
When using the ITA My App Server extension, the application may run in a private JVM with its own Tomcat instance. In this case, you should confirm whether the backup includes the app server configuration, deployed WAR files, and any custom runtime settings.
Knowing the backup type first saves time and reduces the risk of restoring the wrong files into the wrong place.
Restore a hosted Tomcat application from a Plesk backup
Use this method if you have a standard Plesk backup and want to recover the application as part of the hosting account.
Step 1: Open the backup manager in Plesk
Log in to Plesk and go to the subscription or domain where the Tomcat application is hosted. Open the backup tool or backup manager for that account.
Step 2: Select the correct backup point
Choose the backup date that contains the working version of the application. If the site failed after a deployment, pick the most recent successful backup before the change.
Step 3: Choose what to restore
If the backup interface allows granular restore, select the parts you need:
- Website files
- Databases
- Mail settings, if relevant
- Application-specific files
For a Tomcat app, restoring only the files may not be enough if the app stores data in a database or if its configuration changed after deployment.
Step 4: Run the restore
Start the restore process and wait until it completes. Large Java applications can take longer if the backup contains many static assets, logs, or database records.
Step 5: Verify the deployment
After the restore finishes, check that the application starts correctly. Confirm that:
- The Tomcat service is running.
- The deployed WAR file or application directory is present.
- The database connection details are correct.
- The Java version matches the application requirements.
- Any uploaded user files are back in place.
Restore a WAR file or Tomcat deployment manually
If your backup is file-based, or if you only need to restore the application package, you can usually do this manually through Plesk File Manager, FTP, or SSH if enabled on your hosting account.
Step 1: Locate the application directory
Find the directory where the Tomcat application was deployed. Depending on your setup, this may be the web application root or a folder used by My App Server for the specific domain.
Step 2: Upload the backup files
Upload the WAR file or the unpacked application directory from your backup. If the application was previously deployed as an exploded directory, restore the same structure rather than only the archive.
Step 3: Replace the current version carefully
If you are restoring over an existing installation, rename the current folder first so you have a fallback copy. Then place the restored files in the correct location.
Step 4: Check file permissions
File ownership and permissions matter in hosting environments. Make sure the Tomcat process can read the application files and write to the folders it needs, such as temporary directories, upload locations, or log paths.
Step 5: Restart the application service if needed
Some deployments require a restart after files are restored. In Plesk, use the service controls for the Tomcat instance or My App Server if available. Restarting helps Tomcat reload the web application cleanly.
Restore a Java app hosted with My App Server
If your hosting account uses the ITA My App Server extension, the restore process may involve both the app files and the Java service configuration. This is especially important when the application runs in its own private JVM and uses a chosen Java version.
Step 1: Confirm the running app server profile
Open the My App Server section in Plesk and check which application profile was used before the backup. Note the Java version, Tomcat version, memory settings, and any custom startup options.
Step 2: Restore the application package
Upload the backup WAR file or application directory to the relevant deployment path. If your backup contains a previous release, make sure it replaces the correct version.
Step 3: Reapply service settings
If the app server was configured with custom environment variables, JVM options, or port settings, re-enter them after the file restore. A Java application may start but still fail if those values are missing.
Step 4: Start or restart the service
Use the service control tools in Plesk to start the Tomcat instance again. If the service was already running, restart it so the restored application is loaded freshly.
Step 5: Test the application URL
Open the application in a browser and test the main functions, especially login, form submission, file uploads, and any feature that depends on database data.
Restore the database behind the Tomcat application
Many hosted Java applications rely on a database, and restoring the web files alone is not enough. If the application suddenly shows errors, missing records, or empty pages after a restore, the database may not have been recovered yet.
Typical database restore steps in Plesk
- Open the database management section for the subscription.
- Select the correct database backup file or backup point.
- Import the database into the existing or newly created database.
- Check the application’s connection settings, including username, password, host, and database name.
If the restore process recreated the database with a different name or credentials, update the Java application configuration accordingly. In Tomcat-based apps, this is often stored in a properties file, XML configuration, or environment variable.
What to check after restoring the application
After a restore, a careful verification step is important. Even when the files are back in place, Java web apps can fail for small configuration reasons.
Check Tomcat service status
Make sure the service is running in Plesk. If it is stopped, start it and inspect the service logs for startup errors.
Check Java version compatibility
A restored application may depend on a specific Java runtime. If the hosting account allows Java version selection, confirm that the same version used before the backup is active now.
Check the application context path
If the app was deployed under a specific path, such as /app or /portal, verify that the context did not change during restore. A changed context path can make the app appear broken even when it is deployed correctly.
Check permissions and temporary folders
Tomcat applications often need write access to temporary directories, upload folders, or cache directories. If the restore failed because permissions changed, the application may start but not function fully.
Check logs for startup and runtime errors
Use the Plesk logs and diagnostic tools to review the Tomcat log files. Look for:
- Class loading errors
- Database connection failures
- Missing environment variables
- File permission errors
- Port conflicts or service startup issues
Logs usually point to the exact file or setting that needs attention after the restore.
Common problems during Tomcat restore
The app starts but shows a blank page
This often means the deployment files are present, but the application failed during initialization. Check logs, database settings, and Java compatibility.
Database data is missing
Restore the database backup separately. Make sure the application is pointing to the correct database instance.
Tomcat service does not start
This can happen if the restored service settings are invalid, the Java version changed, or the application uses a port already in use.
Uploaded files are gone
Some applications store uploads outside the main WAR file. If the restore only covered the WAR package, you may need a separate restore of the uploads directory.
Old errors still appear after restore
Clear application caches if the app uses them. A restored app may still be reading cached sessions or temporary data from the previous state.
Best practices for restoring Tomcat applications in hosted environments
To make future restores easier, it helps to follow a few simple practices for Java hosting and Tomcat hosting accounts.
- Keep periodic full backups, not only file backups.
- Store deployment notes for Java version, Tomcat version, and service settings.
- Document database names, usernames, and connection paths.
- Keep a copy of custom configuration files outside the application package.
- Test backups periodically to confirm they can be restored.
- Use clear versioning for WAR files and release folders.
These habits reduce restore time and make it easier to recover a site after a failed deployment or accidental deletion.
When to contact support
If the restore looks incomplete, or if the app does not start after you have restored files and database data, contact hosting support with the following details:
- The domain name or subscription name
- The backup date you restored
- The Tomcat or My App Server version in use
- The Java version selected for the app
- Any error messages from the logs
- Whether the database was restored too
This information helps support diagnose whether the problem is related to deployment files, Tomcat service settings, database consistency, or application-level configuration.
FAQ
Can I restore only part of a Tomcat application backup?
Yes, if your backup tool allows partial restore. You can often restore just the files, just the database, or both. For Java apps, restoring only one part may not be enough if the app depends on both.
Do I need to restart Tomcat after restoring files?
Usually yes. Restarting the service helps Tomcat reload the restored application and apply any updated configuration.
Will a WAR file restore also bring back database records?
No. A WAR file contains application code and resources, but not usually the data stored in a database. Restore the database separately if needed.
What if my application uses a private JVM?
If your hosting account uses My App Server, check the Java version, service settings, and startup options after the restore. The application may need both file and service configuration restored.
Why does the app work on one backup but not another?
Different backup points may contain different database states, configuration values, or Java deployment files. Pick the backup created before the issue began and verify all dependent components.
Can I restore a Tomcat app to a different domain?
Sometimes yes, but it may require changes to paths, database credentials, context settings, and environment variables. For the fastest and safest restore, use the original hosting location first.
Conclusion
Restoring a hosted Tomcat application from backup is usually straightforward when you treat it as a complete service recovery rather than only a file restore. In a Plesk-based hosting environment, the best results come from restoring the application files, database data, and Tomcat or My App Server settings together, then verifying the Java version and service status.
If you use ITA’s Java hosting with My App Server, you get practical control over a private JVM and Tomcat instance inside your hosting account, which makes restore and service management more manageable for small and medium Java applications. After the restore, always test the app thoroughly and review the logs before considering the recovery complete.