If your AEM forms implementation stores additional custom data in a different database, you are responsible for implementing a strategy to back up this data and ensuring that it remains in sync with the AEM forms data. Also, the application must be designed so that it is robust enough to handle a scenario where the additional databases get out of sync. It is highly recommended that any database operation that is performed is done in the context of a transaction to help maintain a consistent state.
After you identify how AEM forms is used, determine which files must be backed up, how often, and the backup window to be made available.
As with any other aspect of your AEM forms implementation, your backup and recovery strategy must be developed and tested in a development or staging environment before being used in production to ensure that the entire solution is working as expected with no data loss.
Adobe Experience Manager (AEM) is an integral part of AEM forms. Therefore, you need to back up AEM as well in sync with AEM forms backup as Correspondence Management Solution and services, such as forms manager are based on data stored in AEM part of AEM forms.To prevent any data loss, the AEM forms 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.
The AEM forms 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 AEM forms. Internal corporate policies then dictate how often system image backups are required.
AEM forms 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.
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 AEM forms 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.
continuousCoverage
parameter to false
or use the leaveContinuousCoverage
option.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.
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 AEM forms specific data must be backed up in a way that ensures that GDS and Content Storage Root directory documents correlate with database references.
When the GDS is stored on the file system and not in the database, perform the database backup before the GDS backup.
Use the following guidelines if you must recover AEM forms into a different environment because of the following changes:
Typically, such recovery scenarios are caused by hardware failure of the server that hosts the application server, database server, or Forms Server. In addition to the AEM forms-specific configurations that are described in this section, you should also make the necessary changes for other parts of the AEM forms deployment such as load balancers and firewalls, if the hostname or IP address of an AEM Forms Server changes.
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 AEM forms from a backup. For example, if you are recovering an AEM forms backup, you cannot change the application server from JBoss to WebLogic or database from Oracle to DB2. In addition, recovered AEM forms must use the same file system paths such as the fonts directory.
Before you restart the Forms Server after a recovery, do the following:
Start the system in maintenance mode.
Do the following to ensure that Form Manager is synced with AEM forms in the maintenance mode:
In a clustered environment, the primary node (with respect to AEM) should be up before the secondary nodes.
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 AEM forms database is moved or changed, review the install Guides relevant to your application server for information on updating the database connection information for the AEM forms data sources IDP_DS and EDC_DS.
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.
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 AEM forms applications. On the other hand, for a cluster, all nodes must use the same file system path configuration. 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 [*aem-forms 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 AEM forms.
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*.) *
After you set the GDS path, start the Forms 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 the necessary configurations are updated, restart and test AEM forms.