|
After you identify how LiveCycle is used, determine which
files must be backed up, how often, and the backup window to be
made available.
Important: As with any other aspect of your LiveCycle
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 LiveCycle.
Therefore, you need to back up AEM as well in sync with LiveCycle
backup as Correspondence Management Solution and services, such
as Forms Manager are based on data stored in AEM part of LiveCycle.To
prevent any data loss, the LiveCycle 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 backupsThe LiveCycle 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 LiveCycle. Internal corporate policies then dictate how often
system image backups are required.
- LiveCycle 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:
Snapshot backup mode indicates that the LiveCycle
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.
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 LiveCycle specific data
must be backed up in a way that ensures that GDS and Content Storage
Root directory documents correlate with database references.
Important: When the GDS is stored on the file system
and not in the database, perform the database backup before the
GDS backup.
Special considerations for backup and recoveryUse the following guidelines if you must recover LiveCycle into
a different environment because of the following changes:
Change in the IP address, hostname, or port of the LiveCycle
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 LiveCycle server. In addition to the LiveCycle-specific configurations
that are described in this section, you should also make the necessary
changes for other parts of the LiveCycle deployment such as load
balancers and firewalls, if the hostname or IP address of a LiveCycle
server changes.
What cannot be changedEven though you can change the database server and many
other parameters, you cannot change the application server type
or database type when you recover LiveCycle from a backup. For example,
if you are recovering a LiveCycle backup, you cannot change the
application server from JBoss to WebLogic or database from Oracle
to DB2. In addition, recovered LiveCycle must use the same file
system paths such as the fonts directory.
Restarting after a recoveryBefore you restart the LiveCycle server after a recovery,
do the following:
Start the system in maintenance mode.
Do the following to ensure that Form Manager is synced with
LiveCycle in the maintenance mode:
Go to http://<server>:<port>/lc/fm
and log in using adminstrator/password credentials.
Click the name of the user (Super Administrator in this case)
at top-right corner.
Click Admin Options.
Click Start to synchronize assets from the repository.
In a clustered environment, the master node (with respect
to AEM) should be up before the slave 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 LiveCycle database is moved or changed, review the
install guides relevant to your application server for information
on updating the database connection information for the LiveCycle
data sources IDP_DS and EDC_DS.
Changing the LiveCycle hostname or IP addressIn 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 LiveCycle node file system pathsIf 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 LiveCycle
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[LiveCycle 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 LiveCycle.
Important: This circumstance is the only one under
which you should use this script to change the GDS location. To
change the GDS location while LiveCycle is running, use Administration
Console. (See Configure general LiveCycle settings.)
After you set the GDS path, start the LiveCycle 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 of
the necessary configurations are updated, restart and test LiveCycle.
|
|
|
