Before updating a Tomcat application, make a backup of everything you would need to restore the app quickly if the new release fails, behaves differently, or exposes a deployment issue. In a hosted Java environment with Plesk and a managed Tomcat setup such as My App Server, the safest approach is to protect both the application files and the runtime configuration that makes the app work in your account.
A good backup is not only about the WAR file. For a Tomcat-hosted application, you should also preserve the deployed web application directory, configuration files, uploaded content, environment-specific settings, and any database data or external resources that the application depends on. This is especially important when you run a private JVM or a separate Tomcat instance inside a shared hosting account, because the application may be tied to specific paths, service settings, and Java versions managed through the control panel.
What to back up before a Tomcat update
The exact backup set depends on how your application is deployed, but in most Tomcat hosting and JSP/servlet hosting scenarios you should back up the following items before making changes:
- The current WAR file or build artifact you deployed.
- The exploded application directory if Tomcat has unpacked the WAR.
- Application configuration files such as properties, XML, JSON, YAML, or .env-style files.
- Custom context configuration, including context.xml or any connector-related settings if you use them.
- Uploaded files and user content stored outside the build.
- Database backups or a known-good export if the app uses MySQL, MariaDB, PostgreSQL, or another database.
- Logs from the current working release for troubleshooting after the update.
- Java runtime and Tomcat version details used by the app, if you may need to roll back to the same stack.
- Any custom scripts used to start, stop, or initialize the application.
If your app uses external services, also save the relevant connection details and integration settings, such as API endpoints, webhooks, scheduled jobs, SMTP settings, and storage credentials, if they are stored locally in the hosting account.
Why a Tomcat backup matters before deployment
Tomcat updates can fail for many reasons even when the code change itself looks small. A new build may introduce a missing class, a changed configuration key, a session handling issue, or a dependency conflict with the current Java version. In a managed hosting environment, the safest rollback is often restoring the previous build and its matching configuration rather than trying to diagnose everything after the application is already live.
Backups are also useful for validation after deployment. If the new release behaves strangely, you can compare the new files with the previous version, confirm whether the issue is in code or configuration, and restore service much faster. That is the core idea behind a safer release workflow: reduce the chance that a routine update becomes a service incident.
Backup checklist for Tomcat hosting in Plesk
1. Save the deployed application package
Keep a copy of the exact WAR file or build you are replacing. If your deployment process unpacks the application, also preserve the unpacked folder so you can compare the previous file structure with the new one. This is especially useful if the application includes JSPs, static assets, or server-side classes that may have changed independently of the package name.
2. Back up configuration files outside the build
Many Tomcat applications rely on configuration files that are not part of the code repository or WAR. Examples include database connection files, mail settings, upload directories, OAuth client settings, and environment-specific properties. These files are often edited directly in the hosting account and can be overwritten during deployment if you do not keep a separate copy.
In a Plesk-based setup, it is a good practice to document where each configuration file lives and whether it is managed by the application, the control panel, or a manual step in your release process.
3. Preserve uploaded content and persistent storage
If users upload documents, images, or other files, those files should be backed up separately from the application code. A new deployment should not remove customer content. The same applies to cached files, generated reports, attachments, and any persistent directories that your Tomcat application writes to during normal use.
Check whether your app stores files inside the web root, under the application directory, or in a custom path. Only backing up the WAR is not enough if the runtime data lives elsewhere.
4. Export the database before the update
Most Tomcat applications use a database for users, content, sessions, or application state. Before updating, make a current database backup or export that matches the application version you are about to replace. If the release includes schema changes, a rollback may also require rolling back the database or restoring a copy taken before the migration.
For safer release workflow, always note whether the deployment is:
- Code-only, where no database changes are included.
- Code plus schema update, where the app and database must stay in sync.
- Data migration release, where rollback may be limited unless you keep a separate pre-update database copy.
5. Record the current Tomcat and Java versions
When using My App Server or a similar Java hosting solution, the application may run under a specific Tomcat version and a specific Java version. Before updating, write down the active stack. If you later need to restore the app, this information helps you recreate the same runtime conditions and reduces the risk of version-related issues.
This is particularly important when you can select from several ready-to-install Tomcat or Java versions, or when you manually upload and configure a custom application server. A build that works on one Java release may not behave the same on another.
6. Keep logs from the current working release
Logs are often overlooked, but they are one of the most useful pre-update backups. Save the current Tomcat logs, application logs, and any error output related to the live version. If the new release starts failing, these logs make it easier to compare what changed and identify the point where startup or request handling broke.
Useful log files may include:
- Tomcat startup and shutdown logs
- Application error logs
- Access logs, if enabled
- Deployment or install logs from the control panel
What to back up if you use My App Server
In the ITA Java hosting context, My App Server lets you manage a private Tomcat/JVM setup inside your hosting account through Plesk. That gives you practical control, but it also means you should back up the parts that are specific to that service before updating an application.
For a My App Server deployment, back up:
- The current application package and deployed files.
- Any custom app server settings you changed in Plesk.
- The selected Java version and Tomcat version details.
- Service-related settings such as startup options or memory-related values, if you adjusted them.
- Custom paths used by the app, especially for uploads and logs.
- The database and any scheduled jobs tied to the application.
If you use a ready-made Tomcat version, a rollback can be relatively straightforward. If you use a custom app server configuration, keep enough notes to recreate it exactly. Even small changes in JVM options or service settings can affect startup behavior after a deployment.
Recommended pre-update workflow
A simple release routine lowers risk and makes recovery easier. Before you deploy a new version of your Tomcat application, follow this sequence:
- Identify the current release and confirm the app is healthy.
- Take a file backup of the WAR, unpacked app directory, and persistent content.
- Export the database if the app uses stored data or schema changes.
- Save configuration files and runtime settings outside the build.
- Record the active Java and Tomcat versions used by the app.
- Pause writes or maintenance-sensitive actions if the application requires it.
- Deploy the new build through your normal control panel or release process.
- Validate startup and basic functionality before calling the release complete.
If the application is mission-critical, keep the old release available until you have confirmed that logins, core pages, forms, background tasks, and database connectivity all work as expected.
Good rollback backups are version-aware
Not every backup is equally useful. A rollback backup should be tied to the exact release you are replacing. That means storing the old WAR with a version label, keeping the corresponding database export, and noting any manual changes that were applied after deployment.
For example, if you deployed version 2.4.8 of a servlet application and later plan to move to 2.5.0, a useful backup set would include:
- The 2.4.8 WAR file.
- The 2.4.8 unpacked web app directory, if applicable.
- The database export taken before the 2.5.0 schema changes.
- The config files used by 2.4.8.
- Notes about the Java version and Tomcat version used by 2.4.8.
This makes rollback more predictable than trying to reconstruct an old state from memory after the update has already caused trouble.
What not to rely on as your only backup
Do not assume that source control, a build artifact repository, or the hosting platform alone is enough. Those tools are helpful, but they do not always preserve the runtime state of the application. Source control usually does not include uploaded files, local environment values, or database contents. A package repository may not reflect the exact file set that is currently live in production.
Also avoid relying only on a “redeploy from scratch” plan unless you have already tested that the application can be restored quickly. In Tomcat hosting, the safest backup is the one you can actually use to return to a known-good state without guessing.
Practical examples
Example 1: Updating a WAR-based JSP application
You are about to replace an existing WAR file with a new build. Before deploying, download the current WAR, copy any external config files, export the database, and save the current Tomcat logs. After the update, check that the app starts cleanly and that JSP pages render as expected. If there is a problem, restore the old WAR and config together rather than only the WAR.
Example 2: Updating a servlet app with uploaded files
Your application stores user uploads in a separate folder outside the web root. In this case, backing up the WAR is not enough. You need the uploads directory, the config that points to it, and the database record set that references those files. Without all three, restoring the app may bring the code back but still leave user content missing.
Example 3: Changing Java or Tomcat alongside the app
If the update also includes a Java version change or a switch to a different Tomcat version in My App Server, keep the previous runtime details. If the new release fails, you may need to return to the older Java level as well as the older application build. That is why runtime backups and notes matter as much as file backups.
FAQ
Should I back up only the WAR file?
No. The WAR file is important, but it is usually only one part of a complete backup. Also save configuration files, persistent content, database data, and any runtime settings that the application needs.
Do I need a database backup if the update only changes JSP files?
If the app truly has no data changes and the release is limited to static pages or JSP presentation logic, a database backup may not be necessary. However, if the app reads or writes data, or if you are not fully sure, taking a fresh export is the safer choice.
What should I back up in a Plesk-managed Tomcat setup?
Back up the deployed application, uploaded files, local configuration, logs, database exports, and any My App Server or Tomcat settings that you changed. Also record the Java and Tomcat versions currently in use.
How long should I keep the previous release?
Keep it until the new version has passed your validation checks and you are confident that there are no hidden issues. For applications with a wider release window, it is common to keep at least one known-good version available for quick rollback.
Can I restore only the app files and ignore the configuration?
Usually not. If the app depends on custom properties, context settings, or upload paths, restoring only the code can leave the application broken or partially functional. A reliable rollback includes the matching configuration and data.
Is this the same for every Tomcat application?
The exact files differ from app to app, but the principle is the same: back up whatever defines the live state of the application, not just the code package. In Tomcat hosting, that usually means the build, config, data, and logs.
Final checks before you deploy
Before you update a Tomcat application, confirm that you have a restorable copy of the current release and all of its dependencies. In a managed hosting environment with My App Server, that means protecting the application package, configuration, data, logs, and runtime details together. This small amount of preparation can save a great deal of time if the new release needs to be rolled back.
A safe update is not just about uploading a new file. It is about being able to return to the previous working state quickly and with confidence. For Tomcat hosting, that is the difference between a routine deployment and a long outage.