If you are about to deploy a Java update in Plesk, the safest approach is to create a backup first and verify that you can restore it quickly if anything breaks. This is especially important for Java hosting, Tomcat hosting, JSP applications, and servlet-based sites where a new Java version, JVM setting, or application update can affect startup, runtime behaviour, or session handling.
In a managed hosting environment, a backup gives you a rollback point before you change the Java runtime, update your WAR file, adjust your private JVM, or replace a Tomcat version through My App Server. For UK hosting customers, this is a practical way to reduce downtime and avoid losing application files, configuration, or database data during deployment.
Why you should back up before a Java update
Java updates can be low risk when your application is simple and well tested, but even a minor change may affect libraries, frameworks, startup scripts, or application behaviour. A backup helps you recover quickly if the update causes errors such as:
- Tomcat failing to start after a Java version change
- JSP pages showing compilation errors
- Servlets or webapps behaving differently after a JVM update
- Changes in configuration files being overwritten during deployment
- Database connection issues caused by updated drivers or environment settings
- Accidental removal of application files during upload
If you use Plesk with My App Server, a backup is also useful before changing the Java version selected for the service, replacing a private JVM, or reinstalling a Tomcat instance. For smaller and medium-sized Java applications, that rollback option is often the difference between a quick fix and a prolonged outage.
What you should back up before deploying
A proper pre-deployment backup should cover more than just the web files. For Java hosting on Plesk, make sure you include the items that are relevant to your application and deployment method.
Core files to include
- Application source or build output - such as WAR files, JSP files, class files, or the full project export if you deploy manually.
- Configuration files - such as
server.xml, context files, custom properties, environment files, and any application-specific configuration. - Tomcat-related files - if you use My App Server or a custom app server setup, back up the service configuration and any custom startup settings.
- Static content - images, CSS, JavaScript, and uploaded user files.
- Database data - export your database separately if the Java app depends on MySQL, MariaDB, PostgreSQL, or another database.
- SSL and domain settings - if your deployment affects the hosting subscription, virtual host configuration, or proxy settings.
Important Plesk and hosting settings
If your Java application is managed through Plesk, also note the current service details before making changes. Record the selected Java version, deployed app path, startup command, context path, and any service control settings. This will make recovery easier if you need to restore the previous state.
How to create a backup in Plesk before deploying a Java update
The exact interface can vary slightly depending on your Plesk setup and hosting plan, but the general process is the same. The goal is to create a complete snapshot of the site or subscription before you change the Java runtime or deploy a new application build.
Step 1: Log in to Plesk
Sign in to your Plesk control panel and open the subscription or domain where your Java application is hosted. If you manage multiple sites, confirm that you are working on the correct one before you create the backup.
Step 2: Open the backup tool
In Plesk, go to the backup section for the subscription or domain. Depending on your permissions and hosting setup, you may see options for:
- Backup Manager
- Server backups
- Subscription backups
- Scheduled backup settings
For a pre-deployment backup, choose a manual backup so you can create the restore point immediately before the Java update.
Step 3: Choose the backup scope
Select the items that matter for your Java application. For most hosting setups, it is best to include:
- Website files
- Mail data if the domain uses mailboxes related to the application
- Databases used by the app
- Configuration files and hosting settings
If you only need to protect the Java application itself, you may focus on the domain files, the application folder, and the database. However, if your deployment changes multiple parts of the site, a full subscription backup is safer.
Step 4: Decide whether to include the backup in the server storage or external storage
If your hosting plan supports it, store the backup in a safe location that will still be available if the deployment fails. Internal backup storage is convenient, but if you have external or remote backup options, they can provide additional protection.
For a simple rollback plan, make sure the backup is accessible from your Plesk account and that you know how to restore it.
Step 5: Start the backup and wait for completion
Launch the backup job and let it finish completely before you change anything in the Java environment. Do not begin the deployment until the backup is marked as successful.
If the backup fails, do not continue with the Java update until the issue is resolved. A failed backup means you do not have a reliable rollback point.
Step 6: Download a local copy if possible
For important deployments, it is wise to download a copy of the backup to your local machine or another secure location. This gives you an extra recovery option if you need to inspect files or restore specific content later.
Using My App Server with a Java deployment backup
If your hosting account includes My App Server, you can manage a private JVM and Tomcat instance from within Plesk. This is useful for Java web applications that need a dedicated runtime without the complexity of a full enterprise application platform.
Before updating Java, Tomcat, or the application itself, back up the service configuration and deployment files used by My App Server. In practical terms, this means saving the data that controls how your app starts, which Java version it uses, and where the application is deployed.
What to note before you change the Java version
- Current Java version used by the app server
- Tomcat version, if applicable
- Application context path
- Deployed WAR location or application directory
- Any custom JVM options
- Service start and stop state
With this information, you can restore the previous configuration quickly if the new Java version is not compatible with your application or libraries.
Why this matters for Tomcat hosting
Tomcat-based applications often rely on exact version behaviour, especially when they use older frameworks, specific servlet APIs, or legacy JSP compilation settings. A backup lets you test the update while keeping a safe fallback. That is particularly useful in shared hosting environments where you manage your own application stack but still want control through Plesk.
Best practice checklist before deploying a Java update
Before you update Java, Tomcat, or the application package, use this checklist to reduce risk:
- Create a full backup of the site or subscription
- Export the database separately if the app uses one
- Record the current Java version and service settings
- Save custom configuration files and environment variables
- Check which WAR, JSP, or servlet files will be replaced
- Review recent application logs for existing errors
- Confirm that you can restore the backup in Plesk
- If possible, test the update in a staging environment first
This checklist is especially useful when you manage multiple releases or deploy changes frequently. Even a small update can affect startup timing, memory use, or compatibility with third-party libraries.
How to reduce downtime during the update
Backups help you recover, but careful deployment helps you avoid needing the backup at all. If your application has traffic, consider the following practical steps:
- Deploy during a low-traffic window
- Keep the old build available until the new one is verified
- Restart the service only after the new files are in place
- Check logs immediately after deployment
- Verify the home page, login flow, form submission, and database connectivity
If your hosting setup supports it, run a quick smoke test after the Java update. For example, confirm that the app loads, JSP pages compile correctly, and key servlet actions return expected results. This is a fast way to catch compatibility issues before users do.
How to restore a backup if the Java update fails
If the update breaks the application, restore the backup as soon as possible. In Plesk, open the backup manager, select the latest known-good backup, and restore the files, configuration, and database as needed.
After restoring:
- Revert the Java version to the previous working release
- Restore Tomcat or My App Server settings if they changed
- Check file permissions if the application cannot read or write files
- Restart the service and test the site again
- Review logs for the original error cause before retrying
If you changed only part of the stack, such as the WAR file or a configuration file, you may not need a full rollback. In some cases, restoring only the application directory or database is enough. Still, a full backup gives you the flexibility to choose the right recovery path.
Common mistakes to avoid
Java updates are often rushed, and most problems come from skipping the basics. Avoid these common mistakes:
- Deploying without a verified backup
- Updating Java and application code at the same time without testing
- Forgetting to back up the database
- Not recording the previous Java or Tomcat version
- Assuming the same build will run on a different JVM without checks
- Restoring files but not restoring related configuration
- Ignoring logs after deployment
In hosting environments where you manage your own Java application through Plesk, small configuration changes can be just as important as the code itself. Backing up both gives you a more reliable recovery path.
When a simple file backup is not enough
For static sites, a file backup may be enough. For Java hosting, that is not always true. Many applications depend on a combination of code, runtime settings, and database state. If you only back up the WAR file, you may still lose the information needed to get the site running exactly as before.
Use a fuller backup approach when the app includes:
- User logins and session-based workflows
- Admin settings stored in a database
- Custom Tomcat or JVM parameters
- Uploaded files or generated content
- Scheduled tasks or background jobs
In these cases, the backup should capture the application state, not just the source files.
FAQ
Should I always create a backup before changing Java in Plesk?
Yes. Even if the update seems minor, a backup is the safest way to protect your files, configuration, and database before changing the Java runtime or redeploying the application.
Do I need to back up the database separately?
In most cases, yes. A full hosting backup may include the database, but it is good practice to confirm this and create a separate database export for important applications.
What should I back up for a Tomcat app?
Back up the WAR file or application directory, configuration files, database data, and any My App Server settings that define the Java version, service state, or deployment path.
Can I restore only part of the backup?
Often yes. You may be able to restore only files, only a database, or only specific subscription data, depending on your Plesk backup options and your hosting permissions.
Is a backup still useful if I am only changing the Java version?
Absolutely. A Java version change can affect compatibility, startup behaviour, memory usage, and library support. A backup gives you a fast way to return to the previous working setup.
Should I test the update before deploying to production?
If you have a staging copy or test environment, that is strongly recommended. A backup protects production, while testing helps you find issues before users are affected.
Conclusion
Before deploying a Java update in Plesk, create a reliable backup of the application files, database, and any Java or Tomcat configuration that affects how the site runs. This is the safest way to protect a Java hosting setup managed through My App Server, especially when you use a private JVM or custom Tomcat instance for JSP, servlet, or WAR-based applications.
A good backup routine reduces risk, shortens recovery time, and makes every Java deployment easier to manage. If the update works, you move forward with confidence. If it does not, you can restore the previous version quickly and keep the service stable.