IFS Middleware Server Backup

• Overview
• Perform Backup or Clone
• Restore Backup
• Restore Clone
• Backups and Clusters
• Troubleshooting Guide

Overview

The backup supports two scenarios; Clone operation and Backup operation. Both are archives and can be restored in case something happens to the machine and the IFS Home needs to be restored.

Backup

Creates an archive of everything that exists in the IFS Home. A backup can be restored in the same location as the previous installation and on the same host or it can be restored in the same location as the previous installation on another host. Do note that a backup can never be restored to another location on disk, the paths must always remain the same.

Clone

Creates an archive containing required files to recreate an IFS Home based on an existing IFS Home.
The following lists how a clone can be used and what the result is.

• A clone is restored from the information provided in <ifs_home>/instance/<instance>/<instance>_configuration.xml. Other configurations made to the IFS Home (from e.g. IFS Admin Console) and is not reflected in this configuration file will not be persisted!
• A clone is always restored with only one server in each cluster¹ (standard fresh installation), other nodes configured are not persisted in the cloned environment.
• A clone will generate a new self-signed certificate used by the HTTP Server. This certificate can be reconfigured using the installer later on.²
• If the cloned environment uses a proxy server, this setting will not be persisted in the cloned environment.
• A clone can be restored in any location on any host.
• A clone can be updated from a previously cloned IFS Home
• A clone can be restored with another instance name.

¹: In this context, cluster refers to the internal clusters in IFS MWS, i.e. MainCluster and IntegrationCluster, not horizontal or vertical clustering of an IFS Home.

²: This behaviour can be overriden when restoring the clone, see -keepOhsCert for more information.

Create Backup or Clone

There is a script in <ifs_home>/instance/<instance>/bin called 'create_backup' that takes one or more arguments:

>create_backup [options]
  -backup                           Prepare a backup of an IFS Home.
  -clone                            Prepare a clone of an IFS Home.
  -update                           Prepare a clone of an IFS Home that can be applied on an existing clone. Ignored unless used with -clone.

Either -backup or -clone must be passed as an argument.

Example:

>create_backup -backup 
  Creates a backup archive located in <ifs_home>/instance/<instance>
>create_backup -clone
  Creates a clone archive located in <ifs_home>/instance/<instance>
>create_backup -clone -update
  Creates a clone archive located in <ifs_home>/instance/<instance> that can be used to update an existing clone.
  Note: An update archive in itself can not be used to restore a clone.

Including user-defined files in a backup or a clone

The archives for both backups and clones can be modified to include or exclude files. If an IFS Home includes files that are big and not needed in a backup (or clone) it can be specified in an exclude file. If an IFS Home has dependencies to other files (either in the IFS Home or outside of the IFS Home) these dependencies can be specified in an include file. Note that a backup takes everything in the IFS Home, so if a dependency is already inside the IFS Home, it doesn't need to be added in the include file.
The name of the include file should be includeList (no suffix) and the name of the exclude file should be excludeList (no suffix).
When the archive is extracted, the files outside of the IFS Home needs to be copied to their correct location manually.

Example: Content of <ifs_home>/instance/<instance>/includeList

C:/path/to/include.file
C:/path/to/second/include.file
${ifs.home}/instance/${ifs.j2ee.instance}/somefile.file

The includeList and excludeList can contain the variables ${ifs.home} and ${ifs.j2ee.instance} that is replaced by the value of the IFS Home and the instance name at runtime.
Note: The includeFile and the excludeFile are removed after create_backup script has finished executed.

Note: If ifsdoc and SOLR related files are needed to be included in the clone/backup they have to be specified in the includeList.

Restore Backup

A backup can be restored by extracting the content of the zip in the same place and on the same host as the previous IFS Home or in the same place on another host. It cannot be restored in another location.

Restore backup in same location and on same host

• Extract the archive in the same location and on the same host as the previous IFS Home. If the services are no longer available install them from <ifs_home>/instance/<instance>/bin/install_service_<component>.<suffix>
• Start IFS MWS Nodemanager service.
• All the servers will probably start automatically but if they don't, start all servers using mws-srv.<suffix>
• Wait for the servers to start and verify that the system is accessible.

Restore backup in same location on a different host

• Extract the archive in the same location as the previous IFS Home.
• Run <ifs_home>/instance/<instance>/bin/move_backup.<suffix>
• Install the nodemanager services from <ifs_home>/instance/<instance>/bin/install_service_<component>.<suffix>
• Update the certificates by running <ifs_home>/instance/<instance>/bin/update_http_certificates.<suffix>
• The nodemanager might be started while updating the certificates and if so, it will likey start all servers due to crash recovery feature. Unfortunately the servers will be started before the changes to the certificates has taken effect and must be restarted.
• Start the nodemanager and all the servers.
• Wait for the servers to start and verify that the system is accessible.

Restore Clone

A clone can be restored on any machine and in any location. Run restore_clone.<suffix> in ifs_home.

>restore_clone [options]
  -instance=<new_instance_name>                  [OPTIONAL]      Restore the clone with a new instance name.
  -overrideConfig=<path_to_configuration_file>   [OPTIONAL]      Restore the clone with another configuration.xml file. If specified, the configuration file must exist.
  -keepOhsCert                                   [OPTIONAL]      Restore the clone with the same Http Server certificate as is being used in the cloned environment.

Example:

>restore_clone -instance=myNewInstance
  Restores the clone with a new instance name
>restore_clone -overrideConfig=/path/to/custom/config.xml -keepOhsCert
  Restores the clone using a customized configuration xml and will keep the HTTP Server certificates.

Restore Clone

• Extract the archive where the new IFS Home should be created.
• On linux, restore the permissions by running chmod -R 775 <ifs_home>
• Run <ifs_home>/restore_clone.<suffix>
• Wait for the script to return and verify that the system is accessible.

Update Clone

• Stop all servers (including nodemanager) in the IFS Home that should be updated.
• Extract the archive in the current IFS Home location and select to overwrite all files.
• On linux, restore the permissions by running chmod -R 775 <ifs_home>
• Run <ifs_home>/restore_clone.<suffix>
• Wait for the script to return and verify that the system is accessible.

Restore Customized Clone

A clone is restored by using the configuration xml <ifs_home>/instance/<instance>/<instance>_configuration.xml.

Override configuration

This file can be manually edited before restoring the clone or a custom configuration xml can be used to override the existing one. All the configurations are taken from the configuration file provided. The <ifs.action> tag has to be set to "create".The instance name of the new IFS home instance will be the one given in the configuration file. The parameter -instance will not be taken into account. Make sure to correctly state the path of the JDBC driver and change the ports as required.  See -overrideConfig flag above.

Note:

Note that in some instances when a different instance name is specified either using the -instance parameter or whithin the custom configuration xml the old instance might remian in the restored ifs home. In such situations remove the old instance as this is not required.

Handling passwords

The configuration file expects the password to be encrypted. For convenience, values prepended with [ENC] will be encrypted in the configuration xml when running restore_clone.<suffix>.

Example:

<ifs.ifsadmin.login>IFSADMIN</ifs.ifsadmin.login>
<ifs.ifsadmin.password.encrypted>[ENC]my_super_secret_password</ifs.ifsadmin.password.encrypted>

Backups and Clusters

There is no need to backup cluster nodes. If a node goes down it can be recreated from the cluster zip according to the cluster guide.

Troubleshooting Guide

Unable to extract archive:
If the archive size is very large (typically a backup archive), some file extractors might not be able to open them. Use a different file extractor.

Failed to install MW Home (Windows):
An IFSHome is registered during installation and if a previous IFS Home has been installed in the same location and hasn't been deleted correctly, the installation will fail. Change the IFS Home location or go to C:\Program Files\Oracle\Inventory\ContentsXML\inventory.xml and remove the entry associated with the IFS Home to be reused.
On Linux, the MW Home inventory is located inside the IFS Home so this is very unlikey to occur on any other platform than Windows.

The restore process ended with errors:

1. Make sure there are no conflicting IFS installations on the same machine. Check the ports and that the service names isn't already taken.
2. Check <ifs_home>/instance/<instance>/logs/mws-sc.log(s) for more details.
3. Remove the half-restored clone and restore it from scratch.