DocumentationAEM 6.4Forms Guide

Recovering the AEM forms data recovering-the-aem-forms-data

Last update: Wed May 03 2023 00:00:00 GMT+0000 (Coordinated Universal Time)

CREATED FOR:

  • User
CAUTION
AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our technical support periods. Find the supported versions here.

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

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

AEM forms 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 AEM forms application:

  • IP address
  • Physical system configuration (CPUs, disk, memory)
  • GDS location
NOTE
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 AEM forms data recover-the-aem-forms-data

  1. Stop the AEM forms 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 AEM forms that were applied since the image was made. This information was recorded in the backup procedure. AEM forms 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 AEM forms 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 AEM forms 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 AEM forms 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 note
    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/AEMformsserver/DocumentStorage/backup to:

      [appserverdomain]/[server]/adobe/AEMformsserver/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 AEM forms and then recovering the contents by following the tasks for either stand-alone or clustered environments:

    note note
    NOTE
    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 AEM Forms Workspace data as well.

    • Clustered

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

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

  11. Start AEM forms (see Starting and stopping services).

Changing the GDS location during recovery 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 [aem-forms 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.
NOTE
This circumstance is the only one under which you should use this script to change the GDS location. To change the GDS location while AEM forms is running, use Administration Console. (See Configure general AEM forms settings.)
NOTE
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 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.
recommendation-more-help
a6ebf046-2b8b-4543-bd46-42a0d77792da