What should you back up before updating a Java application?

Before updating a Java application, back up everything that affects the running app, not just the WAR file. In a hosted Java environment with Plesk, Tomcat, or a private JVM, a release can depend on deployed binaries, configuration files, application data, certificates, and even service-level settings. A complete backup helps you roll back quickly if the new version fails to start, exposes a configuration issue, or changes data structures in a way that cannot be reversed safely.

If you are using a managed hosting setup such as My App Server for Java hosting, the safest approach is to back up both the application layer and any related hosting configuration before you deploy the update. That gives you a known-good restore point for the app, the Tomcat instance, and the surrounding environment.

What you should back up before a Java update

The exact scope depends on how your application is built, but in most cases you should protect these items before updating:

  • Deployed application package — the current WAR, EAR, or exploded application directory.
  • Application configuration files — for example application.properties, application.yml, XML config files, environment-specific overrides, and custom context descriptors.
  • Database — schema and data, especially if the release includes migrations.
  • Uploaded files and user content — attachments, media, generated documents, cache exports, and anything stored outside the codebase.
  • Tomcat or app server settings — connector definitions, JVM options, context settings, memory values, and virtual host configuration.
  • SSL/TLS certificates — private keys, certificate files, and renewal configuration if your deployment uses custom certificates.
  • Scheduled jobs and integration settings — cron jobs, webhooks, API keys, mail settings, queue configuration, and third-party credentials.
  • Logs from the previous working version — useful for comparison if the update introduces errors.

In many hosting environments, the safest backup is a combination of file backup, database export, and service configuration snapshot. That is especially true when the Java application runs under a private JVM or a dedicated Tomcat instance managed through Plesk.

Why backing up only the WAR file is not enough

A common mistake is assuming the deployable archive contains everything needed to restore the application. In practice, most Java applications also rely on external state. If you only save the WAR and the release fails, you may still lose critical items such as:

  • production database data;
  • user uploads stored outside the deployment folder;
  • server-side configuration files edited in the control panel;
  • custom JVM arguments added for memory, encoding, or networking;
  • Tomcat context files that define resources such as datasources;
  • SSL keys or API credentials not stored in version control.

For hosted Java services, rollback is usually fastest when you can restore the full working state, not just re-upload the previous application build.

Backup checklist for Java hosting and Tomcat

1. The current deployed build

Save the exact application version that is live now. This may be:

  • a WAR file in the deployment directory;
  • an exploded web application folder;
  • a custom build artifact deployed manually;
  • the current contents of the application root if files are unpacked after deployment.

If possible, keep a versioned copy of the release artifact so you can redeploy it without rebuilding.

2. Configuration files outside source control

Many hosting setups use config files that are not part of the code repository. Back up anything that was tuned after deployment, such as:

  • datasource definitions;
  • SMTP settings;
  • file paths and upload directories;
  • feature flags;
  • integration tokens;
  • custom log settings;
  • JNDI resources;
  • external service endpoints.

In Plesk-based Java hosting, these settings may be stored in application folders, service configuration areas, or custom integration files created during setup. Make sure you know where the working values live before replacing the application.

3. Database backup

If the update changes tables, adds fields, or alters content format, export the database first. A Java application update often depends on successful schema migration, but migrations can fail or produce incompatible states.

Back up:

  • the full database schema;
  • all data tables used by the app;
  • stored procedures, triggers, and functions if applicable;
  • migration scripts or notes that explain the current schema version.

For safer release workflow, it is best to verify that the backup can actually be restored to a test database before you proceed with production changes.

4. Uploaded files and persistent application data

Java web apps often store content outside the code package. This includes images, attachments, PDFs, generated reports, and temporary exports that users expect to remain available after an update.

Back up any directory used for:

  • user uploads;
  • document storage;
  • file-based caches that contain important data;
  • generated content retained between sessions;
  • local repository files used by the application.

If the app stores files on the same hosting account, copy those directories before deployment. If storage is mounted elsewhere, confirm the backup method covers that location as well.

5. Tomcat and JVM settings

With My App Server or another managed Java setup, the runtime configuration can matter as much as the application code. Save any changes made to:

  • Tomcat version selection;
  • JVM version selection;
  • JAVA_OPTS or memory settings;
  • port assignments;
  • connector configuration;
  • context path and deployment mappings;
  • service control settings used to start and stop the app.

This is especially useful if your application starts only with specific heap values, timezone settings, or character encoding flags. After an update, those details can be the difference between a clean restart and a startup failure.

6. SSL/TLS certificates and key material

If the Java application uses custom SSL/TLS configuration or terminates HTTPS through a specific server component, back up the certificate chain and private key. Also save renewal notes and any related configuration paths.

Even if the certificate is managed elsewhere, document where it is installed so you can verify the updated app still serves traffic correctly after the release.

7. Scheduled tasks and external integrations

Many Java apps depend on background jobs and third-party connections. These should be recorded before an update because they often break when environment variables, package versions, or endpoint URLs change.

Include:

  • cron jobs or scheduled tasks;
  • payment or notification integrations;
  • email relay configuration;
  • webhook endpoints;
  • queue consumers and producers;
  • API credentials stored on the server.

If a task runs from the hosting control panel or server scheduler, export the job definition or save a screenshot of the exact settings.

Practical backup workflow before deployment

A simple and reliable process is usually better than a complicated one. For most Java hosting releases, follow this workflow:

  1. Freeze changes — stop non-essential edits while you prepare the update.
  2. Record the current release version — note the WAR version, Git commit, or build number.
  3. Export the database — keep a timestamped copy and verify the file size.
  4. Copy the live application files — include the deployed package and any unpacked content.
  5. Save external configuration — config files, environment variables, and server settings.
  6. Back up persistent content — uploads, attachments, reports, and generated files.
  7. Document runtime settings — Java version, Tomcat version, memory values, and service state.
  8. Test the backup — confirm that files open and the database dump can be restored.

In a managed hosting control panel, it is also useful to note which service controls were used to start or stop the app before the release. That makes rollback easier if you need to restart the same Tomcat instance after restoring files.

What to back up in My App Server specifically

When you manage Java hosting through a Plesk extension such as My App Server, think in terms of three layers:

  • Application layer — WAR, JSPs, servlet classes, resources, and static assets.
  • Runtime layer — the selected Java version, Tomcat instance, JVM options, and service controls.
  • Data layer — database, uploads, and persistent user data.

Before updating, back up all three layers if they are part of the live system. This is the safest way to keep a working copy of your Java application ready for rollback.

If you are using a custom app server setup rather than the default version, document the exact version and installation choice. That helps when you need to recreate the same runtime after the update. For smaller and medium-size applications, this approach is usually enough to keep deployment risk low without needing enterprise-grade orchestration.

Safe update practices after the backup is complete

Once the backup is finished, the release should still be handled carefully. A good backup does not remove the need for validation.

  • Deploy in a maintenance window if the app is user-facing.
  • Keep the previous version available until the new one is confirmed healthy.
  • Check application logs immediately after restart.
  • Verify login, forms, file upload, and any integration points.
  • Confirm that database migrations completed successfully.
  • Test a rollback path before the next release, if possible.

In hosted Tomcat environments, the most common issues after an update are missing configuration, incompatible Java or Tomcat version changes, database schema mismatch, and file permission problems. A good backup helps you resolve these quickly.

Common mistakes to avoid

  • Backing up only source code — source code is not the same as the live environment.
  • Ignoring the database — a new build may depend on schema changes.
  • Forgetting uploaded files — user content is often outside the application package.
  • Not recording server settings — JVM options and Tomcat settings may be essential.
  • Skipping restore tests — a backup that cannot be restored is not enough.
  • Overwriting the only known-good release — keep the current working version until validation is complete.

Example backup scope for a typical Java web app

For a standard JSP or servlet application hosted on Tomcat, a practical pre-update backup might include:

  • the current .war file;
  • the exploded deployment folder, if present;
  • database export in SQL format;
  • custom properties files;
  • upload directory contents;
  • Tomcat context and connector settings;
  • JVM memory settings and startup options;
  • SSL key and certificate files, if custom-installed;
  • logs from the previous stable version.

This scope is usually enough for fast rollback in a shared hosting account with private JVM support.

FAQ

Do I need to back up the whole server before updating a Java application?

Not usually. For hosted Java applications, a focused backup of the application files, database, uploaded content, and relevant server configuration is often sufficient. If the app shares infrastructure with other services, make sure your backup covers only the items related to the Java application and its runtime.

Is the WAR file enough for rollback?

No. The WAR file may be enough to redeploy code, but it does not protect your database, uploads, or runtime settings. For a safe rollback, keep the previous application build together with the related data and configuration.

Should I back up Tomcat settings even if I did not change them?

Yes, especially in a managed hosting environment. Small changes in JVM options, memory allocation, or context settings can affect startup and performance. Saving the current settings gives you a clear rollback reference.

What if my application uses a private JVM in Plesk?

Back up the JVM selection, startup options, Tomcat version, deployed files, and any custom configuration stored in the hosting account. In a private JVM setup, those values are part of the application’s working state.

Do I need to back up logs?

Logs are not required for restoration, but they are very useful for troubleshooting if the update fails. Keep the most recent logs from the stable version so you can compare startup behavior and error messages after the release.

How often should I verify my backup process?

Verify it regularly, especially before larger updates. The best practice is to confirm that the backup can be restored, not just created. A restore test can save time if the next deployment needs to be rolled back quickly.

Conclusion

Before updating a Java application, back up the deployed build, configuration, database, persistent files, and Tomcat or JVM settings. In a hosting environment such as My App Server, that full scope is the safest way to protect a Tomcat-based app, a JSP or servlet project, or a small private JVM deployment. The goal is not only to preserve files, but to preserve a working release that can be restored quickly if the update introduces an error.

A careful backup routine reduces deployment risk, shortens rollback time, and makes every Java release easier to validate. If you treat the application, runtime, and data as one package, your updates will be much safer.

  • 0 Users Found This Useful
Was this answer helpful?