Before you deploy a Tomcat update, it is best practice to create a backup of both your application files and the current Tomcat configuration. In a Plesk-based hosting environment, this gives you a safe rollback point if the new version changes behaviour, breaks a JSP/Servlet app, or requires adjustments to the runtime setup. A backup is especially important when you are using a private JVM or a custom Tomcat instance managed through My App Server, because the update may affect not only the application itself but also the service configuration, environment settings, and deployment files.
This guide explains how to prepare a reliable backup before updating Tomcat in Plesk, what to include in the backup, and how to verify that you can restore it if needed. It is written for managed Java hosting, Tomcat hosting, JSP hosting, and servlet hosting users who want a practical, low-risk update process.
Why you should back up before a Tomcat update
A Tomcat update can introduce changes in supported Java versions, connector behaviour, memory handling, session processing, or deployment defaults. Even if the update is minor, a Java web application may behave differently after restart. Backups protect you from:
- configuration changes that prevent Tomcat from starting;
- broken WAR deployments after a version switch;
- missing libraries or custom files in the web application directory;
- changes to server.xml, context.xml, or related startup settings;
- unexpected issues with JSP compilation, permissions, or file paths;
- the need to roll back quickly without rebuilding the whole environment.
In a hosting platform where Tomcat is managed from Plesk, a clean backup also makes troubleshooting easier. If the update fails, you can compare the old and new setup instead of guessing what changed.
What to back up before updating Tomcat
The most useful backup is not only the application archive. To make rollback possible, include all parts that define how your Tomcat instance runs.
Application files
Back up the deployed application directory, including:
- WAR files;
- expanded web application folders;
- custom JSP, HTML, CSS, and JavaScript files;
- uploaded documents, images, and user-generated content;
- application-specific libraries in
WEB-INF/lib; - application-specific configuration files.
Tomcat configuration
Save the current Tomcat configuration files used by your service. Depending on the installation, this may include:
server.xml;context.xml;tomcat-users.xmlif used;- JVM startup parameters;
- custom connector settings;
- logging configuration;
- environment variables or service-specific settings.
If you are using My App Server, also note the Java version, Tomcat version, and any custom app server details you selected during installation. These settings are often just as important as the files themselves.
Database backups
If your application uses a database, create a separate database backup before the Tomcat update. Tomcat itself does not store database content, but a deploy can expose issues in the app that affect reads, writes, or migrations. Keep the database dump in the same rollback package.
SSL, proxy, and domain-related settings
If your Tomcat service is connected to a domain in Plesk, save any related settings such as:
- reverse proxy configuration;
- SSL certificates and chain details;
- domain mappings;
- rewrite rules;
- custom ports or path mappings.
These settings may not be part of the Tomcat installation itself, but they can affect how your app is reached after the update.
How to create a backup in Plesk before deploying a Tomcat update
The exact interface depends on your hosting plan and how Tomcat is provisioned, but the general workflow is the same: stop or prepare the service, archive the current files, export configuration data, and verify that the backup is complete.
Step 1: Check the current Tomcat version and app state
Before making changes, confirm which Tomcat version is currently running and whether your application is healthy. In Plesk, open your Java or My App Server tools and check:
- current Tomcat service status;
- installed Java version;
- deployed application name and path;
- any custom startup flags or service parameters;
- recent log messages related to startup or deployment.
Taking a short note or screenshot of these details helps if you need to compare behaviour after the update.
Step 2: Put the application in a safe state
If the application is actively handling traffic, choose a low-traffic window if possible. For a simple update, you may only need to stop the Tomcat service briefly. In a managed hosting context, this reduces the risk of file changes during the backup.
If stopping the service is not suitable for your case, at least ensure that no deployment is running and no files are being written continuously.
Step 3: Back up the application directory
Use the file manager in Plesk or an SSH session if available to create an archive of the current application directory. Include the deployed web root and any custom folders outside it that belong to the app.
A practical backup structure can include:
- the current WAR file;
- the expanded app directory;
WEB-INFcontents;- upload directories;
- static assets;
- custom config files.
If your application uses symbolic links or external directories, document those paths as well. A restore is much easier when you know which files were linked versus copied.
Step 4: Save Tomcat configuration files
Copy the relevant Tomcat configuration files to a separate backup folder. If you are unsure which files matter, the safest approach is to save the entire Tomcat configuration set associated with the service.
For example, keep a snapshot of:
- connector and port settings;
- memory and JVM options;
- custom context definitions;
- deployment descriptors used by the current instance.
For My App Server users, also export or record the Plesk service settings that define how the private JVM and Tomcat instance are started and managed.
Step 5: Export the database
If your Java application depends on a database, create a fresh SQL dump before the update. This is important even for a minor Tomcat upgrade, because a failed deployment may require a complete rollback, not just restoring files.
Make sure the database backup matches the application version you are currently running. If you keep app files and database dumps together, label them with date, time, and Tomcat version.
Step 6: Save the logs you may need later
Logs are often overlooked, but they are very useful when comparing pre-update and post-update behaviour. Before you change anything, save the latest Tomcat logs and any related application logs.
In particular, keep:
- startup logs;
- deployment logs;
- error logs;
- access logs if relevant to the issue;
- recent stack traces or warning messages.
If the update introduces a problem, these logs can quickly show whether the issue is related to Java compatibility, missing classes, or configuration differences.
Step 7: Package everything into one rollback set
For easier recovery, store the backup as one clearly named set. A good naming pattern includes:
- application name;
- date of backup;
- current Tomcat version;
- Java version;
- environment label if you have more than one instance.
Example: myapp_tomcat10-java17_backup_2026-04-22
This makes it easier to identify the correct restore point when you are working in a hosting panel with multiple services.
Recommended backup checklist for Tomcat updates
Use this checklist before you deploy the new version:
- current application files copied;
- WAR package saved;
- Tomcat configuration files exported;
- JVM options recorded;
- database dumped;
- SSL and domain settings noted;
- Tomcat logs downloaded or archived;
- backup tested for completeness;
- restore location clearly identified;
- update window planned.
If you manage several Java applications, keep a separate backup folder for each one. This avoids confusion when multiple WAR files or custom contexts are involved.
How this works with My App Server in Plesk
ITA’s My App Server extension is designed for practical Java hosting in Plesk. It allows you to install and manage your own Apache Tomcat or private JVM inside a shared hosting account, which is useful for JSP, servlet, and smaller Java web applications. Because the service is controlled inside Plesk, you can usually manage the update process in a more structured way than on a manually maintained server.
Before deploying a Tomcat update in this setup, the safest approach is to back up both the app and the service definition. That means:
- copying the current app files from the hosting account;
- saving the Java/Tomcat version details;
- preserving the service control settings;
- recording any custom app server configuration;
- keeping the existing logs and database dump.
This is especially useful when you use one of the ready-made Tomcat versions installed with a button, because a version change may also affect JVM compatibility or the location of configuration files. If you uploaded a custom version manually, a full backup is even more important because the deployment layout may be unique.
What to do before you click deploy
Before starting the update, review the following points:
- Is the new Tomcat version compatible with your current Java version?
- Does your application depend on deprecated APIs or old servlet behaviour?
- Are there custom session, cache, or upload settings that might need adjustment?
- Have you tested the new version in a staging or non-critical environment?
- Do you have a clear rollback plan if the app fails after restart?
If any of these answers are unclear, do not skip the backup. A few extra minutes spent preparing the rollback set can save a lot of time later.
How to verify that the backup is usable
A backup is only valuable if it can be restored quickly. After creating it, confirm the following:
- the archive opens without errors;
- the WAR file is intact;
- the application directory contains the expected subfolders;
- the configuration files are readable;
- the database dump is not empty and was created recently;
- the backup filename clearly identifies the version;
- you know where to upload or restore it if the update fails.
If possible, keep a test restore procedure documented in your internal notes. For managed hosting, this is often the fastest way to reduce downtime when something changes after a Tomcat update.
Common mistakes to avoid
Several backup mistakes are very common during Tomcat maintenance:
- backing up only the WAR file and ignoring configuration;
- forgetting uploaded files or user content outside the web root;
- not saving the database;
- ignoring Java version changes;
- not recording custom ports or connector settings;
- overwriting the only backup with the new deployment;
- updating without checking logs first;
- not verifying that the archive can be restored.
These mistakes can turn a simple version update into a longer recovery task. A complete backup process prevents that.
FAQ
Should I back up only the WAR file before updating Tomcat?
No. The WAR file is important, but it is not enough for a safe rollback. You should also save configuration files, uploaded content, database data, and any service settings used by the Tomcat instance.
Do I need a database backup if I am only updating Tomcat?
Yes, if your application uses a database. The Tomcat update itself does not modify the database, but if the new runtime exposes an application issue, you may need to restore the app and data together.
What should I back up in Plesk for a Tomcat service?
Back up the application files, Tomcat configuration, JVM settings, logs, and any related domain or SSL settings. If you use My App Server, also note the installed Java and Tomcat versions and the current service control settings.
Can I update Tomcat without stopping the service?
In some cases you can prepare the backup first and then perform the update with minimal interruption. However, for the safest result it is better to stop the service or schedule the change during a quiet period, especially if files may still be changing.
How do I know which configuration files matter most?
If you are not sure, keep the full service-related configuration set. The most important files typically include server.xml, context.xml, user definitions if used, and any files that control ports, connectors, memory, or deployment paths.
What if the new Tomcat version does not start my app?
Use your backup to restore the previous configuration and application files, then check the logs for the exact error. In many cases the issue is caused by a Java compatibility change, a missing library, or a connector setting that must be adjusted.
Conclusion
Creating a backup before deploying a Tomcat update is one of the simplest ways to protect your Java application in Plesk. When you save the application files, Tomcat configuration, database, logs, and service settings together, you create a dependable rollback point. This is especially important in a My App Server setup where you manage your own Apache Tomcat or private JVM inside a hosting account.
If you follow a consistent backup routine before every Tomcat version change, you reduce downtime, make troubleshooting faster, and keep your JSP or servlet application easier to maintain. In managed hosting, good preparation is often the difference between a smooth update and a long recovery.