This chapter describes the backing up and restoring files and data in Oracle Communications Contacts Server.
Contacts store backup and restore is one of the most important administrative tasks for your Contacts Server deployment. You must implement a backup and restore policy for your contacts store to ensure that data is not lost if problems such as system crashes, hardware failures, or accidental deletion of information occur.
This chapter describes the options for backing up and restoring the Contacts Server database (either MySQL database or Oracle Database), and the document store. You need to understand the pros and cons of these options to make the proper choice for your deployment.
This information also assumes that you are backing up your LDAP Directory Server. Contacts Server uses Directory Server to authenticate users, groups, and resources. Contacts Server uses the davUniqueId LDAP attribute to map each contacts entry (in LDAP) to a unique account in the contacts store. The unique identifier links various entries from different database tables for a user, group, and resource. You must use a unique identifier, and one that does not change, for user, group, and resource entries stored in LDAP.
The section describes the ways to back up the Contacts Server data store.
Note:
You cannot back up Contacts Server by backing up the active contacts database and the Contacts Server data directory while Contacts Server is running. If you do so, bad data results. Thus, you must use one of the methods described in this section.Contacts Server provides the davadmin db backup and davadmin db restore commands to back up and restore the Contacts Server data.
Pros:
Supports partial backup and restore.
You can also use backup and restore to migrate data from one Contacts Server host to another.
Cons:
The davadmin db backup command is relatively slow.
The davadmin db restore command might take longer than the backup command, as it needs to rebuild the database and indexes.
You can use Oracle Solaris ZFS snapshots to produce an atomic snapshot of the file system containing the MySQL database or Oracle Database and the document store. Then use zfs send or third-party file system backup software to back up the snapshot. See ZFS Administration Guide for more information.
Pros:
Performance is better than davadmin db backup.
Cons:
This method does not support partial backup and restore.
The following methods back up the MySQL Server database only. For general information about MySQL Server backup and restore, see the MySQL Server database documentation at:
http://dev.mysql.com/doc/refman/5.5/en/backup-and-recovery.html
MySQL Async Replication
Use MySQL replication to replicate the databases. See the MySQL Async Replication documentation at:
MySQL database dump
Use mysqldump to dump the databases for backup or transfer to another SQL server. See documentation about mysqldump at:
Point-in-time backup and recovery using the binary log.
The binary log files provide you with the information you need to replicate changes to the database. See the documentation about point-in-time backup and recovery documentation using the binary log at:
http://dev.mysql.com/doc/refman/5.5/en/point-in-time-recovery.html
For general information about Oracle Database backup and restore, see the Oracle Database documentation at:
http://docs.oracle.com/cd/E11882_01/nav/portal_14.htm#backup_and_recovery