This section describes the steps required to recover the AEM forms data. Also see Special considerations for backup and recovery.
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:
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 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:
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.
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:
(WebLogic) Rename [appserverdomain]/[server]/adobe/AEMformsserver/DocumentStorage/backup to:
(WebSphere) Rename [appserver root]/installedApps/adobe/[server]/DocumentStorage/backup to:
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:
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.
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.
For restoration in a clustered environment, see Strategy for backup and restore in a clustered environment.
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.
If you had enabled document storage in database, you don’t need to change the GDS location.
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.)
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:\.
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.
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.