Before updating a Tomcat application, back up everything that defines how the app runs, not just the WAR file. In a managed hosting environment with Plesk and a service such as My App Server, the safest approach is to capture the application code, the Tomcat runtime settings, the Java version in use, and any data that would be difficult to reconstruct after deployment.
This matters because a Tomcat update can change class loading, session handling, connector settings, framework compatibility, and application startup behavior. If something breaks, a good backup lets you restore the previous release quickly and reduce downtime. For UK hosting customers managing Java, JSP, servlet, or WAR-based applications, a clear backup checklist is one of the most practical ways to support a safer release workflow.
What you should back up before updating a Tomcat application
At minimum, back up the application package, the configuration that controls the Tomcat instance, and any persistent data used by the app. If you are working through a control panel such as Plesk with a Java hosting extension, also save the service settings that define the private JVM or Tomcat setup. This gives you a full rollback path, not only a copy of the deployed files.
1. The deployed application package
Save the current WAR file, expanded application directory, or any other deployment artifact you are using. If your release process uploads a new WAR, keep the last known working version in a separate location before you replace it.
Back up:
- The active WAR file
- The exploded application directory, if your Tomcat setup uses one
- Any custom JAR files shipped with the app
- Static assets such as images, uploaded files, and front-end resources
If your application is deployed with a versioned folder structure, keep the previous release folder intact until the new version has passed validation. That makes rollback much faster than rebuilding from source.
2. Tomcat configuration files
Tomcat rarely fails because of the WAR alone. In many cases, the problem is a changed connector, context path, memory setting, or environment variable. Back up the relevant configuration files before the update so you can restore the same runtime behavior if needed.
Common items to preserve include:
server.xmlcontext.xmlweb.xmlif you have application-level overrides- Custom connector or SSL-related settings
- JVM memory options such as heap and metaspace values
- Environment variables and system properties
In a hosted setup, some of these settings may be managed through the control panel rather than edited directly on the server. Make a note of where each setting lives so you can restore it accurately after the update.
3. Java version and JVM options
Tomcat applications can behave differently across Java versions. Before updating the app, record the exact Java version and the JVM options currently assigned to the service. This is especially important if your application depends on older libraries, deprecated APIs, or specific garbage collection behavior.
Back up or document:
- Java major version in use
- Any custom JVM arguments
- Encoding settings
- Timezone settings
- Memory limits and startup parameters
If your hosting plan allows multiple Java versions to be installed or selected from Plesk, verify whether the update is being tested under the same Java runtime that runs in production. A release that works in one Java version may fail in another.
4. Application configuration files
Most Tomcat applications store important settings outside the main WAR, either in external property files, XML files, YAML files, or environment-specific configuration directories. These files often contain database credentials, API keys, endpoint URLs, feature flags, and other settings that are not part of the codebase but are essential to application startup.
Back up all external configuration used by the app, including:
application.propertiesor similar property files- Environment-specific config files
- Logging configuration
- Cache or session-related settings
- Mail, database, and third-party integration settings
If you are using separate development, staging, and production values, ensure you back up the production-specific version, not only the template.
5. Database data and schema
If the application stores information in a database, back up the database before deploying any update that could change data structures or business logic. This is one of the most important parts of the rollback plan because code changes and database changes often need to be restored together.
Back up:
- Database dumps or snapshots
- Schema definitions
- Migration scripts already applied
- Stored procedures, views, and triggers if relevant
When possible, record the database version and the exact migration state before the release. If the update includes schema changes, confirm whether they are reversible. Some database changes can be rolled back only with a restore from backup.
6. Uploaded files and user-generated content
For many Tomcat applications, user content is more important than the application code itself. Uploaded documents, images, attachments, and cached exports can be lost if the app update changes storage paths or file handling logic.
Make sure you back up:
- User uploads
- Media folders
- Generated PDFs or reports
- Temporary files that may still be needed during rollback
- Any custom storage directories outside the web root
Do not assume these files are included in the WAR. They are often stored separately and must be backed up explicitly.
7. Logging and diagnostic files
Logs are not part of the rollback itself, but they are extremely useful when the new release does not behave as expected. Before making changes, keep a copy of the recent Tomcat logs and application logs so you can compare “before” and “after” behavior.
Useful files include:
- Tomcat access logs
- Application error logs
- Catalina or service logs
- Any custom audit logs
These files can help identify whether the issue is caused by deployment, configuration, permissions, dependency changes, or a startup failure.
8. SSL, domain, and routing-related settings
If your application relies on HTTPS redirects, reverse proxy rules, or host-based routing, back up the settings that connect the Tomcat app to the domain. In a Plesk-based hosting environment, this may include web server directives, proxy rules, and domain-level configuration tied to the app.
Save any relevant:
- Apache proxy rules
- Domain or vhost configuration
- SSL certificate references
- Redirect rules
- Header or rewrite settings
These items are often overlooked, but they can cause the application to appear broken even if Tomcat starts successfully.
Recommended backup checklist before deployment
A practical backup plan should be simple enough to repeat before every release. Use a consistent checklist so you do not miss anything when the update is urgent.
- Take a copy of the current WAR or deployed application directory.
- Export or archive Tomcat configuration files.
- Record the Java version and JVM options.
- Back up external configuration files and secrets.
- Create a database backup or snapshot.
- Copy uploaded files and persistent user content.
- Save the latest logs for comparison.
- Document domain, proxy, and SSL-related settings.
- Confirm where the rollback copy is stored.
- Verify that the backup can actually be restored.
For hosted Tomcat environments, the most effective backup is the one you can restore quickly through the same service and control panel you use for deployment.
What to back up in My App Server / Plesk hosted Tomcat setups
If you are using a hosting platform that provides Java hosting through a Plesk extension such as My App Server, the backup scope is slightly broader than a simple file copy. That is because the service may manage a private JVM, Tomcat version, startup options, and deployment path inside the hosting account.
In this setup, back up the following items together:
- The application release package
- The selected Tomcat version
- The selected Java version
- Service configuration and startup parameters
- Custom app server settings created in the control panel
- Deployment path and context configuration
- Database and file storage used by the application
If the app server is installed and controlled through a panel button or service page, save screenshots or notes of the current settings as well. This can be useful when restoring the same setup after a failed release.
Files and settings you should not forget
Some items are easy to miss because they are not part of the visible web application. These are the most commonly forgotten parts of a Tomcat backup:
- Custom JNDI resources
- Datasource definitions
- Session persistence settings
- Scheduled task definitions
- CRON jobs or external triggers
- File permission changes made after deployment
- Symbolic links used by the app
- Environment variables loaded at startup
If these are not backed up, the application may restore from the WAR but still fail in production because a missing dependency or path breaks startup.
How to validate the backup before updating
A backup is only useful if you know it can be restored. Before you update the Tomcat application, confirm that the backup is complete and readable. You do not always need to perform a full test restore in production, but you should at least verify the archive structure and key files.
Follow these checks:
- Open the backup archive and confirm the expected files are present.
- Check the timestamp to ensure it was taken before the change.
- Verify that database dumps are not empty and can be imported.
- Confirm that configuration files match the production environment.
- Make sure the rollback copy is stored in a safe and accessible location.
If your hosting platform supports it, keep one backup outside the live deployment area so it is not accidentally overwritten during the update process.
Rollback planning after a Tomcat update
Backing up before deployment is only half of the safer release workflow. You should also decide in advance how to restore the previous version if the update causes errors. A rollback plan reduces decision-making during an incident and speeds up recovery.
A practical rollback plan should include:
- The exact previous WAR or app directory to restore
- The configuration files that must be replaced
- The database backup needed for consistency
- The service restart or reload step in the control panel
- The validation checks to run after restoring
In a managed hosting setup, the rollback should be simple enough to complete through the control panel and standard service controls, without needing a complex server rebuild.
Best practices for safer Tomcat releases
To reduce risk, pair your backup process with a few release habits that make problems easier to isolate.
- Change one thing at a time when possible.
- Keep the previous release available until the new one is validated.
- Test the update with the same Java version used in production.
- Document any configuration changes separately from code changes.
- Review logs immediately after deployment.
- Confirm app startup, login, and key business flows after the update.
For Tomcat hosting on shared infrastructure, these practices are especially useful because they help you recover quickly without needing enterprise-grade clustering or complex failover design.
FAQ
Do I need to back up only the WAR file?
No. The WAR file is important, but it is usually not enough. You should also back up Tomcat settings, Java version details, external configuration, database data, and any uploaded files or persistent content.
Should I back up Tomcat configuration if it has not changed?
Yes. Even if you do not plan to change the Tomcat configuration, keeping a copy helps if the application update fails because of a runtime or connector issue.
What is the most important backup for a JSP or servlet app?
For JSP and servlet applications, the most important items are the deployed application package, the external configuration, and the database. If the app stores user content, back that up as well.
What should I back up in Plesk before using My App Server?
Back up the deployed application, Java and Tomcat version details, startup parameters, service configuration, domain routing settings, database data, and file-based content. This gives you a full restore path if the update does not work as expected.
How often should I take backups before updating Tomcat applications?
Take a fresh backup before every release that changes code, dependencies, configuration, or database structure. Even small updates can affect startup behavior or data compatibility.
Can I roll back only the application without restoring the database?
Sometimes, but not always. If the update changes stored data or schema, restoring only the application may leave the database in an incompatible state. For safety, plan the rollback around both code and data.
Summary
Before updating a Tomcat application, back up more than the application code. Save the current WAR or deployment folder, Tomcat configuration, Java version and JVM options, external app settings, database data, uploaded files, logs, and any domain or proxy rules connected to the service. In a Plesk-based hosting environment with My App Server, also record the service settings that control the private JVM and Tomcat instance.
A complete backup reduces release risk, supports fast rollback, and helps you validate the update with confidence. For UK hosting customers running Java, JSP, servlet, or WAR-based projects, this is one of the most effective steps in a safer release workflow.