If you have restored files from a backup and your hosted Tomcat application is not starting correctly, the usual cause is that only part of the application was recovered. A working Tomcat deployment often depends on more than the .war file alone: it may also require the app directory, configuration files, logs, uploaded content, environment-specific settings, and a matching Java version. In a Plesk-based hosting environment, the safest approach is to restore the application in a controlled order and then verify the Tomcat service, deployment path, and permissions.
When to restore a hosted Tomcat application from backup
You normally restore a Tomcat application after one of these events:
- an application update failed and the site now shows errors;
- files were deleted or overwritten by mistake;
- you need to roll back to a previous version after a bad deployment;
- the Tomcat web application was reinstalled and needs its content back;
- you migrated a site and want to recover the original application structure.
For Java hosting on Plesk, this is especially important when the application runs on a private JVM or on a Tomcat version managed through the My App Server extension. In that setup, restoring the right files is only part of the job; the service settings and deployed application path must also match the backup.
Before you start the restore
Before restoring anything, check what type of backup you have. A complete restore is easier when the backup contains the full application folder, the Tomcat configuration, and any database dump if your application uses one. If the backup was created with Plesk, it may include subscription files, logs, and selected site data. If it was created manually, it may only contain the deployed app directory.
Check these items first
- Tomcat version used by the application before the restore.
- Java version required by the app.
- Deployment type: WAR file, expanded directory, or both.
- Database connection details if the app depends on MySQL, MariaDB, PostgreSQL or another external database.
- Custom configuration files such as context.xml, server.xml fragments, properties files, or external environment variables.
- Permissions on the restored files.
If the application was running on a hosted Tomcat instance created through My App Server, also confirm that the service is still available for the account and that the deployment path has not changed.
How Tomcat restores usually work in Plesk hosting
In a standard hosting control panel workflow, restoration usually means copying the application files back to the web space and then reactivating the Tomcat service or redeploying the application. In Plesk, the process may be handled through the file manager, backup manager, or a Tomcat management interface provided by your hosting platform.
For hosted Java applications, the most common restore targets are:
- the application source or build folder;
- the deployed WAR file;
- the expanded application directory;
- Tomcat-specific configuration files;
- log files used for troubleshooting after the restore.
If your hosting account uses the ITA My App Server extension, Tomcat runs under the account scope, which is useful for small and medium Java applications because you can manage the service, select a Java version, and deploy applications without needing a separate server administration layer.
Step-by-step: restore the hosted Tomcat application from backup
1. Put the application into maintenance mode if possible
If the site is still accessible and users are active, stop further changes before restoring. This prevents new uploads or database updates from being overwritten during the recovery process. If your application supports a maintenance page, enable it first. If not, consider temporarily stopping the Tomcat service while you restore files.
2. Download and review the backup
Open the backup archive locally or in a safe temporary folder and inspect its contents. Look for:
- WAR files;
- expanded web application directories;
- configuration files;
- database dumps;
- static assets such as uploaded images, PDFs or attachment folders;
- deployment notes or readme files from your team.
If the backup contains a full site snapshot, identify the exact folder that corresponds to your Tomcat application. In some hosting setups, the web root may contain several directories and not all of them belong to the Java app.
3. Restore the application files
Upload or copy the recovered files back to the original location in your hosting account. In a Plesk environment, this is often done through File Manager, SFTP, or an integrated backup restore tool. Place the files in the same path the application used before, unless you intentionally changed the deployment path.
Typical restore items include:
- the deployed .war file;
- the expanded app folder with WEB-INF and static resources;
- custom configuration files;
- asset directories such as uploads, media, or documents;
- any shared resource files required by the app.
If your application was deployed manually, restoring the expanded folder may be more important than the WAR file itself. If your workflow is WAR-based, make sure the restored WAR is the same build version expected by the application.
4. Restore database content if the application uses one
Many hosted Tomcat applications rely on a database for user accounts, orders, content, logs, or configuration. If the application state is incomplete after file restore, import the database backup as well. Use the same database name, user, password, and host settings that the application had before the incident, unless you are also updating the application configuration.
After importing the database, verify that the application properties file or datasource configuration still points to the correct connection details. A common restore issue is that files are restored correctly but the database connection still points to an old or empty database.
5. Check permissions and ownership
Restored files may have incorrect ownership or permissions, especially if they were unpacked from an archive outside Plesk and then uploaded. Tomcat must be able to read the application files, and in some cases write access is required for logs or uploaded content.
Review the following:
- read permissions for application code and static content;
- write permissions for upload directories and runtime cache folders;
- execute permissions only where needed, such as for scripts;
- ownership aligned with the hosting account or service user model used by your platform.
If permissions are too restrictive, Tomcat may start but fail to load JSP files, class files, or uploaded resources. If permissions are too open, the application can become less secure. Use the minimum permissions needed for the app to function.
6. Confirm the Java and Tomcat versions
After a restore, version mismatch is one of the most frequent causes of failure. A backup created while the app was running on one Java runtime may not work properly on another version. This matters especially when the app was built for a specific major Java release.
In My App Server, you can usually select from available Java/Tomcat combinations or manage a custom app server profile. If the restored application was built against a particular version, match that version as closely as possible before testing the deployment. For JSP and servlet applications, this can determine whether the application loads cleanly or throws class loading errors.
7. Restart or redeploy the Tomcat application
Once files, database content and permissions are in place, restart the Tomcat service or redeploy the app from the hosting control panel. Depending on the platform, you may need to:
- start or restart the service from the service control page;
- rebuild the deployment from the WAR file;
- refresh the application path in Plesk;
- clear temporary files before starting again.
If your hosting account uses a private JVM or dedicated Tomcat instance inside the shared hosting environment, restarting that service is usually enough to make the restored application live again.
8. Test the application carefully
Open the site and test the main pages, login flow, forms, file uploads, and any API endpoints the application exposes. Check whether images, CSS, JavaScript and attachments are loading correctly. A restore can appear successful at first but still miss external files or runtime folders.
Pay special attention to:
- HTTP status codes such as 404, 403 and 500;
- login and session handling;
- database-driven pages;
- upload and download features;
- any functionality that depends on external services.
What to do if the restored Tomcat app still fails
If the application does not start after restore, check the Tomcat logs first. In Plesk-based hosting, logs are usually the fastest way to identify whether the problem is caused by a missing class, a broken datasource, an incompatible Java version, or a file permission issue.
Common restore problems and their causes
- Blank page or HTTP 500 — often caused by missing configuration, classpath problems or an incompatible runtime.
- 404 on the app path — deployment path changed or the WAR was not redeployed correctly.
- Database connection error — credentials, host, or schema were not restored.
- JSP compile errors — Java/Tomcat version mismatch or missing dependencies.
- Missing uploads or images — static content folder was not included in the restore.
- Service starts but app does not load — application file structure is incomplete or permissions are wrong.
Review the logs in Plesk
Use the available logs and diagnostic tools in your hosting panel to find the exact error message. For hosted Tomcat applications, useful logs often include:
- Tomcat startup logs;
- application error logs;
- Apache reverse proxy or web server logs if the app is proxied through Apache;
- system or service logs exposed by the control panel.
Look for timestamps that match the restart or redeployment time. Errors that appear immediately after startup usually point to configuration or runtime problems, while errors that appear after a page request often point to missing resources or database connectivity.
Restoring from a Plesk backup versus a manual backup
The restore process is not identical for every backup type. If you use the panel’s built-in backup tools, the archive may include more of the hosting account state and can be restored more predictably. If you use a manual zip or tar archive, you may need to restore each piece separately.
Plesk backup restore
A Plesk backup is usually the easiest option because it can preserve the file structure and selected account settings. When restoring a hosted Tomcat app from a Plesk backup, confirm whether the backup included:
- the site files;
- the database;
- mail settings, if relevant;
- custom service or extension settings;
- logs useful for diagnosis.
Even when restoring from the panel, you should still validate Java version compatibility and check whether the Tomcat application was redeployed after the restore.
Manual backup restore
A manual backup is useful when you only want to restore the application itself. In that case, it is your responsibility to place the files back in the correct path, re-import the database if needed, and verify the Tomcat service configuration. This method is common when developers archive their application builds before deployment.
Best practices for hosted Tomcat recovery
To reduce downtime and avoid restore problems in the future, it helps to follow a few practical habits.
- Keep a copy of the deployed WAR file and the source build artifact.
- Back up custom configuration separately from the application code.
- Store database dumps together with the application release version.
- Document the Java version and Tomcat version used by each app.
- Keep notes for any manual changes made in Plesk or My App Server.
- Test restore procedures periodically, not only after an incident.
For small and medium Java applications, this approach is usually enough to recover quickly without needing a complex application server environment. It also makes it easier to switch between Tomcat versions or rebuild a private JVM instance when required by the app.
Example restore checklist
Use this checklist after recovering a hosted Tomcat application from backup:
- Application files restored to the original path
- WAR file or expanded directory restored
- Database imported and tested
- Configuration files verified
- Java version confirmed
- Tomcat service restarted
- Permissions checked
- Logs reviewed for startup errors
- Main site functions tested in the browser
Frequently asked questions
Can I restore only the WAR file and skip everything else?
Sometimes yes, but only if the application is stateless and does not rely on uploaded files, custom configuration or a database restore. In real hosted Tomcat environments, restoring only the WAR file is often not enough.
Why does the app work locally but fail after restore on hosting?
The most common reasons are a different Java version, missing environment settings, unavailable dependencies, or permission differences. Local development and hosted Tomcat often run with different runtime settings.
Do I need to restart Tomcat after restoring files?
In most cases, yes. Restarting or redeploying ensures that Tomcat reloads the restored application and picks up any configuration changes.
What if I use a custom app server or private JVM in Plesk?
Then you should verify that the restored application still matches the configured Java runtime and service profile. If the app server was customized, a simple file restore may not be enough without a service restart and redeploy.
Where should I check for restore errors first?
Start with the Tomcat logs and the web server logs in your control panel. They usually show whether the problem is a missing file, class loading issue, database failure or a runtime mismatch.
Conclusion
Restoring a hosted Tomcat application from backup is usually straightforward when you recover the full application stack in the right order: files, database, configuration, permissions and service restart. In a Plesk hosting environment with My App Server, the process is especially practical because you can manage the Tomcat service and Java version from the control panel while keeping the application within your hosting account. If the restore still does not work, the logs will usually point to the missing piece quickly.
For reliable recovery, keep your Tomcat deployment documented, back up both code and data, and verify the runtime after every restore. That approach reduces downtime and makes future restores much simpler.