Before deploying a Java update, it is a good practice to create a backup of your application files, configuration, and database. In a Plesk-based hosting environment, this helps you recover quickly if the new Java version, Tomcat configuration, or application build does not behave as expected. This is especially useful when you are running a WAR, JSP, or servlet application through a private JVM or Apache Tomcat instance managed from the control panel.
If you use a hosting platform with Java support such as My App Server, a backup gives you a safe rollback point before you change the Java version, restart the service, or redeploy your application. The process is straightforward, but the exact steps depend on whether you want a full subscription backup or only a backup of the app-specific files and database.
Why you should back up before a Java update
Java updates can affect more than the runtime itself. A newer Java version may change how your application starts, how libraries are loaded, or how the application interacts with Tomcat. Even if the update is minor, problems can still happen after deployment.
Common risks include:
- Application startup failures after switching to a new Java version
- Servlet, JSP, or dependency compatibility issues
- Changes in JVM options, memory settings, or encoding behavior
- Tomcat configuration errors after a redeploy
- Unexpected database connection issues after a version change
- Broken file permissions or overwritten configuration files
A backup lets you restore the previous working state quickly. For managed hosting users, this is one of the safest ways to test a Java update without risking extended downtime.
What to include in the backup
For a Java hosting account, a useful backup usually includes more than just the application archive. Before deploying a Java update, make sure you protect the parts that are most likely to be needed for rollback.
Application files
Back up the deployed application directory, including:
- WAR files
- Expanded application folders
- Configuration files such as
application.properties,web.xml, or framework-specific settings - Custom libraries in
WEB-INF/lib - Static assets, uploaded files, and templates
Tomcat and JVM-related settings
If your hosting account allows service-level control through Plesk or a Java extension, save the current configuration details before making changes. This may include:
- Java version in use
- Tomcat version
- Startup parameters and JVM options
- Memory allocation settings
- Context configuration or virtual host settings
In many cases, these settings are not part of the file backup itself, so it is useful to note them separately.
Database backup
If the Java application uses a database, create a backup of that database as well. This is essential for applications built on Spring, Hibernate, Jakarta EE, or any framework that stores state externally.
- MySQL or MariaDB databases
- PostgreSQL databases, if applicable
- Any application-specific schema or seed data
Emails and cron jobs, if relevant
Some Java applications rely on scheduled tasks, mail notifications, or inbound email processing. If that applies to your setup, review and back up the related settings too.
How to create a full backup in Plesk
If you want the safest rollback option, create a full subscription backup in Plesk before changing the Java runtime. This captures the hosting account data and is often the easiest way to restore the environment if something goes wrong.
Step 1: Open the backup manager
Log in to Plesk and open the subscription that hosts your Java application. Go to the backup section for that subscription. Depending on your hosting plan and permissions, this may appear as Backup Manager or a similar backup tool in the control panel.
Step 2: Choose the backup type
Select a full backup if you want to protect:
- Website files
- Databases
- Email data, if included in the subscription
- Configuration data available to the backup system
If you only need to protect the Java application itself, a selective backup may be enough. However, for a Java update, full backup is usually the safer choice.
Step 3: Decide where to store the backup
You may be able to store the backup locally on the hosting account or send it to remote storage. If your hosting platform supports remote backup destinations, use them when possible. This reduces the risk of losing both the live data and the backup if the account is affected by a configuration mistake.
Step 4: Start the backup
Run the backup and wait for it to complete. Large Java applications may take longer if they include uploaded files, logs, or multiple databases. Avoid deploying the Java update until the backup finishes successfully.
Step 5: Verify the backup status
After completion, confirm that the backup is listed as successful. If available, review the backup details to make sure the main files and databases were included. A backup that appears successful but is incomplete can create problems later during restore.
How to back up only the Java application files
Sometimes you do not need a full account backup. If your main goal is to protect a specific Tomcat or Java application before a runtime update, you can create a smaller backup of just the app files and configuration.
Typical files to copy
- The deployed WAR file
- The application source or build artifact, if stored on the server
- Custom configuration files
- Certificates or keystore files used by the app
- Uploaded media and generated content
Recommended approach
Use the File Manager in Plesk or connect over SFTP/SSH if available. Copy the relevant directories to a safe location before making any Java or Tomcat changes. Keep the backup outside the live deployment folder to avoid accidental overwrite.
If your Java app is deployed through a private JVM or a custom Tomcat installation, make a note of the service path and any custom startup scripts as well. Those files can be just as important as the WAR file itself.
Back up the database before redeploying
Most Java web applications depend on a database. If you update Java and then discover a compatibility issue, a restored codebase alone may not be enough. The database must also be protected so the application can return to the exact previous state.
Using the database tools in Plesk
Open the database management section in Plesk and export the database to an SQL file. If the panel provides a backup or export feature, choose the format recommended for your database engine. Keep the export in a safe location and label it with the date and Java version you are about to deploy.
What to check before exporting
- Database name and user
- Character set and collation
- Whether the application uses one database or multiple schemas
- Any scheduled jobs that write to the database
For rollback purposes, it is useful to back up the database immediately before testing the new Java version. That reduces the chance of having to restore data that changed during the test window.
Save your current Java and Tomcat configuration
When Java is managed through a Plesk extension such as My App Server, the update process may involve changing the Java version, restarting the service, or adjusting runtime parameters. Before you do that, save the current settings.
Record the active version
Note the current Java version and Tomcat version. If the update causes a problem, this information helps you return to a working setup faster. It also makes support requests easier, because you can describe the previous environment accurately.
Document JVM options
If you have custom JVM options, write them down or take screenshots. Pay special attention to:
- Memory limits such as
-Xmsand-Xmx - Garbage collection settings
- Timezone and encoding parameters
- Custom system properties
- Any arguments required by the application
These details are often overlooked, but they are important when restoring a Java service after an update.
Check service control settings
If your hosting plan allows service control from the panel, confirm the current state of the Java service before changing anything. In some setups, the app can be stopped, restarted, or switched between versions from within Plesk. A backup is safest when taken before those actions.
Recommended backup workflow before a Java update
A practical workflow for most Java hosting accounts looks like this:
- Review the current Java and Tomcat versions.
- Note the app URL, deployment path, and JVM options.
- Create a full subscription backup in Plesk, if available.
- Export the database separately for added safety.
- Copy any custom app files, certificates, or scripts.
- Confirm that the backup completed successfully.
- Only then deploy the Java update.
This approach gives you both a control-panel backup and an application-level rollback point. For hosted Java environments, that combination is usually enough to handle most update-related issues.
How to test the Java update safely
After the backup is complete, deploy the Java update in a controlled way. If your hosting platform offers multiple Java versions, switch to the target version and test the application immediately. Do not wait until production traffic has already begun to use the updated runtime.
Test items after the update
- Application startup and shutdown
- Homepage and key user flows
- Login and session handling
- Database read/write operations
- File upload and download functions
- Background jobs or scheduled tasks
If the app fails to start or produces errors, use the backup to restore the previous files and database, then return to the earlier Java version.
How to restore if the update fails
If the new Java version causes issues, restore in the reverse order of your backup process. In most cases, that means:
- Stop or pause the application service if needed
- Restore the application files from backup
- Restore the database export if data was changed
- Reapply the previous Java and Tomcat settings
- Restart the service and test again
Restoring the database only after you have returned to the previous runtime usually prevents additional compatibility issues. If the hosting control panel supports point-in-time restore or full subscription restore, use the method that best matches the scope of the change.
Best practices for Java hosting backups in Plesk
To make future updates easier, build a simple backup routine around each Java deployment.
- Create backups before every Java version change
- Keep a record of the working Java and Tomcat versions
- Store backups with clear names that include the date and application name
- Keep at least one restore point outside the live account, if possible
- Verify the backup before deploying the update
- Separate file backups from database exports for easier rollback
For smaller and medium-sized applications hosted on shared hosting with private JVM control, this process is usually sufficient. It gives you a practical safety net without adding unnecessary complexity.
Common mistakes to avoid
When preparing a Java update, these mistakes can make recovery harder:
- Updating Java before creating a backup
- Backing up only the WAR file and ignoring the database
- Forgetting custom configuration or certificate files
- Not recording the original JVM options
- Assuming the backup succeeded without checking the result
- Testing the update on live traffic without a rollback plan
A backup is only useful if it can be restored quickly and completely. The more carefully you document the current state, the easier it is to return to it.
FAQ
Should I always create a full backup before a Java update?
Yes, if the application is important or production-facing. A full backup is the safest option because it includes files and databases. If you only need to test a minor runtime change, you may still want at least a database export and application file backup.
Is a WAR file enough for rollback?
Usually not. A WAR file may be enough to redeploy the code, but it does not protect uploaded files, configuration changes, or database state. For a reliable rollback, back up the app files and database together.
Do I need to back up Tomcat settings separately?
Yes, if you have custom startup parameters, memory values, or service settings. These are not always included in the standard hosting backup, so it is best to record them before the update.
Can I update Java first and back up later if something goes wrong?
That is risky. If the update breaks the application or changes data unexpectedly, you may lose the state you need to restore. The backup should always come first.
What is the safest backup method in Plesk for Java hosting?
The safest method is usually a full subscription backup in Plesk, combined with a separate database export and a copy of any Java-specific configuration files. This gives you the best chance of restoring the previous state quickly.
Does this apply to private JVM or Tomcat hosting?
Yes. In fact, it is especially useful for private JVM or Tomcat hosting because version changes can directly affect service startup and application behavior. A backup before the update makes it much easier to revert.
Conclusion
Creating a backup before deploying a Java update is one of the simplest ways to reduce risk in Plesk-based Java hosting. Whether you manage a WAR application, a JSP site, or a servlet-based project through My App Server and a private Tomcat instance, the same rule applies: protect the files, database, and current runtime settings before you change the Java version.
A complete backup gives you a fast rollback path if the new runtime is incompatible or if the application needs additional tuning. For day-to-day Java hosting tasks, that small amount of preparation can save a lot of time and prevent unnecessary downtime.