This chapter describes backing up and restoring files and data in Oracle Communications Calendar Server.
Calendar store backup and restore is one of the most important administrative tasks for your Calendar Server deployment. You must implement a backup and restore policy for your calendar store to ensure that data is not lost if problems such as system crashes, hardware failures, or accidental deletion of information occur.
This information describes the two options for backing up and restoring the Calendar Server calendar store (either MySQL database or Oracle Database, and the document store). You must understand the pros and cons of these solutions to make the proper choice for your deployment.
Note:
You cannot back up the Calendar Server store by backing up the active calendar database and the Calendar Server data directory while Calendar Server is running. If you do so, bad data results. Thus, you must use one of the two methods described in this information.Caution:
You can view contents of the back-end store by using standard MySQL or Oracle Database tools. Do not use MySQL or Oracle Database tools to modify your data.This information also assumes that you are backing up your LDAP Directory Server. Calendar Server stores user, group, and resource information in LDAP. Calendar Server uses the davUniqueId LDAP attribute to map each calendar entry (in LDAP) to a unique account in the calendar 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. For more information, see the topic on Calendar Server unique identifier in Calendar Server Concepts.
The section describes the following ways to back up the Calendar Server data store:
Calendar Server provides the davadmin db backup command to back up the calendar server data.
Pros:
Supports partial backup and restore.
You can also use backup and restore to migrate data from one Calendar 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.
Use Oracle Solaris ZFS snapshots to produce an atomic snapshot of the file system containing the MySQL database or Oracle Database and the attachment store. Then use zfs send or a 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 database only. For general information about MySQL backup and restore, see the MySQL documentation at:
http://dev.mysql.com/doc/refman/5.1/en/backup-and-recovery.html
Use MySQL asynchronous replication to replicate the databases. For more information, see the MySQL documentation at:
Use mysqldump to dump the databases for backup or transfer to another SQL server. For more information, see the MySQL documentation at:
The binary log files provide you with the information you must use to replicate changes to the database. For more information, see the MySQL documentation at:
http://dev.mysql.com/doc/refman/5.1/en/point-in-time-recovery.html
For general information about Oracle Database backup and restore, see the backup and recovery documentation at:
http://docs.oracle.com/cd/E11882_01/nav/portal_14.htm#backup_and_recovery