Restore a Payara Server Domain

Overview on restoring a Payara Server domain

Restoring a Domain

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

asadmin restore-domain --filename ${filepath} <domain-name>

Specify the path to the zipped backup domain using the --filename argument. When executed, the command will restore the domain using the specified name as its operand.

You can get more details by using the --long argument too:

asadmin restore-domain --filename --long domain1

Restored the domain (domain1) to /opt/payara/glassfish/domains/domain1
Description               : domain1 backup created on 2017_09_12 by user payara
GlassFish Version         : Payara Server #badassfish (build 24)
Backup User               : payara
Backup Date               : Tue Sep 12 19:16:15 COT 2017
Domain Name               : domain1
Backup Type               : full
Backup Config Name        :
Backup Filename (origin)  : /opt/backups/domain1/
Domain Directory          : /opt/payara/glassfish/domains/domain1

Command restore-domain executed successfully.
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.
If a domain is restored on an already existing domain folder, all the files will be overwritten when the command is run.

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) and 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:


Running the start-local-instance command with a full sync, as discussed earlier, will restore the instance completely:

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

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 --sync=full the instance.