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 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 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.
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.
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 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.
Use the Backup Settings page in Administration Console. To enter snapshot mode, select the Operate In Safe Backup Mode checkbox. Deselect the checkbox to exit snapshot mode.
Use the LCBackupMode script (see Back up the database, GDS, and Content Storage Root directories). To exit snapshot backup mode, in the script argument, set the continuousCoverage parameter to false or use the leaveContinuousCoverage option.
Use the supplied Backup/Recovery API (see AEM forms API Reference section on AEM Forms Help and Tutorials page).
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 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:
Change in the IP address, hostname, or port of the AEM forms 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 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 a 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 a 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.
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. 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[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.)