Before you deploy a JSP update, it is best practice to create a full backup of your website, application files, and database. In a Plesk hosting environment, this gives you a safe rollback point if the update introduces a compilation issue, changes application behaviour, or affects the Apache Tomcat service behind your Java hosting setup. For JSP hosting, even a small change in a page, tag library, servlet mapping, or shared class can impact the running application, so a backup should always be part of the deployment checklist.
If you are using a Java hosting setup with My App Server, you can manage your own Apache Tomcat or private JVM inside a shared hosting account. That makes backups especially important because your JSP application files, Tomcat configuration, and runtime-specific settings may all need to be restored together. The safest approach is to back up both the web root and any application data used by your JSP or servlet application before you upload the update.
Why a backup matters before a JSP deployment
A JSP update can include code changes in .jsp files, compiled classes, tag files, web.xml updates, library changes, or even a new WAR package. If something breaks during deployment, a backup allows you to return to the previous working state quickly without troubleshooting under pressure.
Common risks include:
- JSP compilation errors after a change in syntax or an incompatible library version.
- Broken servlet routing due to a modified
web.xmlor annotation-based mapping. - Missing resources such as images, properties files, or configuration files.
- Database changes that do not match the updated JSP application logic.
- Tomcat or JVM configuration issues after updating application-level settings.
- Unexpected differences between the staging and live environment.
In a managed hosting environment, backups also help you separate application issues from infrastructure issues. If the update fails, you can restore the previous version and confirm whether the problem came from the new deployment or from the environment itself.
What to back up before updating JSP files
When preparing a JSP deployment, do not back up only the files you plan to edit. A complete backup should include everything your application needs to run correctly.
1. Application files
Back up the entire application directory or document root used by your JSP application. This usually includes:
.jspfiles.javasource files, if they are stored in the project tree- compiled
.classfiles, if applicable - JAR libraries in
WEB-INF/lib - deployment descriptors such as
web.xml - tag files and custom JSP fragments
- static assets like CSS, JavaScript, images, and uploads
2. Configuration files
Many JSP applications depend on environment-specific configuration files. Save copies of:
- database connection settings
- application property files
- Tomcat context configuration, if used
- custom initialization files
- server-side include files
3. Database backup
If your JSP application reads or writes data to a database, back up that database before deployment. A code rollback alone may not be enough if the update also changed stored content or schema assumptions.
4. Tomcat and service-related settings
If your deployment touches the Java runtime, Apache Tomcat, or My App Server settings, record the current configuration and service state. This may include:
- selected Java version
- Tomcat version in use
- custom JVM options
- memory settings
- service startup parameters
These settings are often as important as the application files themselves, especially when using a private JVM or custom app server setup in Plesk.
How to create a backup in Plesk before deploying a JSP update
Plesk provides a practical way to create a backup of your hosting subscription or individual site data. The exact menu names may vary slightly depending on your hosting plan and available permissions, but the process is generally straightforward.
Step 1: Open the subscription or domain in Plesk
Log in to Plesk and open the domain or subscription where your JSP application is hosted. Make sure you are working in the correct site before you create the backup. If you manage multiple domains, verify the site name carefully to avoid backing up the wrong account.
Step 2: Go to the backup section
In Plesk, find the backup management area for the domain or subscription. Depending on the hosting configuration, this may be available under a backup manager, webspace backup, or backup settings page.
Step 3: Choose the backup scope
Select the data you want to include. For a JSP application update, it is usually best to back up everything relevant to the site, not just a single directory. If the interface allows partial backup selection, include:
- website files
- databases
- mail data, if the site depends on mail-related configuration
- application configuration and settings
If the site uses My App Server, include the Java application files and any custom Tomcat-related configuration available in the hosting panel.
Step 4: Use a clear backup name
Name the backup in a way that helps you identify it later. A useful format is:
pre-jsp-update-YYYY-MM-DD
You can also include the release name or version number, for example:
pre-jsp-update-v2.4.1
Clear naming matters when you need to restore quickly, especially if you keep multiple backups for different application releases.
Step 5: Start the backup and wait for completion
Run the backup and let it complete fully before you upload any changes. Do not deploy while the backup job is still in progress. In a hosting environment, interrupted backups can produce incomplete restore points and lead to confusion later.
Step 6: Confirm that the backup is available
After completion, verify that the backup appears in the backup list and that the timestamp, size, and included items look correct. If Plesk provides a download, test, or checksum option, use it to confirm that the backup is valid.
Recommended backup approach for JSP, Tomcat and WAR deployments
For Java hosting and JSP hosting, the best backup strategy depends on how your application is deployed.
For file-based JSP deployments
If your application runs directly from the web root or a project folder, back up the entire application directory before replacing JSP pages or libraries. This is the simplest and most reliable option.
For WAR-based deployments
If you deploy a WAR file through Tomcat or a related Plesk extension, keep a copy of the previous WAR package and the exploded application directory if one exists. A rollback may require both the archived package and the unpacked runtime files, depending on how the application is deployed.
For private JVM or custom app server setups
If you are using My App Server with a custom Apache Tomcat setup, make sure you preserve both the application content and the service configuration. In some cases, the application will start only when the same Java version, memory limits, and service settings are restored together.
For applications with database changes
If the update includes schema changes, create a separate database dump before deployment. This is especially useful if the JSP update adds fields, modifies queries, or changes how data is stored and read.
Best practices before you upload the JSP update
Creating a backup is only one part of a safe deployment. The following checks help reduce the chance of a failed update.
- Test the update in staging first if a staging environment is available.
- Compare file paths, include directives, and package names before upload.
- Check for changed third-party libraries and version conflicts.
- Review database migrations before applying them to production.
- Note the current Java version and Tomcat version used by the site.
- Save the current Plesk and My App Server configuration for reference.
If your JSP application depends on cached data, session state, or compiled classes, plan the deployment so you know whether to clear caches or restart the service after the update.
How to restore the backup if the JSP update fails
If the deployment causes errors, restore the backup as soon as possible to reduce downtime. The exact restore process depends on whether you backed up a full subscription, only website files, or separate database content.
Restore website files
Use the backup restore function in Plesk to return the previous application files. This will typically replace the updated JSP pages, libraries, and configuration files with the older working version.
Restore the database
If the update changed stored data or affected schema compatibility, restore the database from the same backup point. Restoring files without restoring the database can leave the application in an inconsistent state.
Verify Tomcat or My App Server service status
After restoring, check that the Java service is running properly. In a My App Server environment, review the service control panel and confirm that the correct Java and Tomcat version are still selected. If needed, restart the service to reload the restored application cleanly.
Test the site after restore
Open the application in a browser and verify the affected JSP pages, login flow, forms, and database-backed features. If possible, review application logs and Tomcat logs for errors after the rollback.
Useful checks in Plesk before deployment
Plesk is not only for backups. It is also a useful place to verify application health before and after a JSP update.
- Check disk usage to ensure enough space for the backup and deployment files.
- Review logs for existing warnings before the update.
- Confirm file permissions on JSP and upload directories.
- Check the active Java runtime and Tomcat service status.
- Validate that any custom app server settings are still intact.
These checks help you avoid deploying into an already unstable environment and make troubleshooting easier if something goes wrong.
Common mistakes to avoid
Teams often run into problems because the backup process is rushed or incomplete. Avoid these common mistakes:
- Backing up only the changed JSP file instead of the full application.
- Skipping the database backup when the app stores user or transactional data.
- Forgetting to save Tomcat or Java-related settings.
- Deploying before confirming that the backup finished successfully.
- Using unclear backup names that are hard to identify later.
- Assuming a code rollback alone will fix a data-related issue.
For JSP hosting, application code and runtime configuration are closely connected. A safe rollback plan should reflect that.
When to create the backup
The best time to create the backup is immediately before the deployment window begins. If the update is large or split into multiple steps, create a new backup before each major release phase. This is especially useful if you are changing both JSP logic and database structure.
In practice, a good update flow is:
- Review the release notes and files to be deployed.
- Create the Plesk backup.
- Save the database dump if needed.
- Upload the new JSP or WAR files.
- Test the application and review logs.
- Keep the backup until the release is confirmed stable.
FAQ
Can I back up only my JSP files and skip everything else?
You can, but it is not recommended for a production deployment. JSP applications often depend on libraries, configuration files, database content, and Tomcat settings. A partial backup may not be enough for a complete restore.
Do I need to back up the database if the update is only in the JSP page?
Yes, if the page reads from or writes to a database. Even a small JSP change can affect queries, form handling, or data formatting. A database backup gives you a safe rollback path if the update exposes a data issue.
What should I do if my JSP app uses My App Server?
Back up the application files, any database used by the app, and the current service configuration. Also note the selected Java and Tomcat version, because restoring the files without the same runtime settings can still leave the app unstable.
Should I restart Tomcat after restoring a backup?
In many cases, yes. Restarting Tomcat or the My App Server service helps ensure that restored JSP pages, compiled classes, and configuration changes are loaded cleanly.
How long should I keep the backup?
Keep it until the deployment has been tested and confirmed stable. For important releases, it is common to retain the pre-update backup until the next successful release cycle.
Conclusion
Creating a backup before deploying a JSP update is one of the simplest ways to reduce risk in Plesk-based hosting. For Java hosting environments with My App Server, this becomes even more important because your application may depend on a specific Tomcat version, Java version, and service configuration. A complete backup should cover the site files, application libraries, configuration, and database content so you can restore the previous working state without delays.
By making backups part of every JSP deployment, you improve reliability, shorten recovery time, and keep troubleshooting under control. In managed hosting, that is usually the difference between a routine update and an urgent incident.