Recovering the LiveCycle data

This section describes the steps required to recover the LiveCycle data. Also see Special considerations for backup and recovery.

Important: The database, GDS, AEM repository, and Content Storage Root directories must be restored to a computer with the same DNS name as the original.

LiveCycle should recover reliably from the following failures:

Disk Failure: The latest backup media is required to recover the database content.

Data Corruption: File systems do not record past transactions, and systems may accidentally overwrite required process data.

User Error: Recovery is limited to the data that is made available by the database. If the data was stored and is available, recovery is simplified.

Power Outage, System Crash: File system APIs are often not designed or used in a robust manner that guards against unexpected system failures. If a power outage or system crash occurs, document content that is stored in the database is more likely to be up to date than content that is stored on a file system.

If you are using rolling backup mode, you are still in backup mode after recovery. If you are using snapshot backup mode, you are not in backup mode after recovery.

When restoring from backup to a new system, the following configurations may be different. This difference should not affect a successful recovery of the LiveCycle application:

  • IP address

  • Physical system configuration (CPUs, disk, memory)

  • GDS location

Important: The backup of the Content Storage Root directory must be restored to the location of that directory as it was set during Content Services configuration.

If a single node of a multinode cluster failed and the remaining nodes of the cluster are operating properly, perform the cluster single-node recovery procedure.

    Recover the LiveCycle data

    1. Stop the LiveCycle services and application server if running.

    2. If necessary, re-create the physical system from a system image. For example, this step may not be necessary if the reason for recovery is a faulty database server.

    3. Apply patches or updates to LiveCycle that were applied since the image was made. This information was recorded in the backup procedure. LiveCycle must be patched to the same patch level as it was when the system was backed up.

    4. (WebSphere Application Server) If you are recovering to a new instance of WebSphere Application Server, run the restoreConfig.bat/sh command.

    5. Recover the LiveCycle database by first running a database restore operation using the database backup files and then applying the transaction redo logs to the recovered database. (See LiveCycle database.) For more information, see one of these knowledge base articles:

    6. Recover the GDS directory by first deleting the contents of the GDS directory on the existing installation of LiveCycle and then copying the contents of the GDS directory from the backed-up GDS. If you changed the GDS directory location, see Changing the GDS location during recovery.

    7. Rename the GDS backup directory to be restored as shown in these examples:

      Note: If the /restore directory already exists, back it up and then delete it before you rename the /backup directory that contains the latest data.

      • (JBoss) Rename [appserver root]/server/[server]/svcnative/DocumentStorage/backup to:

        [appserver root]/server/[server]/svcnative/DocumentStorage/restore.

      • (WebLogic) Rename [appserverdomain]/[server]/adobe/LiveCycleServer/DocumentStorage/backup to:

        [appserverdomain]/[server]/adobe/LiveCycleServer/DocumentStorage/restore.

      • (WebSphere) Rename [appserver root]/installedApps/adobe/[server]/DocumentStorage/backup to:

        [appserver root]/installedApps/adobe/[server]/DocumentStorage/restore.

    8. Recover the Content Storage Root directory by first deleting the contents of the Content Storage Root directory on the existing installation of LiveCycle and then recovering the contents by following the tasks for either stand-alone or clustered environments:

      Important: The backup of the Content Storage Root directory must be restored to the location of the Content Storage Root directory as it was set during Content Services (Deprecated) configuration.

      Standalone: During the recovery process, restore all the directories that were backed up. When these directories are restored, if the /backup-lucene-indexes directory is present, rename it to /lucene-indexes. Otherwise, the lucene-indexes directory should already exist and no action is required.

      Clustered: During the recovery process, restore all the directories that were backed up. To restore the Index Root directory, perform the following steps on each node of the cluster:

      • Delete all content in the Index Root directory.

      • If the /backup-lucene-indexes directory is present, copy the contents of the Content Storage Root directory/backup-lucene-indexes directory to the Index Root directory and delete the Content Storage Root directory/backup-lucene-indexes directory.

      • If the /lucene-indexes directory is present, copy the contents of the Content Storage Root directory/lucene-indexes directory to the Index Root directory.

    9. Restore/recover the CRX-repository.

      • Standalone

        Restore author and publish instances: If a disaster occurs, you can restore the repository to the last backed up state by performing the steps described in Backup and Restore.

        The complete restoration of Author node ascertains the restoration of Forms Manager and HTML Workspace data as well.

      • Clustered

        For restoration in a clustered environment, see Strategy for backup and restore in a clustered environment.

    10. Delete any LiveCycle temporary files that were created in the java.io.temp directory or in the Adobe temp directory.

    11. Start LiveCycle (see Starting and stopping services) and the application server(s) (see Maintaining the Application Server).

    Changing the GDS location during recovery

    If your GDS is restored to a location other than where it was originally, run the LCSetGDS script to set the GDS to the new location. The script is in the [LiveCycle root]\sdk\misc\Foundation\SetGDSCommandline folder. The script takes two parameters, defaultGDS and newGDS. See the ReadMe.txt file in the same folder for instructions on how to run the script.

    Note: If you had enabled document storage in database, you don’t need to change the GDS location.
    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.)
    Important: Component deployment will fail on Windows if the GDS directory is at the drive root (for example, D:\). For GDS, you must make sure that the directory is not located at the root of the drive but is located in a subdirectory. For example, the directory should be D:\GDS and not simply D:\.

    Recovering the GDS to a clustered environment

    To change the GDS location in a clustered environment, shut down the entire cluster and run the LCSetGDS script on a single node of the cluster. (See Changing the GDS location during recovery.) Start only that node. When that node is fully started, other nodes in the cluster may be started safely and will correctly point at the new GDS.

    Note: If you cannot ensure starting one node completely before starting other nodes, you must run the LCSetGDS script on every node in the cluster before you start the cluster.

    // Ethnio survey code removed