Best Practices for Backing up and Restoring MySQL Databases in Calendar Server Deployments

Skip to end of metadata
Go to start of metadata

This documentation applies to Communications Suite 6 Update 2 at the time of its release. The most up-to-date documentation is available at the Communications Suite Documentation Home.

 Work in progress banner for Comms Suite wiki.

Unable to render {include} Couldn't find a page to include called: Features Under Development

Best Practices for Backing Up and Restoring MySQL Databases in Calendar Server Deployments

This information is intended for use by Calendar Server 7 installations that use the MySQL database for the calendar store.

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 your options for backing up and restoring the calendar store (MySQL database). You need to understand the pros and cons of these solutions to make the proper choice for your deployment.

Note
You can also use backup and restore to migrate data from one Calendar Server host to another.

MySQL Backup and Restore Techniques

For general information about MySQL backup and restore, see http://dev.mysql.com/doc/refman/5.1/en/backup-and-recovery.html.

The following lists recommended backup techniques for the calendar store:

Other Commercial Backup Products

Labels:
zfs zfs Delete
caldavserver caldavserver Delete
wip wip Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Sign up or Log in to add a comment or watch this page.


The individuals who post here are part of the extended Oracle community and they might not be employed or in any way formally affiliated with Oracle. The opinions expressed here are their own, are not necessarily reviewed in advance by anyone but the individual authors, and neither Oracle nor any other party necessarily agrees with them.