Backup and recovery strategy for AEM forms backup-and-recovery-strategy-for-aem-forms

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.

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.

Types of backups types-of-backups

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.

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:

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.

Special considerations for backup and recovery special-considerations-for-backup-and-recovery

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.

What cannot be changed what-cannot-be-changed

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.

Restarting after a recovery restarting-after-a-recovery

Before you restart the Forms Server after a recovery, do the following:

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.

Changing the AEM forms hostname or IP address changing-the-aem-forms-hostname-or-ip-address

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.

Changing the AEM forms node file system paths changing-the-aem-forms-node-file-system-paths

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 LCSetGDSscript 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.

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.