|
The LiveCycle database stores content such as form artifacts,
service configurations, process state, and database references to
files in the GDS and the Content Storage Root directory (for Content
Services). Database backups can be performed in real time without
an interruption in service, and recovery can be to a specific point
in time or to a particular change. This section describes how to configure
your database so that it can be backed up in real time.
On a properly configured LiveCycle system, the system administrator
and the database administrator can easily collaborate to recover
the system to a consistent, known state.
To back up the database in real time, you must either use snapshot
mode or configure your database to run in the specified log mode.
This allows your database files to be backed up while the database
is open and available for use. Furthermore, the database preserves
its rollback and transaction logs when it is running in these modes.
Note: Adobe® LiveCycle® Content Services
ES (Deprecated) is a content management system installed with LiveCycle.
It enables users to design, manage, monitor, and optimize human-centric
processes. Content Services (Deprecated) support ends on 12/31/2014.
See Adobe product lifecycle document.
To know about configuring Content Services (Deprecated), see Administering Content Services.
DB2Configure your DB2 database to run in archive log mode.
Important: If your LiveCycle environment was upgraded
from a previous version of LiveCycle and uses DB2, online backup
is not supported. In this case, you must shut down LiveCycle and
perform an offline backup. Future versions of LiveCycle will support
online backup for upgrade customers.
IBM has a suite of tools and help systems to help database administrators manage
their backup and recovery tasks:
DB2 has built-in capabilities to back up a database to Tivoli
Storage Manager. By using Tivoli Storage Manager, DB2 backups can
be stored on other media or the local hard drive.
For more information about DB2 database backup and recovery,
see Developing a backup and recovery strategy
for DB2.
OracleUse snapshot backups or configure your Oracle database
to run in archive log mode. (See Oracle Backup: An Introduction.) For
more information about backing up and recovering your Oracle database,
go to these sites:
Oracle Backup and Recovery: Explains
the concepts of backup and recovery and the most common techniques
for using Recovery Manager (RMAN) for backup, recovery, and reporting
in more detail, as well as providing more information about how
to plan a backup and recovery strategy.
Oracle Database Backup and Recovery User's
Guide: Provides in-depth information about RMAN architecture,
backup and recovery concepts and mechanisms, advanced recovery techniques
such as point-in-time recovery and database flashback features,
and backup and recovery performance tuning. It also covers user-managed
backup and recovery, using host operating system facilities instead
of RMAN. This volume is essential for backup and recovery of more
sophisticated database deployments and for advanced recovery scenarios.
Oracle Database Backup and Recovery Reference: Provides
complete information about syntax and semantics for all RMAN commands,
and describes the database views that are available for reporting
on backup and recovery activities.
SQL ServerUse snapshot backups or configure your SQL Server database
to run in transaction log mode.
SQL Server also provides two backup and recovery tools:
See Backup Strategies and Backup and Restore.
MySQLUse MySQLAdmin or modify the INI files in Windows to configure
your MySQL database to run in binary log mode. (See MySQL binary logging.) A hot backup tool
for MySQL is also available from InnoBase software. (See Innobase Hot Backup.)
Note: The default binary logging mode for MySQL is "Statement",
which is incompatible with tables used by Content Services (Deprecated).
Using binary logging in this default mode causes Content Services
(Deprecated) to fail. If your system includes Content Services (Deprecated),
use "Mixed" logging mode. To enable "Mixed" logging, add the following
argument to the my.ini file:
binlog_format=mixed
log-bin=logname
You can use the mysqldump utility to obtain the full database
backup. Full backups are required, but they are not always convenient.
They produce large backup files and take time to generate. To do
an incremental backup, ensure that you start the server with the
–log-bin option as described in the previous section.
Each time the MySQL server restarts, it stops writing to the current
binary log, creates a new one and, from then on, the new one becomes
the current one. You can force a switch manually with the FLUSH LOGS SQL command.
After the first full backup, subsequent incremental backups are
done by using the mysqladmin utility with the flush-logs command,
which creates the next log file.
See Backup Strategy Summary.
|
|
|
