Before updating a JSP application, make a backup of everything that can affect the running app, not just the JSP files themselves. In a managed hosting environment with Plesk and a Tomcat-based Java setup such as My App Server, the safest approach is to protect the application code, deployment package, runtime configuration, and any data that the app changes during normal use. That way, if the new release causes a syntax issue, a classpath conflict, a template problem, or an unexpected data change, you can restore the previous working version quickly.
What should you back up before a JSP update?
The short answer is: back up the full application state, plus anything outside the application that it depends on. For a JSP site or servlet application, that usually includes the WAR file or exploded application directory, configuration files, database exports, uploaded files, and any custom Tomcat or JVM settings used by the site.
If you are updating through a control panel such as Plesk, treat the deployment as more than a file upload. A JSP application may depend on multiple layers: Java version, Tomcat version, context configuration, environment variables, and an external database. A backup plan should cover each of those layers so rollback is possible without guesswork.
Core items to back up first
1. The current application package
Back up the current WAR file or the live application directory before replacing it. If your deployment uses an exploded webapp, copy the whole folder structure, including:
- JSP files
- Servlet classes and libraries
- Static assets such as CSS, JavaScript, and images
- WEB-INF content
- Any custom XML descriptors
This gives you a clean rollback point if the new version fails to start or behaves differently from expected. If you only keep source code in Git but not the exact deployed build, you may not be able to restore the same runtime state quickly.
2. Configuration files used by the application
Back up any application-level settings that are not part of the code repository. Common examples include:
- Database connection files
- Property files
- XML config files
- Security or authentication settings
- Feature flags and environment-specific values
These files often contain production-specific values that differ from development or staging. If the update changes how the app reads configuration, having the current files preserved makes troubleshooting much easier.
3. The database
If the JSP application reads from or writes to a database, back up the database before updating. This is essential even when the release appears to be “frontend only”, because JSP changes often interact with stored data, sessions, content records, or schema-dependent code.
At minimum, capture:
- A full database export
- Any schema migrations planned for the release
- Stored procedures, triggers, or functions used by the app
For safer release workflow, it is best to take the database backup immediately before deployment so the restore point matches the code version that is currently live.
4. Uploaded files and user-generated content
Many JSP applications store uploaded documents, images, attachments, or cached exports outside the code directory. Back these up separately because they are often the hardest items to reconstruct after a failed release. If the application keeps user content under a webroot, ensure the backup includes that location and not just the application source.
This is especially important for applications with file upload forms, content management features, or download generation jobs.
5. Tomcat or My App Server deployment settings
In a My App Server setup, also save the service and deployment settings that define how the application runs. Depending on how your app is configured, that may include:
- Tomcat version in use
- Java version selected for the app
- Context path settings
- JVM arguments or memory options
- Service start/stop configuration
- Any custom server-side variables
If you have adjusted the runtime through the hosting control panel, those changes are part of the working environment and should be treated as backup-worthy configuration.
6. Logs from the current working version
Copy recent application and server logs before the update. Logs help you compare “before” and “after” behaviour when a release goes wrong. Save the most recent Tomcat logs, application logs, and any error traces related to the current version.
Logs are not a substitute for a backup, but they are extremely useful if you need to diagnose whether a new JSP, servlet, or dependency is the cause of a failure.
What to back up depending on your deployment style
If you deploy a WAR file
Back up the exact WAR file currently deployed, plus the extracted application if Tomcat unpacks it. Keep the database backup and any external configuration files in the same rollback set. If your release process replaces the WAR but leaves generated files in place, also preserve the full application directory so you can restore a consistent state.
If you use an exploded application directory
Back up the entire webapp folder, not just selected JSPs. Exploded deployments can include compiled classes, cached data, generated files, and modified resources that are not present in the source tree. Missing one small file can break the application after rollback.
If you changed the Java runtime or Tomcat version
Back up the current runtime selection and any custom settings tied to it. A JSP application that works on one Java version may not behave the same on another. This is particularly relevant when you use a hosting control panel to switch between supported versions or to run a private JVM.
If the app has scheduled jobs or background tasks
Document and back up any scheduler settings, cron-like jobs, or background processing config. These often live outside the main app code and can be overlooked during release planning. If the update changes how a background task writes data, that can affect the visible site even when the JSP pages themselves look unchanged.
Recommended backup checklist before updating JSP
Use this checklist before every update, even for small changes:
- Back up the current WAR file or application directory.
- Export the database.
- Save configuration files and environment-specific properties.
- Copy user uploads and other generated content.
- Record current Java and Tomcat versions.
- Save any custom JVM options or service settings.
- Export or note the current control panel deployment settings.
- Download recent logs for comparison after the update.
If you are managing several JSP sites, use the same checklist for each one. Consistency reduces the chance of missing a critical dependency during a late-night fix.
How this fits a safer release workflow
A safer release workflow is not only about having a backup; it is about being able to restore service quickly if the update introduces a problem. For JSP hosting, that means knowing exactly which version is live, which database snapshot matches it, and how to put the previous Tomcat deployment back in place.
A practical workflow looks like this:
- Take a backup of code, config, and data.
- Deploy the new release to a test or staging location if possible.
- Validate the main pages, login flow, forms, and file upload features.
- Check logs for Java exceptions or servlet startup errors.
- Only then switch the live version.
- Keep the previous backup until the new release is confirmed stable.
In a hosting platform that provides My App Server through Plesk, this workflow is especially practical because you can manage the app, service, and runtime from one place instead of handling everything manually at server level.
Special considerations for JSP, servlet, and Tomcat applications
Compiled classes and dependency jars
Back up any compiled classes and third-party JAR files in use by the application. JSP sites often depend on utility libraries, mail libraries, JSON parsers, or framework JARs. A missing or mismatched dependency can prevent Tomcat from starting the app correctly.
Session-related behaviour
If the update changes session handling, authentication, or user state, make sure you understand whether the old sessions can survive a rollback. If not, schedule the update carefully and notify users if needed. Session data itself is usually not part of the file backup, but the code and configuration that manage it definitely are.
Generated content and cache
Some JSP applications generate cached pages, thumbnails, or temporary files. Decide whether these should be backed up or cleared before the release. In many cases, the safest choice is to preserve them for rollback and clear them only after the new version is confirmed stable.
Custom error pages and rewrite rules
If your app uses custom error pages, proxy rules, or Apache/Tomcat routing settings, back those up too. A small change to URL handling can make pages look broken even if the JSP code itself is fine.
Suggested backup location and naming
Store backups in a separate location from the live application. Use clear names that show the date, application, and version. For example, a backup set should let you quickly identify the live release you are preserving and the update you are testing.
A simple naming approach helps with rollback:
- application-name-before-update-date
- database-export-date
- tomcat-config-date
- upload-data-date
Keep the backup set together so that code, data, and runtime settings can be restored as one unit if required.
Common mistakes to avoid
- Backing up only the JSP files and ignoring the database.
- Saving source code but not the exact deployed WAR.
- Forgetting uploaded files or generated content.
- Overlooking custom Tomcat or Java settings in the control panel.
- Deploying a new version before checking whether the old runtime is documented.
- Deleting the previous release too soon.
These mistakes are common because a JSP app often appears simple on the surface, but its runtime dependencies are broader than the visible web files.
Practical example
Suppose you are updating a JSP application that runs on a private Tomcat instance through My App Server. The release adds a new form, updates a few JSP pages, and changes one database query. Before the deployment, you should back up the current WAR, the application properties file, the database export, the uploads folder, and the current Java/Tomcat service settings from Plesk. After the update, you test the login, form submission, file upload, and error handling. If the new query causes failures, you can restore the previous WAR and database snapshot without rebuilding the environment from scratch.
This approach reduces downtime and avoids uncertainty, especially when the app uses production data and live traffic.
FAQ
Do I need to back up JSP files if I already have source control?
Yes. Source control is useful, but it may not include the exact files, dependencies, generated content, or runtime state currently deployed on the hosting account. Always back up the live release before updating it.
Should I back up the database even for a minor JSP change?
Yes, if the app uses a database. Even minor UI changes can affect form submission, validation, or stored data. A database backup is a standard part of a safer release workflow.
What if my JSP app uses uploaded files stored outside the app folder?
Back up that upload directory separately. These files are often critical and can be missed if you only export the web application folder.
Do I need to save Tomcat settings in Plesk?
Yes. If your app uses custom Java version selection, JVM memory options, service control settings, or context configuration, save them before the update. They are part of the working environment.
How long should I keep the old backup after updating?
Keep it until the new version has been tested and confirmed stable. For business-critical sites, many administrators keep the previous known-good backup until the release has been used successfully for a reasonable period.
Is a file backup enough for a JSP application?
No. A JSP application usually depends on code, configuration, Tomcat settings, and data. For reliable rollback, back up all of them together.
Conclusion
Before updating a JSP application, back up the deployed application package, configuration files, database, uploaded content, and any Tomcat or My App Server settings that affect runtime behaviour. In a Plesk-managed Java hosting environment, this gives you a clear rollback path and reduces release risk. The safest updates are the ones you can reverse quickly if something unexpected happens.
If you treat each JSP release as a full stack change, not just a file upload, your deployment process becomes more predictable and much easier to support.