If you need to recover a JSP site after a failed deployment, accidental file removal, or a configuration change in Plesk, the safest approach is to restore the application files first and then verify the Tomcat or private JVM service settings. For hosted Java applications, the backup often contains more than just your web content: it may also include the JSP source, compiled classes, deployment descriptors, database export, and Plesk-related configuration data.
In a managed hosting environment with JSP hosting and My App Server, a restore usually means putting back the application package, checking the document root or context path, and confirming that the service still points to the correct Java version and Tomcat instance. If your site runs on a shared hosting account with its own Apache Tomcat or private JVM, a clean restore can bring the application back online quickly without reinstalling the whole environment.
When you should restore a hosted JSP application from backup
Restoring from backup is the right step when the live application no longer matches the last known good state. Typical cases include:
- the JSP application returns 500 errors after deployment
- important files were deleted or overwritten by mistake
- a new WAR upload introduced a broken build
- the application works in staging but not in the hosted account
- configuration files were changed and the site no longer starts correctly
- you need to roll back after an update to JSP pages, servlets, or libraries
- database-related changes were also included in the backup and must be restored together
If the application is managed through Plesk, a restore is often faster and safer than trying to rebuild files manually. It also reduces the chance of missing hidden items such as .xml configuration files, custom JARs, or deployment metadata used by Tomcat.
What a JSP backup usually contains
Before restoring, it helps to understand what data may be inside the backup archive or snapshot. A hosted JSP application backup may contain:
- JSP pages and static web files
- compiled classes under
WEB-INF/classes - third-party libraries under
WEB-INF/lib web.xmland other deployment descriptors- the full WAR file or exploded application directory
- custom Tomcat context settings if included in the service backup
- database dumps or exported data for connected applications
- Plesk site settings, depending on how the backup was created
In a My App Server setup, the backup may also relate to the selected Java version, service configuration, and the path where the application was deployed. If the restore brings back the files but the site still does not start, the issue may be in the service configuration rather than in the application content itself.
Before you restore: check these points first
A restore works best when you prepare the environment and avoid overwriting useful changes by accident. Review the following before starting:
Confirm the backup date
Choose the most recent backup that still includes a working version of the application. If the problem started after a specific deployment, restore a backup from before that change.
Check whether the backup is full or partial
Some backups include only files, while others also include databases, mail, and configuration. For JSP applications, you may need both the web content and the database, especially if the app stores content dynamically.
Make a current copy first
Even if the site is broken, download or archive the current version before restoring. This is useful if you later need to compare files, recover a recent edit, or troubleshoot what changed.
Verify the Java and Tomcat settings
After restore, the application should still use the correct Java version and the correct Tomcat instance or private JVM. If the service was altered manually, the files may return correctly but the site may still fail to start.
Know the deployment format
Determine whether your application is deployed as a WAR file, as an exploded directory, or through a custom application server setup in Plesk. The restore method may differ slightly depending on the format.
How to restore a hosted JSP application from backup in Plesk
The exact menu labels can vary depending on your hosting account setup and backup tool, but the overall workflow is similar across Plesk-based environments.
Step 1: Sign in to Plesk
Log in to your Plesk control panel using the credentials provided by your hosting company. Open the subscription or domain where the JSP application is hosted.
Step 2: Open the backup management tool
Find the backup area in Plesk. This may be listed under backup management, backup manager, or a hosting tools section. In a managed hosting environment, the backup interface may also be limited by your account permissions.
Step 3: Select the correct backup
Choose the backup that contains the version of the application you want to restore. Pay attention to:
- backup date and time
- whether the backup is full or incremental
- which domain or subscription it belongs to
- whether database content is included
If you are restoring after a failed update, select a backup from before the update was applied.
Step 4: Choose what to restore
For a JSP application, you typically want to restore:
- website files
- application directories
- WAR package or deployed exploded app
- configuration files under the application path
- database, if the application depends on one
If the backup interface allows granular restore, avoid restoring unrelated mail or DNS content unless you specifically need those items.
Step 5: Review overwrite options
Most restore tools will warn you that existing files may be replaced. This is normal. If the live application folder contains important changes made after the backup, consider exporting the current files first. If the site is already broken and the backup is known-good, replacing the current version is usually the right move.
Step 6: Start the restore
Begin the restore and wait for it to complete. Larger JSP applications may take some time, especially if the backup includes databases or many small library files. Do not interrupt the process unless the interface clearly indicates a failure.
Step 7: Restart or reload the application service if needed
After the files are restored, the application service may need a restart to load the updated WAR, classes, or configuration. In a My App Server environment, this can usually be done from the service control area in Plesk.
How to restore only the JSP application files
If you do not want to restore the entire hosting account, you can usually recover only the application files. This is often the preferred approach when the database is still intact and only the code base needs to be rolled back.
Restore the following items first:
.jspfiles.javasource files, if kept in the deployment tree.classfiles if your setup stores compiled outputWEB-INFdirectory- JAR libraries in
WEB-INF/lib - static assets such as images, CSS, and JavaScript
After restoring the files, refresh the application and test the main pages. If the application still fails, inspect the logs for startup errors, missing classes, or classpath issues.
How to restore the database for a JSP application
Many JSP applications depend on MySQL, MariaDB, PostgreSQL, or another database. If the backup includes database content, restore it when:
- site content disappeared
- form submissions no longer work
- the application returns data-related errors
- tables were dropped or modified incorrectly
- the application version and database schema must match the backup state
In Plesk, database restore is usually done from the backup manager or from the database management area, depending on how the backup was created. If the application uses a restore point from before a schema change, restoring the database together with the files helps keep the app consistent.
After the database restore, check the connection settings in the JSP application, especially:
- database host
- database name
- database username
- database password
- JDBC driver version
Restoring a WAR-based Tomcat application
If your hosted JSP app is deployed as a WAR file, the restore process may be simpler. Uploading the saved WAR file back to the application path or restoring it through the backup manager can redeploy the app cleanly.
Typical WAR restore flow
- Restore the archived WAR file from backup.
- Place it in the expected deployment directory or application folder.
- Remove broken temporary files if the service keeps old cached content.
- Restart Tomcat or the private JVM service.
- Check whether the WAR was unpacked correctly.
- Open the application URL and verify the pages load.
If your hosting setup uses a custom app server managed by Plesk, the restore might also require checking the application name, context path, and port binding. A WAR file can be correct but still not load if the service is attached to the wrong context.
Restoring an exploded JSP application directory
Some Java hosting setups deploy the application as a folder structure instead of a single WAR. In that case, the restore must replace the full directory tree, not just the visible JSP pages.
Pay attention to these common restore targets:
- the application root folder
WEB-INF- resource folders used by the app
- custom properties files
- uploaded user content stored in the web root
Do not forget hidden files and folders if the backup tool preserved them. Missing configuration files are a common reason why a restored JSP application still behaves incorrectly.
What to do after the restore
A successful file restore is only part of the job. For a hosted JSP application, always complete the following checks:
Test the homepage and key functions
Open the main URL and test the core application flows, such as login, forms, search, or admin pages. Verify that the restored version behaves as expected.
Check the application logs
Review the logs in Plesk or through the hosting tools provided for the domain. Look for:
- startup exceptions
- class not found errors
- JDBC connection failures
- permission issues
- deployment errors
Logs are especially useful when the site loads partially but fails on specific JSP pages.
Confirm the Java version
Make sure the application is running with the same Java version used when the backup was created, or a compatible version. A restore can succeed while the app still fails if the runtime version changed.
Restart the service if needed
If the platform keeps cached classes or holds old file handles, restart the Tomcat service or private JVM. This is often necessary after restoring compiled classes or updated libraries.
Clear temporary application files if the host recommends it
Some JSP applications create cached output or temporary deployment files. If the restored app still shows old behavior, clearing temp files can help the server load the restored content correctly.
Common issues during restore
Even in a well-managed hosting environment, restore jobs can fail for predictable reasons. Here are the most common ones.
Backup does not include the application directory
If only the account settings were backed up, the JSP files may not be present in the archive. Confirm that the backup was created at the file level and not only at the subscription or control panel level.
Database mismatch after restore
A restored application may expect a database schema that does not match the current one. This happens when files are rolled back but the database is not. Restore both components from the same backup point when possible.
Permission problems
After restore, files may have the wrong ownership or permissions for the Tomcat process. If the application cannot read JSP files, libraries, or configuration files, it may fail with access errors.
Wrong Java or Tomcat version
Older JSP applications may depend on a specific Java release or servlet container behavior. If the version changed, the app may start with errors even though the files are restored correctly.
Old cached content remains visible
Browsers, reverse caches, or application temp files can make it seem like the restore did not work. Refresh with a clean browser session, and if needed, restart the service.
Best practices for restoring hosted JSP applications
To reduce downtime and avoid repeat incidents, use these practical habits:
- keep regular backups of the application files and database
- test restore points periodically, not only when an outage occurs
- store release notes for each deployment
- track which Java version and Tomcat version each release uses
- separate static files, application code, and uploads where possible
- before major changes, export the current working version
- after restore, validate logs and service status immediately
For small and medium JSP, servlet, and Tomcat-based applications, these steps usually provide enough control to recover quickly without requiring a full platform rebuild.
When to contact hosting support
Contact support if:
- the backup restore fails repeatedly
- the restored application files look correct but the service will not start
- you need help identifying the correct backup version
- database restore is not available in your account
- the Tomcat or private JVM service shows errors in Plesk
- you suspect a permission, context path, or runtime mismatch
When you open a support request, include the domain name, backup date, the restore action you attempted, and any error messages from the logs. This speeds up troubleshooting.
FAQ
Can I restore only part of a JSP application?
Yes. In many cases you can restore only the application files, only the database, or both. For a broken deployment, restoring only the affected app directory is often enough.
Will restoring the backup restart my JSP site automatically?
Not always. Some restore tools replace files only. You may need to restart Tomcat or the private JVM service in Plesk to make the restored files active.
What if the site still shows errors after restore?
Check the logs first. The issue may be a Java version mismatch, a database connection problem, missing libraries, or incorrect file permissions rather than the backup itself.
Do I need to restore the database too?
If the application stores content, users, orders, messages, or settings in a database, restoring only the files may not be enough. In that case restore the database from the same point in time.
Can I use a backup from an older Java version?
Usually yes, but the application must still be compatible with the Java version currently selected in My App Server. If not, you may need to switch to the matching runtime or deploy a compatible build.
What is the difference between restoring a WAR file and restoring an exploded app?
A WAR restore usually redeploys the whole application package. An exploded app restore replaces the full directory tree. Both can work well, but the correct method depends on how the site was originally deployed.
Conclusion
To restore a hosted JSP application from backup in Plesk, focus on three things: recover the correct files, restore the database if the app needs one, and verify the Java/Tomcat service settings afterward. In a My App Server environment, that usually means checking the selected Java version, restarting the service if necessary, and confirming the deployment path or context is still correct.
For most JSP hosting and Tomcat hosting setups, a clean backup restore is the fastest way to roll back a broken release and return the application to a known working state. If you combine regular backups with log checks and version tracking, future restores become much simpler and far less risky.