How to create a backup before deploying a JSP update in the UK

Before you deploy a JSP update, it is a good idea to create a backup of both your application files and the related Plesk configuration. In a JSP hosting setup, even a small change can affect the application archive, static assets, Tomcat settings, or the virtual host configuration that supports your Java app. A backup gives you a quick way to roll back if the new version introduces an error, breaks a page, or changes how the application starts under Tomcat.

If you are using Plesk with a Java hosting setup such as My App Server, the safest approach is to back up the site files, the deployed WAR or exploded application, and any custom service settings you have added. This is especially important when you manage a private JVM or a dedicated Apache Tomcat instance from the control panel, because an update may require both file replacement and a service restart.

Why a backup matters before a JSP deployment

JSP applications often depend on several moving parts at once: compiled classes, JSP pages, web.xml, libraries, static resources, and Tomcat configuration. When you upload a new version, you may also replace a WAR file, clear cached files, or update environment-specific settings. If anything goes wrong, restoring from backup is usually faster and safer than trying to repair the site manually.

A backup is particularly useful when:

  • you are updating JSP pages, servlets, or supporting Java classes;
  • you are replacing a WAR file in a Plesk-managed Java hosting account;
  • you have custom Tomcat or My App Server settings;
  • the application uses database connection settings stored in configuration files;
  • you need to test a new release and may need to revert quickly;
  • you want to protect logs and configuration before changing the deployment.

For UK hosting customers, this is a practical part of normal change management. Whether you are deploying a small business JSP site, an internal tool, or a servlet-based web application, a backup helps reduce downtime and avoids unnecessary recovery work.

What to include in your backup

For a JSP update, do not rely only on a copy of the source code. A useful backup should cover everything needed to restore the site to a working state.

Essential files and folders

  • the deployed application directory or WAR file;
  • JSP files and related Java source files;
  • compiled classes, if your deployment uses them directly;
  • WEB-INF folder contents, including web.xml;
  • JAR files in the lib folder;
  • static assets such as images, CSS, and JavaScript;
  • custom configuration files, including database and environment settings.

Plesk and Tomcat-related items

  • Tomcat deployment settings in My App Server;
  • Java version selection used by the application;
  • custom service options or startup parameters;
  • document root mapping and application path details;
  • any rewrite rules or Apache settings if they are part of the setup;
  • recent logs, if you want a record of the current deployment state.

If you are not sure which components are changed by the update, it is safer to back up the full application directory and the relevant Plesk configuration notes. That way, you can restore the app even if the deployment structure changes slightly.

How to create a backup in Plesk before updating JSP

The exact steps may vary slightly depending on how your site is set up, but the general process in Plesk is straightforward. The goal is to save a copy of the current working version before uploading or activating the new one.

1. Open the website in Plesk

Log in to Plesk and go to the subscription or domain that hosts your JSP application. If your account uses My App Server, open the relevant service or Java application section first so you can review the current deployment details.

Before making changes, note the following:

  • application path;
  • Tomcat or JVM version in use;
  • deployment method, such as WAR upload or extracted files;
  • any custom start or stop settings;
  • the last known working release or version number.

2. Create a manual copy of the application files

If your account allows file management through Plesk File Manager, copy the current JSP application folder to a safe location. A common approach is to create a backup folder outside the web root, such as a private directory in the subscription or a temporary archive location.

For example, you can save:

  • the full application directory;
  • the current WAR file before replacement;
  • any modified JSP pages or templates;
  • configuration files that are not stored in version control.

If your application is deployed as an exploded directory, make sure the copy includes all nested folders and not only the visible JSP files. Missing a library or WEB-INF file can make the restore incomplete.

3. Download a local archive copy

In addition to a server-side backup, it is wise to download a local copy to your computer or secure storage. Compress the application directory into a ZIP or TAR archive if possible. A local copy is useful if you need to restore content quickly or compare files after the deploy.

When saving locally, use a clear file name that includes:

  • the domain name or project name;
  • the date and time;
  • the version before the update.

This makes it much easier to identify the correct rollback point later.

4. Back up Plesk configuration details

If your JSP application runs through My App Server or another custom Java setup, record the key configuration values before updating anything. In many cases, a screenshot or a short text note is enough.

Document:

  • which Java version is selected;
  • which Tomcat instance or service is attached to the app;
  • the application URL or context path;
  • the service status before deployment;
  • any custom memory or startup values if they are available in your plan;
  • any additional virtual host or Apache settings.

This step is especially useful if the update includes changes to server-side classes or dependency files, because a rollback may require more than just copying files back.

5. Save a copy of the current logs

Before you deploy the update, consider saving recent logs from the application. Logs are not a replacement for a real backup, but they are very helpful for troubleshooting after a release. Keeping the current logs alongside the backup can help you compare behaviour before and after the change.

Useful log sources may include:

  • Tomcat application logs;
  • Apache access and error logs if the site is fronted by Apache;
  • application-specific logs written by the JSP app;
  • Plesk service logs related to the Java instance.

If the update fails, logs can show whether the issue came from a missing class, a bad JSP syntax error, a deployment path problem, or a service start failure.

Recommended backup workflow for My App Server users

If you are using ITA’s My App Server extension in Plesk, the backup process should cover both the application files and the Java service setup. This setup is designed for practical JSP hosting, servlet hosting, and Tomcat hosting in a shared hosting account, so the safest workflow is to prepare a full restore point before any new deploy.

Suggested checklist

  • confirm which version of the JSP application is currently live;
  • copy the deployed files or WAR to a backup folder;
  • export or note the My App Server configuration;
  • save the current service status and Java version;
  • download the backup to local storage;
  • copy the current logs for reference;
  • test that the backup archive opens correctly.

If your deployment process uses multiple steps, such as uploading a WAR and then restarting the service, back up before each major change. That way, you can isolate which part of the update caused any issue.

How to restore quickly if the JSP update fails

A good backup is only useful if you can restore from it without delay. Before you start the deployment, make sure you know how to put the previous version back online.

Rollback steps

  1. Stop the application or Tomcat service if needed.
  2. Replace the updated files with the saved backup copy.
  3. Restore the previous WAR, JSP files, and WEB-INF contents.
  4. Return any changed configuration files to their earlier version.
  5. Restart the Java service or Tomcat instance.
  6. Check the site in a browser and review the logs.

If the application was working before the update, keep the backup available until you have tested the new release properly. For safer change control, many administrators also keep one earlier backup in case the most recent version turns out to have its own hidden problem.

Common mistakes to avoid

When updating JSP applications in Plesk, backup mistakes often happen because only part of the deployment is copied. Avoid these common issues:

  • backing up only JSP files and forgetting WEB-INF or JAR dependencies;
  • saving the source code but not the deployed WAR or live folder structure;
  • overwriting the working version before confirming the backup is complete;
  • forgetting to save Tomcat or My App Server settings;
  • not keeping a local copy outside the hosting account;
  • skipping log collection, which makes troubleshooting harder;
  • deploying during busy hours without a rollback plan.

These issues are easy to avoid if you treat the backup as part of the deployment process, not as an optional extra.

Best practice for small and medium JSP applications

For most small and medium JSP applications, a simple but disciplined backup process is enough. You do not need a complex enterprise backup system to protect a straightforward Tomcat-based site. Instead, focus on consistency and repeatability.

A practical routine is:

  • make a server-side copy before each release;
  • keep a local archive of the last working version;
  • note the Java and Tomcat version used for the deployment;
  • save logs after every update;
  • test the new release in the browser before deleting older backups.

This approach fits well with managed hosting and control panel workflows, where speed and reliability matter more than complicated infrastructure. It also works well when you deploy WAR files, JSP pages, or servlet updates through Plesk.

When to use a full Plesk backup instead of a file copy

A manual file copy is usually enough for a simple JSP code update. However, in some cases a full Plesk backup is the better choice.

Use a fuller backup method when:

  • the site also includes mail or database changes;
  • you are updating multiple domains or subdomains at once;
  • your deployment affects more than one application path;
  • you have recent configuration changes in addition to the JSP update;
  • you need a broader restore point for a planned maintenance window.

For a focused JSP deployment, though, a clean file-level backup plus saved configuration notes is often the fastest and most practical option.

FAQ

Should I back up the whole website or only the JSP application?

If the JSP application is isolated, backing up the application folder and related Tomcat settings is usually enough. If the site shares assets, configuration, or databases with other parts of the domain, a broader backup is safer.

Do I need to back up the WAR file if I already have the source code?

Yes, if the WAR file is the currently deployed version. The live package may include compiled classes, bundled libraries, and deployment-specific settings that are not present in source control.

What should I save before restarting Tomcat?

Save the current application files, configuration details, and recent logs. If the app uses My App Server, also note the selected Java version and the current service state.

Can I back up JSP files from File Manager in Plesk?

Yes. File Manager is a convenient way to copy the application files, but make sure you include all related folders, not only the visible JSP pages.

Is it enough to keep one backup?

One backup is better than none, but keeping at least two recent restore points is safer. That gives you an option if the newest version has a problem of its own.

Should I create the backup before or after uploading the new release?

Always before. The backup should capture the last known working version, not the updated files.

Conclusion

Creating a backup before deploying a JSP update is one of the simplest ways to protect a Java application in Plesk. It helps you recover quickly if the new version fails, protects Tomcat and My App Server settings, and gives you a clear rollback path if a JSP, servlet, or WAR change causes problems.

For the best results, back up the live application files, note the Java and Tomcat configuration, save current logs, and keep a local archive outside the hosting account. That small preparation step can save a lot of time during deployment and makes JSP hosting far easier to manage on a day-to-day basis.

  • 0 Users Found This Useful
Was this answer helpful?