Before updating a Java application, the safest approach is to back up both the application itself and everything it depends on. In a typical hosting environment, that means more than copying a single .war file. If your app runs through Plesk and My App Server, or on a private Tomcat/JVM setup, you should also save configuration files, deployment settings, uploaded content, and the database that stores live data.
A proper backup makes it possible to roll back quickly if the new release introduces a problem such as a broken servlet mapping, an incompatible Java version, a missing library, or a configuration change that affects Apache Tomcat startup. For UK-based hosting customers managing Java web apps through a control panel, the goal is simple: keep the update low-risk, reversible, and easy to validate.
What you should back up before updating a Java application
At minimum, back up the following items before any application update:
- The current application package, such as the
.war,.jar, or deployed application directory - All application configuration files
- Database contents and database credentials used by the app
- Uploaded files, media, and user-generated content
- Tomcat or JVM-related settings specific to the app
- Custom libraries, certificates, and environment variables
- Any reverse proxy, Apache, or control panel integration settings
- Logs from the current working version, if you may need to compare behaviour after the update
If the application is small, these items may all be easy to identify. For more complex installs, especially if you have custom Tomcat configuration or separate JVM settings in My App Server, it is worth making a simple inventory before touching the release.
Why a Java update needs more than a file copy
Java applications often store important state outside the deployable package. The code inside a .war file is only one part of the system. A live app may also depend on:
- a database schema with active customer records
- session data or cached configuration
- file uploads stored outside the application archive
- external properties files defining database URLs, mail servers, or API keys
- Tomcat context settings, startup options, or Java memory parameters
When an update goes wrong, the most common rollback failure is not the code itself, but the missing supporting files. For example, an updated build may deploy successfully, yet fail at runtime because a property file was overwritten or a new library version no longer matches the old configuration. Backing up the full release environment reduces that risk.
Application files to back up
Current deployable artifact
Save the exact version currently running in production. This may be one of the following:
.warfile.jarfile- expanded application directory under Tomcat
- a build archive from your CI/CD pipeline
If the app is already deployed and expanded, keep both the original package and a copy of the deployed directory structure. This can help you restore the same version quickly if the update needs to be reversed.
Configuration files
Back up any configuration files that are not part of the codebase but are required for the app to run in your hosting account. Common examples include:
- database connection settings
- mail server configuration
- feature flags
- API endpoints and keys
- file storage paths
- locale or timezone settings
In Plesk-based hosting, these settings may be stored in application-specific files, environment variables, or panel-managed deployment options. If you use My App Server, check any custom app server settings that were created for this application.
Environment-specific overrides
Many Java apps behave differently in each environment. Preserve any override files used for production, such as:
application.propertiesapplication.ymlcontext.xmlserver.xmlfragments, if customised- shell scripts used to start or stop a private JVM
These files often contain values that are not safe to rebuild from memory after the update. Keeping a copy ensures you can reapply the exact production settings.
Database backup before updating a Java application
If the app uses a database, back it up before changing the application version. This is one of the most important steps because code updates may change data handling, schema validation, or migration behaviour.
What to back up in the database layer
- The full database dump
- Stored procedures, triggers, and routines
- User accounts and privileges, if relevant to the app setup
- Migration state or version tables used by the application
For hosted Java services, the database may be managed separately from Tomcat. That means you should verify that the backup covers the actual production database and not just a development copy. If your application performs automatic schema migration on startup, keep a backup even if you expect the update to be backward compatible.
Why database backups matter for rollback
Even a minor code release can introduce a schema change, data transformation, or new validation rule. If the release fails and you revert the code, the old version may still be incompatible with the modified data. A database backup gives you a safe fallback point.
If possible, take the database backup immediately before deployment and note the timestamp. This makes it easier to match the data state to the application version during recovery.
Tomcat, JVM, and hosting control panel settings to save
When Java hosting is managed through a control panel like Plesk and a private runtime such as My App Server, you should also preserve the runtime settings that make the app start correctly.
Tomcat-specific settings
Back up or document the following where applicable:
- Tomcat version in use
- virtual host or context configuration
- context path mapping
- JNDI resources
- JVM memory arguments
- startup and shutdown parameters
- connector settings, if customised
If your hosting account uses a ready-made Tomcat installation, make sure you know which version is live before changing anything. If you use a custom app server install, save the exact configuration package or notes so you can recreate the same runtime.
JVM options and Java version
Back up the Java version in use and any custom JVM flags. Common items include:
-Xmsand-Xmxmemory settings- garbage collector options
- timezone or encoding settings
- system properties passed at startup
- Java version selector used for the app
This matters because a release may work in one Java version and fail in another. In a managed hosting setup, the safest path is to record the exact runtime used by the current application before testing the new build.
Apache and proxy configuration
If Apache is used in front of Tomcat, back up any related routing or proxy rules. This may include:
- rewrite rules
- reverse proxy mappings
- SSL or TLS certificate references
- redirects to the Java application
- custom headers or security rules
These settings are easy to overlook because they are not part of the Java code, but they can break the application just as quickly as a bad deployment package.
Uploaded files, user content, and attachments
If the application allows uploads, preserve the upload directory before updating. This is especially important for content management systems, document portals, internal tools, and customer-facing portals built on Java.
Examples of data commonly stored on disk
- profile images
- documents and invoices
- generated reports
- temporary export files
- attachments or media uploads
Do not assume these are included in the code deployment. In many hosting setups, they live outside the WAR file and may be mounted in a separate directory. If the update affects file handling, a backup of this directory is essential.
Certificates, keys, and secrets
Before updating, back up any security-related files the app depends on. These may include:
- TLS certificates
- private keys
- keystores and truststores
- API credentials
- OAuth client secrets
- SMTP passwords
Never leave secrets only in memory or in undocumented panel settings. If the update requires redeployment or a runtime restart, you need a secure, recoverable record of what was in use.
Logs to keep before the update
Logs are not a replacement for a backup, but they are extremely useful for comparing the old and new release. Save the most recent working logs before deployment, especially if the update may affect startup or authentication.
Useful logs to retain
- application logs
- Tomcat logs
- access logs
- error logs
- control panel deployment logs
These logs can help you identify whether a problem is caused by the new release, by the host configuration, or by a missing dependency in the Java runtime.
Recommended backup checklist before updating
Use this checklist before pushing a new version live:
- Back up the current
.war,.jar, or expanded app directory. - Export the production database.
- Save all configuration and environment override files.
- Record the active Java version and JVM options.
- Save Tomcat context, connector, and startup settings.
- Copy upload folders and user-generated content.
- Back up certificates, keys, and truststores if used.
- Keep the last known good logs.
- Note the exact deployment time and version number.
- Verify you can restore from the backup before proceeding, if possible.
For hosted Java apps managed through Plesk or My App Server, this checklist helps keep the deployment process predictable even when the release is small.
How to reduce release risk in a managed hosting environment
Backups are only one part of a safer release workflow. A lower-risk update usually includes a few additional habits:
- Test the new build in staging first, if available
- Confirm the target Java version before deployment
- Check whether the release changes database schema
- Keep the previous version available for rollback
- Deploy during a quieter traffic window
- Validate the application immediately after restart
In a hosting platform with a control panel, you often have the advantage of clear service control. That makes it easier to stop, replace, start, and test the application in a controlled order. If your app runs on a private Tomcat instance, this is especially useful because you can verify the exact runtime state after the update.
Practical rollback planning
If the update fails, a rollback should be straightforward. Before deploying, make sure you can answer these questions:
- Which version is currently running?
- Where is the backup stored?
- How do you restore the database?
- Which configuration files must be copied back?
- What Tomcat or JVM settings must be restored?
- Who will validate the app after rollback?
If the answer to any of these is unclear, the release is not ready. A good backup plan is not just a file copy; it is a practical recovery path.
Common mistakes to avoid
- Backing up only the WAR file and forgetting the database
- Overwriting production settings with default build settings
- Ignoring custom JVM arguments
- Forgetting uploaded files and attachments
- Not saving the previous Tomcat context configuration
- Assuming the app will recreate all data automatically
- Updating first and checking compatibility later
These mistakes are common because Java apps often separate code, runtime, and data. A safe update treats all three as part of the release.
FAQ
Do I need to back up the full server before updating a Java application?
Usually no. For most hosted Java applications, it is enough to back up the application package, configuration, database, uploads, certificates, and runtime settings. A full server image is only needed in more complex environments.
Is the WAR file enough for rollback?
No. The WAR file is important, but it is rarely enough on its own. You also need the database backup, config files, upload directories, and any Tomcat or JVM settings required to make the app run exactly as before.
Should I back up Tomcat settings if I use My App Server?
Yes. If your Java application runs under a private Tomcat or JVM managed through My App Server, save the version, startup options, and any custom app server settings. These can affect whether the old release starts correctly after rollback.
What if the update only changes one class or one small feature?
Even small changes can affect runtime behaviour, data handling, or compatibility with the current Java version. Backing up the existing release is still the safer approach.
Should I back up before changing the Java version too?
Yes. A Java version change can expose compatibility issues in libraries, Tomcat configuration, or application code. Back up everything first, then test carefully after the change.
How do I know whether a file is part of the application or just a setting?
If the file is needed to make the app connect to databases, send email, store files, or start correctly in your hosting account, treat it as part of the release backup. If in doubt, save it.
Conclusion
Before updating a Java application, back up the deployable package, database, configuration files, uploaded content, certificates, and any Tomcat or JVM settings tied to the live service. In a managed hosting setup with Plesk and My App Server, this gives you a practical rollback path and lowers the risk of downtime or broken application behaviour.
A safe release is not just about deploying the new version. It is about being able to return to the last known good state quickly if something unexpected happens. If you save the full application state before the update, you will be in a much better position to validate the release and recover cleanly if needed.