Backup and recovery strategy for LiveCycle

After you identify how LiveCycle is used, determine which files must be backed up, how often, and the backup window to be made available.

Important: As with any other aspect of your LiveCycle implementation, your backup and recovery strategy must be developed and tested in a development or staging environment before being used in production in order to ensure that the entire solution is working as expected with no data loss.

Adobe Experience Manager (AEM) is an integral part of LiveCycle. Therefore, you need to back up AEM as well in sync with LiveCycle backup as Correspondence Management Solution and services, such as Forms Manager are based on data stored in AEM part of LiveCycle.To prevent any data loss, the LiveCycle specific data must be backed up in a way to ensure that GDS and AEM (repository) correlate with database references.The database, GDS, AEM, and Content Storage Root directories must be restored to a computer with the same DNS name as the original.

Types of backups

The LiveCycle backup strategy involves two types of backups:

System image:
A complete system backup that you can use to restore the contents of your computer if your hard drive or entire computer stops working. A system image backup is necessary only prior to production deployment of LiveCycle. Internal corporate policies then dictate how often system image backups are required.

LiveCycle specific data:
Application data exists in database, Global Document Storage (GDS), and AEM repository, and must be backed up in real time. GDS is a directory that is used to store long-lived files that are used within a process. These files may include PDFs, policies, or form templates.
Note: If Content Services (Deprecated) is installed, also back up the Content Storage Root directory. (See Content Storage Root directory (Content Services only).)

The database is used to store form artifacts, service configurations, process state, and database references to GDS files. If you enabled document storage in the database, persistent data and documents in the GDS are also stored in the database. The database can be backed up and recovered by using the following methods:

  • Snapshot backup mode indicates that the LiveCycle system is in backup mode either indefinitely or for a specified number of minutes, after which backup mode is no longer enabled. To enter or leave snapshot backup mode, you can use one of the following options. After a recovery scenario, snapshot backup mode should not be enabled.

  • Rolling backup mode indicates that the system is always in backup mode, with a new backup mode session being initiated as soon as the previous session is released. No time out is associated with rolling backup mode. When the LCBackupMode script or APIs are called to leave rolling backup mode, a new rolling backup mode session begins. This mode is useful for supporting continuous backups but still allowing old and unneeded documents to be cleaned out of the GDS directory. Rolling backup mode is not supported through the Backup and Recovery page. After a recovery scenario, rolling backup mode is still enabled. You can leave the continuous backup mode (rolling backup mode) by using the LCBackupMode script with the leaveContinuousCoverage option.

Note: Leaving rolling backup mode immediately causes a new backup mode session to begin. To disable rolling backup mode completely, use the leaveContinuousCoverage option in the script, which overwrites the existing rolling backup session. When in snapshot backup mode, you may leave backup mode as you usually do.

To prevent data loss, the LiveCycle specific data must be backed up in a way that ensures that GDS and Content Storage Root directory documents correlate with database references.

Important: When the GDS is stored on the file system and not in the database, perform the database backup before the GDS backup.

Special considerations for backup and recovery

Use the following guidelines if you must recover LiveCycle into a different environment because of the following changes:

  • Change in the IP address, hostname, or port of the LiveCycle server

  • Change in the drive letters or directory path

  • Change to a different database host, port, or name

Typically, such recovery scenarios are caused by hardware failure of the server that hosts the application server, database server, or LiveCycle server. In addition to the LiveCycle-specific configurations that are described in this section, you should also make the necessary changes for other parts of the LiveCycle deployment such as load balancers and firewalls, if the hostname or IP address of a LiveCycle server changes.

What cannot be changed

Even though you can change the database server and many other parameters, you cannot change the application server type or database type when you recover LiveCycle from a backup. For example, if you are recovering a LiveCycle backup, you cannot change the application server from JBoss to WebLogic or database from Oracle to DB2. In addition, recovered LiveCycle must use the same file system paths such as the fonts directory.

Restarting after a recovery

Before you restart the LiveCycle server after a recovery, do the following:

  1. Start the system in maintenance mode.

  2. Do the following to ensure that Form Manager is synced with LiveCycle in the maintenance mode:

    1. Go to http://<server>:<port>/lc/fm and log in using adminstrator/password credentials.

    2. Click the name of the user (Super Administrator in this case) at top-right corner.

    3. Click Admin Options.

    4. Click Start to synchronize assets from the repository.

  3. In a clustered environment, the master node (with respect to AEM) should be up before the slave nodes.

  4. Ensure that no processes are initiated from either internal or external sources such as the Web, SOAP, or EJB process initiators until the normal operation of the system is validated.

If the main LiveCycle database is moved or changed, review the install guides relevant to your application server for information on updating the database connection information for the LiveCycle data sources IDP_DS and EDC_DS.

Changing the LiveCycle hostname or IP address

In a cluster, if you use TCP caching instead of UDP, you must update the cache locator configuration. See “Configuring the caching locators (caching using TCP only)” in the configuration guide relevant to your application server.

Changing the LiveCycle node file system paths

If you change the file system paths for a standalone node, you must update the appropriate references in preferences, other system configurations, custom applications, and deployed LiveCycle applications. On the other hand, for a cluster, all nodes must use the same file system path configuration. You must set the Global Document Storage (GDS) root directory and ensure that it points to a copy of the recovered GDS which is in sync with the recovered database. Setting the GDS path is important because the GDS can contain data intended to persist across application server restarts.

In a clustered environment, the file system path configuration of the repository should be same for all the cluster nodes before the backup and after the recovery.

Use the LCSetGDS script in the[LiveCycle root]\sdk\misc\Foundation\SetGDSCommandline folder to set the GDS path after you change the file system paths. See the ReadMe.txt file in the same folder for details. If the old GDS directory path cannot be used, LCSetGDS script must be used to set the new path to the GDS before you start LiveCycle.

Important: This circumstance is the only one under which you should use this script to change the GDS location. To change the GDS location while LiveCycle is running, use Administration Console. (See Configure general LiveCycle settings.)

After you set the GDS path, start the LiveCycle server in maintenance mode, and use the Administration Console to update the remaining file system paths for the new node. After you verify that all of the necessary configurations are updated, restart and test LiveCycle.

// Ethnio survey code removed