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 domain1_2017_09_12_v00001.zip --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 4.1.2.173 #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/domain1_2017_09_12_v00001.zip
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:
payara41/nodes/localhost-localdomain/myInstance
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.