Backup and Restore Upgrade Method

You will need to download the version of Payara Enterprise you are planning to upgrade to before beginning the backup and restore method of upgrading Payara.

Backup a Payara Server Domain

The backup-domain command requires the domain is not running, if this method is chosen for a production system, an arranged period of downtime would be required.

To create a backup of a domain, the asadmin backup-domain command is used:

asadmin backup-domain {domain_name}

The resulting ZIP file will be saved in a destination with this structure:

{backupDir}/{domain_name}/<domain-name>_<YYYY_MM_DD>_v<backup-number>

Where the backup number is a consecutive integer representing how many backups of the domain have been made.

You can get additional details of the backup operation by using the --long argument when running the command, which will output the following data:

asadmin> backup-domain --backupDir /home/james/payarabackup --long domain1

Backed up domain1 at Mon Jul 04 16:25:58 BST 2022.

Description               : domain1 backup created on 2022_07_04 by user james
GlassFish Version         : Payara Server Enterprise  5.39.0 #badassfish (build 529)
Backup User               : james
Backup Date               : Mon Jul 04 16:25:58 BST 2022
Domain Name               : domain1
Backup Type               : full
Backup Config Name        :
Backup Filename (origin)  : /home/james/payarabackup/domain1/domain1_2022_07_04_v00001.zip
Domain Directory          : /home/james/payara-5.39.0/payara5/glassfish/domains/domain1

Command backup-domain executed successfully.

Read more about the Backup Domain Command

Restore a Payara Server Domain

Since instances are stored separately from a domain, and they may be on remote hosts, the command will have no effect on restoring instance data.

To restore from a backup, the asadmin restore-domain command is used:

asadmin restore-domain --filename {path_to_backup} {domain_name}

You can get additional details of the restore operation by using the --long argument when running the command, which will output the following data:

asadmin> restore-domain --filename /home/james/payarabackup/domain1/domain1_2022_07_04_v00001.zip --long domain1

Restored the domain (domain1) to /home/james/PayaraInstalls/payara-5.40.0/payara5/glassfish/domains/domain1

Description               : domain1 backup created on 2022_07_04 by user james
GlassFish Version         : Payara Server Enterprise  5.39.0 #badassfish (build 529)
Backup User               : james
Backup Date               : Mon Jul 04 16:25:58 BST 2022
Domain Name               : domain1
Backup Type               : full
Backup Config Name        :
Backup Filename (origin)  : /home/james/payarabackup/domain1/domain1_2022_07_04_v00001.zip
Domain Directory          : /home/james/PayaraInstalls/payara-5.39.0/payara5/glassfish/domains/domain1

Command restore-domain executed successfully.

Read more about the Restore Domain Command

Restoring an Instance

Since all data in an instance directory is kept in sync with the DAS, there is no added data (besides logs, caches and some MQ data when a file-based store is used) so an instance can be completely restored simply by making sure there is an empty directory with the name of the instance inside a node folder of the correct name.

For example: payara5/glassfish/nodes/localhost-example/myInstance

Running the start-local-instance command with the sync property set to full sync, will restore the instance completely:

asadmin> start-local-instance --sync=full myInstance

Read more about the Start Local Instance Command

Considerations for OpenMQ

If OpenMQ (Payara Server’s JMS broker) is being used, the default configuration is to use EMBEDDED mode, meaning that Payara Server will fully manage the JMS broker within the same JVM as the server instance and a file-based store is used for persistent messages.

The alternative option of LOCAL allows for the use of an “enhanced” broker cluster, whereby the JMS broker instances are started as separate JVMs and use a database connection for storage. Assuming the database is highly available, this completely avoids any danger when needing to use --sync=full on the instance.