Before updating a JSP application, the safest approach is to back up everything that would be difficult to reconstruct after a failed deploy, config change, or version mismatch. In a hosting environment with Plesk and a managed Java setup such as My App Server, that usually means more than just the JSP files. You should save the application package, server-side configuration, deployment mappings, and any data the application writes at runtime.
A proper backup lets you roll back quickly if the new build breaks compilation, changes servlet behaviour, or causes an Apache Tomcat startup problem. It also helps when a release looks fine in testing but fails under real traffic or after a Java version change.
What to back up before updating a JSP application
For most JSP, Servlet, and Tomcat-based applications, back up these components before you deploy a new version:
- The application source code if you maintain the project on the server or need to reproduce the build.
- The deployed WAR file or the current exploded application directory.
- JSP pages, servlets, tag files, and static assets such as CSS, JavaScript, images, and downloads.
- Configuration files like
web.xml, context descriptors, environment property files, and custom XML/JSON config. - Tomcat and JVM-related settings that affect the app, including memory parameters, Java version, and startup options.
- Database schema and data if the release may change tables, queries, or stored records.
- Uploads and generated content stored by the app outside the web root.
- Logs from the current version, especially access logs and application logs needed for troubleshooting.
- SSL and domain mappings if the app depends on specific hostnames, virtual hosts, or HTTPS settings.
- Any custom scripts or scheduled tasks tied to the application release.
Why a JSP backup needs more than the code
JSP applications often depend on a mix of files and runtime settings. A deployment can fail even when the code itself is correct. For example, a new build may require a different Java version, a changed servlet mapping, a new database connection string, or an updated class library. If you only back up the source files, recovery can still be slow because you may have to rebuild the exact runtime state.
In a hosted Tomcat environment, the safest rollback point is usually a full snapshot of the application as it existed right before the update. That snapshot should include:
- the deployed artifact,
- the config used by the current version,
- the data it relies on,
- and the service settings in Plesk or My App Server.
This is especially important for JSP hosting where a small change in a class library or servlet mapping can affect page rendering, session handling, or login flows.
Backup checklist for My App Server and Plesk
If you are using ITA’s Java hosting with My App Server, use this checklist before clicking update:
1. Save the current deployed application
Download or archive the current WAR file if your app is deployed as a packaged application. If it runs as an exploded deployment, copy the full application directory so you preserve the exact structure currently running in Tomcat.
2. Export application configuration
Back up all configuration files that control application behaviour. Common examples include:
web.xml- context descriptors
- database property files
- logging configuration
- mail settings
- feature flags
- integration endpoints
If the app stores configuration outside the deployment folder, back up that location too. Many JSP applications use environment-specific settings that are easy to overlook during an update.
3. Record Tomcat and Java settings
Before updating, note the active Tomcat version, Java version, and any custom JVM options used by your service. This matters because a JSP application may compile and run differently across Java releases.
Useful settings to record include:
- selected Java version,
- Tomcat version,
- memory limits or JVM heap size,
- startup arguments,
- classpath additions,
- custom environment variables.
In My App Server, these settings help you restore the service to the same runtime state if the new version does not start correctly after deployment.
4. Back up the database
If your JSP application uses a database, back it up before release even when the code change seems minor. A JSP update may introduce new columns, modify validation, or write data in a new format. Always create a database backup if the release includes any of the following:
- new forms,
- authentication changes,
- admin panel changes,
- order processing,
- content management updates,
- reporting logic,
- data migration scripts.
Keep in mind that application rollback is not enough if the database schema has already changed. Backing up data gives you a true recovery path.
5. Save uploaded files and generated content
Many JSP applications store user uploads, cache files, exports, attachments, or generated documents outside the codebase. These files are often more valuable than the app itself because they are user data. Back up any folder that can be modified by the application at runtime.
Typical examples include:
- file upload directories,
- image caches,
- PDF or report exports,
- session-related cache data,
- temporary working files.
6. Preserve current logs
Before updating, archive the latest application logs, access logs, and Tomcat logs. These logs can be essential if the new version fails. They help you compare the old behaviour with the new one and identify whether the issue is related to compilation, deployment, permissions, or a runtime exception.
7. Capture deployment details
Write down how the application is deployed in Plesk or My App Server. Include the domain name, document root, service name, deployed path, and any special mapping between Apache and Tomcat. If you use a custom app server setup, record the exact configuration so you can restore it quickly.
Recommended backup scope by release type
Not every update needs the same level of backup, but lower-risk releases still need a rollback plan. Use the scope below as a practical guide.
Minor JSP content update
If you are changing only a small JSP page or static content, back up at least:
- the changed files,
- the deployed application package,
- current logs.
Code change in servlets or Java classes
For a code update, back up:
- the full app source or source archive,
- the current WAR or deployment folder,
- configuration files,
- logs,
- runtime settings.
Release with database changes
For database-related changes, back up everything above plus:
- full database export,
- schema migration scripts,
- rollback SQL if available.
Release with Java or Tomcat compatibility changes
If the update requires a different Java version or a newer Tomcat build, back up:
- the current service configuration,
- JVM settings,
- the existing deployed application,
- log files from the old runtime,
- any custom libraries added to the service.
How to create a safe rollback point
A rollback point should allow you to return the application to a working state without rebuilding everything from scratch. In practice, that means copying the full running version before any update is applied.
A good rollback point includes:
- the current WAR file or deployed directory,
- the active config files,
- the database backup taken before release,
- the current Tomcat and JVM settings,
- the latest logs,
- a note of the exact version number being replaced.
If possible, keep these backups in a separate location from the application itself. That protects them from being overwritten during deployment.
Common mistakes when backing up JSP applications
Many update problems happen because the backup was incomplete. Watch out for these common mistakes:
- Backing up only JSP files and forgetting Java classes, libraries, or config.
- Skipping database exports when the release affects stored data.
- Ignoring runtime-generated files such as uploads and cache folders.
- Not recording Java or Tomcat version details, which makes restoration harder.
- Overwriting the only backup during deployment instead of keeping a separate copy.
- Forgetting custom service settings in Plesk or My App Server.
- Not testing restore steps before a real incident happens.
If you avoid these mistakes, your release process becomes much safer and rollback becomes much faster.
Practical update workflow before deployment
A simple safer release workflow for JSP hosting can look like this:
- Check the app version currently running in Tomcat.
- Back up the deployed application and its configuration.
- Export the database if the update touches data.
- Save logs and record the active Java version.
- Upload the new WAR or files to a staging path if available.
- Validate the new build with a quick test.
- Switch the live deployment only after the app starts cleanly.
- Keep the old backup until you confirm the release is stable.
This workflow works well in managed hosting because it reduces the chance of downtime and makes the update process easier to reverse.
What to verify after the update
Backups are only part of a safe release. After deploying the new JSP version, verify the most important application functions before deleting the old backup:
- application loads without errors,
- JSP pages render correctly,
- login and session handling work,
- forms submit successfully,
- database reads and writes are correct,
- uploads and downloads work,
- Tomcat service remains stable,
- error logs do not show new exceptions.
For My App Server deployments, it is also useful to confirm that the selected Java version and private JVM settings still match the application’s requirements.
FAQ
Do I need to back up the JSP files only?
No. A JSP application often depends on Java classes, libraries, configuration files, database data, and runtime content. Backing up only the JSP files is usually not enough for a safe rollback.
Should I back up the WAR file before every update?
Yes, if the application is deployed as a WAR. Keeping the current WAR is one of the easiest ways to restore the previous release quickly.
Is a database backup necessary for small JSP changes?
If the change does not affect stored data, a database backup may be less critical, but it is still recommended for any release that touches forms, authentication, content editing, or business logic. When in doubt, back it up.
What if my application uses files outside the web root?
Back up those folders too. Many JSP apps store uploads, exports, images, and cache files outside the deployment directory. These are often part of the live application state.
Do I need to save Tomcat and Java settings?
Yes. In a managed hosting environment, version and JVM settings can affect whether the updated application starts successfully. Save the active configuration so you can restore it if needed.
How long should I keep the old backup?
Keep it until the new version has been tested in production and you are confident the release is stable. For important updates, it is common to keep the previous version until the next successful release.
Conclusion
Before updating a JSP application, back up the deployed application, configuration files, database, logs, uploaded content, and the Tomcat or Java settings that control how the app runs. In a Plesk-based Java hosting setup such as My App Server, this gives you a reliable rollback path and reduces the risk of downtime after deployment.
A good backup is not just a copy of the code. It is a complete snapshot of the application state. If you capture the current WAR, runtime files, service settings, and data before the update, you can recover faster and troubleshoot with confidence if anything changes unexpectedly.