Before you deploy a Tomcat update, create a full backup of your web space, application files, and any related configuration in Plesk. This gives you a safe rollback point if the new Tomcat version changes how your WAR, JSP, servlet, or Java application behaves after restart.
In a managed hosting environment, a Tomcat update can affect more than the application itself. It may also impact the Java runtime, service settings, startup parameters, deployed files, and any custom changes you have made in Plesk. A recent backup is the simplest way to reduce downtime and avoid data loss when you update a private JVM or Apache Tomcat instance through My App Server.
Why you should back up before a Tomcat update
A Tomcat update can introduce version changes in the servlet container, JSP compilation, session handling, Java compatibility, or startup behaviour. Even when the update is routine, the safest approach is to create a backup first and verify that you can restore it if needed.
- Protect application files in case the update or restart exposes a deployment issue.
- Preserve configuration such as context settings, custom environment variables, and service options.
- Reduce recovery time if the application fails to start after the update.
- Keep a rollback path for your WAR, JSP, and servlet files.
- Safeguard related data including uploaded files, logs, and database exports if your application stores them in the account.
If you use Plesk-based Java hosting, a backup is especially useful before changing the Tomcat version inside the hosting account. It helps you compare behaviour before and after the upgrade and revert quickly if the new version is not compatible with your app.
What to back up before deploying a Tomcat update
For most Tomcat hosting setups, the best backup includes both files and configuration. The exact scope depends on how your application is deployed and what has been customised in Plesk or My App Server.
Core items to include
- Application files — WAR files, exploded application directories, JSP files, static resources, and Java web app assets.
- Custom Tomcat configuration — any service settings, JVM options, context files, or connector changes you made.
- Logs — helpful for comparing behaviour before and after the update.
- Uploaded content — user files, media, attachments, or generated content stored in the hosting space.
- Database backups — if your Java app uses MySQL, MariaDB, or another database.
- Environment files — credentials, properties files, or external service settings used by the app.
What to check before taking the backup
- Confirm which Tomcat version is currently active.
- Note whether your app uses a custom Java version or default JVM.
- Identify whether the app is deployed as a WAR or as a folder-based application.
- Review any manual changes made through Plesk or file manager.
- Make sure the account has enough disk space for the backup archive.
How to create a backup in Plesk before updating Tomcat
In Plesk, the most practical method is to create a full subscription backup or a partial backup that includes the files and databases used by your Java application. If your hosting plan includes My App Server, use this backup step before you stop the service, switch Tomcat versions, or deploy a new build.
Step 1: Log in to Plesk
Sign in to your Plesk control panel and open the subscription or domain where the Tomcat application is hosted. If you manage several sites, double-check that you are working in the correct domain before making changes.
Step 2: Open the Backup Manager
Go to the backup section in Plesk. Depending on the interface version, this may appear as Backup Manager, Backup & Restore, or a similar menu item under your subscription tools.
Step 3: Choose the backup type
Select either a full backup or a custom backup based on what you need to protect:
- Full backup — best when you want to capture the entire hosting account, including files and databases.
- Selected data backup — useful if you only need the web space, a specific site, or a database connected to the app.
For a Tomcat update, a full backup is usually the safest choice because it captures more of the environment that could affect the app.
Step 4: Include the website files
Make sure the backup includes the directory where your Java application is deployed. If your app uses a WAR file, check that the archive and any extracted contents are included. If the app has a custom deployment folder, include that folder too.
Step 5: Include databases if the app uses them
If the Java application reads from or writes to a database, include the relevant database backup in the same restore point. A Tomcat rollback is not complete if the database state no longer matches the application files.
Step 6: Start the backup and wait for completion
Run the backup and allow it to finish fully before making any Tomcat changes. Do not begin the update while the archive is still being created. When the backup finishes, confirm the status and keep the backup name and timestamp for reference.
Step 7: Download a local copy if needed
If your process requires an off-server copy, download the backup archive to a secure local location. This can be helpful if you want an additional restore option outside the hosting account.
Backing up a My App Server Tomcat setup
If you are using My App Server for Java hosting in Plesk, your update may involve a private Apache Tomcat instance and a dedicated JVM inside the hosting account. In this case, the backup should cover both the application and the service-related changes you have made.
Check the service state first
Before creating the backup, review the current service status in My App Server. If the service is running normally, you can proceed with the backup. If the app is already unstable, capture logs first so you have a baseline for troubleshooting later.
Save your current version details
Record the following items before you deploy the Tomcat update:
- Current Tomcat version
- Current Java version
- Application deployment method
- Custom JVM options
- Context or connector settings
- Any recent manual file changes
This information is useful if you need to restore the previous setup or reproduce it after rollback.
Back up custom app server files
If you uploaded a custom app server or adjusted a manual Tomcat installation, include those files in the backup as well. Custom Java hosting setups often rely on configuration files outside the web root, so check the service directories carefully.
Manual backup method for Tomcat application files
Some developers prefer to create a manual backup in addition to the Plesk backup. This is a good practice if you are about to test a new Tomcat release, especially when the application uses custom code or sensitive configuration.
Files you can copy manually
- WAR file
- Application source or build output
- Configuration files
- Properties files
- Static content and uploads
- Deployment notes and version logs
Useful backup folder structure
To keep the restore process simple, store the files in clearly labelled folders such as the following:
- /backup/app-files/
- /backup/config/
- /backup/database/
- /backup/logs/
Use a timestamp in the folder name so you can easily identify the backup that matches the Tomcat update you are about to deploy.
Recommended backup checklist before a Tomcat update
Use this checklist to make sure your hosting account is ready before changing the Tomcat version or restarting the service.
- Create a Plesk backup of the subscription or domain.
- Export any related databases.
- Copy the WAR file and deployed application directory.
- Save custom JVM and Tomcat settings.
- Capture important log files.
- Confirm the backup can be restored.
- Make a note of the current Tomcat and Java versions.
- Verify there is enough disk space for the update and for rollback.
Completing this checklist helps you avoid common mistakes such as updating first and backing up later, or missing a hidden configuration file that the application needs to start.
What to do after the backup is complete
Once the backup is ready, do a quick validation before deploying the Tomcat update. The goal is to make sure the backup is usable and that you know where to find it if the new version causes issues.
- Confirm the backup completed without errors.
- Verify the archive date and time.
- Check whether the database export is included.
- Ensure the application files are present in the backup.
- Store the restore instructions in a safe place.
If your application is business critical, it is also a good idea to schedule the update during a low-traffic period. That gives you more time to test the new Tomcat version and restore the backup if the application needs to be rolled back.
Common mistakes to avoid
When preparing a Tomcat update in Plesk, a few simple mistakes can make recovery harder than it needs to be.
Backing up only the web files
A file-only backup may not be enough if the app depends on a database or custom Tomcat settings. Always include the parts of the environment that affect runtime behaviour.
Skipping log files
Logs are often the fastest way to identify whether a Tomcat change caused the issue. Save the relevant logs before updating so you can compare the old and new behaviour.
Not checking Java compatibility
Some Tomcat versions behave differently with different Java releases. Before the update, make sure your application is compatible with the Java version used by your hosting setup.
Updating without noting current settings
If you use custom JVM arguments, memory settings, or context parameters, record them first. These options may need to be restored after the update.
Not testing the restore path
A backup is only useful if you can restore it. Make sure you know how to recover the files, database, and service settings if the deployment does not work as expected.
How to restore if the Tomcat update causes problems
If the new Tomcat version does not work correctly, use the backup you created before the deployment. In many cases, the fastest rollback path is to restore the previous files and configuration, then switch the service back to the earlier Tomcat or Java version.
A typical restore process includes:
- Stopping the updated service if necessary.
- Restoring the application files from the backup.
- Restoring any affected database backups.
- Reapplying Tomcat or JVM settings from your notes.
- Starting the service again and checking the application logs.
After restoration, test the main application pages, login flow, form submissions, and any JSP or servlet endpoints that were affected by the update.
Best practice for UK hosting users
For UK hosting customers, the safest approach is to treat every Tomcat update as a controlled change. Even a minor version update can affect a Java app in subtle ways, especially when the deployment uses custom code, session storage, or external connections.
Use the backup as part of a simple change process:
- Review the current Tomcat and Java version.
- Create a full backup in Plesk.
- Save logs and service notes.
- Deploy the Tomcat update.
- Test the application carefully.
- Restore from backup if any issue appears.
This approach works well for small and medium Java web applications hosted through Plesk, especially when you manage a private JVM or Tomcat service through My App Server.
FAQ
Should I back up before every Tomcat version change?
Yes. Even if the update seems minor, it is best practice to create a backup before any Tomcat version change. That includes patch updates and major version upgrades.
Is a Plesk backup enough for a Tomcat deployment?
Often it is, but for Java hosting it is safer to include application files, configuration, logs, and any database used by the app. For custom Tomcat setups, a manual copy of key files is also recommended.
Do I need to back up logs?
Yes, if you want a clear troubleshooting reference. Logs can help you compare errors before and after the update and can shorten recovery time.
What if my application uses a custom Java version?
Then you should record the Java version and any custom runtime settings before deploying the update. Compatibility between Tomcat and Java is important for startup and runtime stability.
Can I restore only the application files?
Yes, if the problem is limited to the deployment files. However, if the application also depends on a database or custom Tomcat configuration, restore those parts as well.
What is the safest backup type before updating Tomcat?
A full subscription backup is usually the safest option because it captures the web space, settings, and databases together. If your hosting environment is simple, a targeted backup may be enough, but full backup is generally better before service changes.
Conclusion
Creating a backup before deploying a Tomcat update in Plesk is one of the most important steps in maintaining a stable Java hosting environment. It protects your WAR, JSP, servlet files, databases, logs, and custom service settings, and it gives you a fast rollback option if the new version does not behave as expected.
If you manage Tomcat through My App Server, make the backup first, record the current Java and service details, then deploy the update only after you know you can restore the previous state. That simple habit can save time, prevent data loss, and keep your hosted Java application running smoothly.