test

Sun Java System Calendar Server 6.3 Administration Guide

Chapter 9 Configuring Automatic Backups (csstored)

At configuration time you are given the opportunity to enable automatic backups. However, you can also enable or disable automatic backups at any time thereafter. A good backup system is essential to safeguard your data and minimize operational downtime.

Information in this chapter explains how to configure the Calendar Server service csstored to perform automatic backups.

Note –

If you choose not to use the automatic backup process discussed here, you must implement your own backup strategy to safeguard your data. For information on how to use other Calendar Server tools for protecting your data, see Chapter 17, Backing Up and Restoring Calendar Server Data.

For an overview of csstored, see the Sun Java Communications Suite 5 Deployment Planning Guide.

9.1 Enabling the Calendar Server Store Service (csstored)

The store service must be enabled in the ics.conf file. Verify that the store service is enabled by setting the following ics. conf file parameter is set to "yes":

local.store.enable

If this parameter is set to "yes", each service that accesses the store depends on the successful start up of the store service.

9.2 Overview of Automatic Backups in a Calendar Server 6.3 System

This section is an overview of how automatic backups are implemented in a Calendar Server system.

This section covers the following topics:

9.2.1 How Automatic Backups Work in a Calendar Server 6.3 System

The Calendar Server system records each transaction for the calendar database (additions, modifications or deletions to calendars and their properties) in a transaction log file. At some predetermined interval, the log file is closed for writing and another is created. The system then applies the transactions from the oldest closed transaction log to the live calendar databases as time permits. When all the transactions in the log have been applied to the database, the log is marked as “already applied”.

When hot backups are configured, a snapshot of the live databases is taken every 24 hours. The already applied logs are then applied to the hot backup copy of the databases. The hot backup databases are as current as the number of transactions still waiting to be applied.

9.2.2 How csstored Works for Backups in a Calendar Server 6.3 System

One of the Calendar Server services launched at startup is csstored. When configured, this service performs automatic backups (either hot backups or archival backups, or both) of your calendar databases.

You can configure csstored for automatic backups when you run the configuration program, csconfigurator.sh. If you choose one or both of the automatic backups at that time, no further configuration steps are necessary.

If csstored is disabled, none of the other daemons that access the database will work. The csstored daemon performs other necessary tasks for the databases. Therefore, the daemon should not be disabled.

Note –

When automatic backups are disabled, the circular logging ics.conf parameter, caldb.berkeley.circularlogging, should be set to "yes". This enables purging of old database transaction logs, which conserves disk space.

9.2.3 How Circular Backups Work in a Calendar Server 6.3 System

With automatic backups enabled, csstored automatically manages the number of backup copies retained in your backup database files using a circular backup system.

The csstored process stores backups in your backup database directory until either the maximum number of backup copies have accumulated, or the maximum disk space allowed has been reached. At that point, it purges backup copies (oldest first) until it reaches the minimum number of copies to retain and it is under the disk space threshold.

There are a cluster of ics.conf parameters that control circular backups. These parameters have default values, and do not require further customization. If you wish to tune how backups work in your system, see 21.7 Tuning Automatic Backups.

9.2.4 High Level Steps for Enabling Automatic Backups

If you did not configure automatic backups when you ran the configuration file, you can set them up later. This section contains a list of high-level steps necessary for enabling automatic backups for the Calendar Server 6.3 system after the configuration program has already run.

The following is the list of high-level tasks:

9.3 Setting up Transaction Log Files for Calendar Server 6.3 Backups

This section contains both overview and instructions for setting up transaction log files.

This section covers the following topics:

9.3.1 Understanding Transaction Log Files for Calendar Server 6.3 Backups

Transaction log files are used by Calendar Server to capture all of the additions, modifications and deletions made to the calendar database since the latest snapshot. The transactions are not actually applied to the live database until the log file is closed for writing. The interval parameter specifies how often the old log files are closed and new log files are created.

The log file names consist of a configurable name with a unique number appended to the end.

As the log files are closed, they are ready to be applied to the live database. This happens asynchronously, meaning the creation of log files and the writing of transactions into them is done in “real time”, whereas the program applying the transactions to the database is running independently, without regard to the writing of the transactions into the log files. If the system is very busy, the number of log files awaiting application to the database can rise. When the system has slow periods, the program applying the transactions has time to “catch up” and may actually sit idle, waiting for the next transaction log.

After the transactions have been applied to the live database, they are applied to the hot backup snapshot (if enabled). The log files are also written to the same archive directory where the snapshot resides.

ProcedureTo Set up Transaction Log Files

  1. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  2. Specify the transaction log name:

    logfile.store.logname=storename.log

  3. Specify the directory path for the transaction log directory:

    The default value is: logfile.logdir="logs"

  4. When you have completed editing the ics.conf file, restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.4 Specifying the Calendar Server Administrator’s Email Address

This section contains overview and instructions for setting the Calendar Server administrator's email address.

This section covers the following topics:

9.4.1 Email Messages Sent to the Administrator

When certain events or errors occur, the administrator is notified by email.

The events causing an email message to be generated are:

ProcedureTo Set the Calendar Server 6.3 System Administrator’s Email Address

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit the ics.conf parameter that follows to specify the administrator’s email address:

    alarm.msgalarmnoticercpt="admin@email_address"

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.5 Enabling Hot Backups for Calendar Server 6.3 Databases

This section contains an overview and instructions for enabling hot backups for Calendar Server 6.3 databases, if you did not configure them when you ran the configuration program.

This section covers the following topics:

9.5.1 What are Hot Backups in Calendar Server Version 6.3?

Ideally, hot backups consist of the latest snapshot with all of the transaction logs applied to the it, except the transaction log currently being written. The system can get behind in applying the transaction logs, depending on how busy the system is. It is possible that there might be several log files that have not yet been applied to either the database or the hot backup.

This “almost duplicate” of the live database is designed to minimize down time and data loss if something catastrophic happens, or if a corruption of the database is detected.

A new hot backup is started every 24 hours when a new snapshot is taken. The old hot backup is verified and kept until purged. For more information, see 9.2.3 How Circular Backups Work in a Calendar Server 6.3 System.

ProcedureTo Enable Hot Backups for a Calendar Server 6.3 System

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  4. Enable hot backups by setting the following ics.conf parameter to "yes":

    caldb.berkeleydb.hotbackup.enable="yes"

  5. Specify the directory path for the hot backup directory:

    caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory

    The default hot backup directory for Calendar Server is /var/opt/SUNWics5/csdb for Solaris and /var/opt/sun/calendar/csdb for Linux. The Communications Suite installer puts the archive and hot backup directories in the csdb directory by default because it is the convenient subdirectory that is known to the installer.

    Note –

    It is highly recommended that the Calendar Server administrator needs to put the archive and hot backup in a different disk or volume or partition than the csdb directory because of the size issues.

    The number of archive and hot backup directories is configurable. So, if you choose to have six of each archive and hot backup directories, it means that they might have 6 + 6 + 1 copies of your live database in the csdb directory. The csstored utility calculates the size of the required archive and hot backup based off of the size of the contents of the csdb directory and the physical disk that csdb is located on.

    The archive and hot backup directories are installed inside the csdb directory by default for convenience. But, it should be located in a directory outside of csdb for a real life deployment.

    You might choose to place hot backups on an alternate disk or disk subsystem in case of a hardware failure on the primary disk drive. Doing this might also reduce input-output contention on the primary drive or subsystem.

    If you have a high availability (HA) configuration, specify the path as a subdirectory in shared storage (/global/cal/). See also, Chapter 6, Configuring Calendar Server 6.3 Software for High Availability (Failover Service).

  6. When you have completed editing the ics.conf file, restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.6 Enabling Archive Backups for Calendar Server 6.3 Databases

This section contains overview material and instructions for enabling archival backups for Calendar Server databases if you did not configure them when the configuration program ran.

This section covers the following topics:

9.6.1 What are Archive Backups in Calendar Server Version 6.3?

Archive backups consist of a snapshot and the log files that were created for it. The log files are not applied to the snapshot. The archive databases remain on disk until purged. See 9.2.3 How Circular Backups Work in a Calendar Server 6.3 System.

ProcedureTo Enable Archive Backups for a Calendar Server 6.3 System

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  4. Enable archive backups by setting the following ics.conf parameter to “yes”:

    caldb.berkeleydb.archive.enable=”yes”

  5. Specify the directory path for the archive directory:

    caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/archive_backup_directory

    You might choose to place the archive backups on an alternate disk or disk subsystem in case of a hardware failure on the primary disk drive. Doing this might also reduce I/O contention on the primary drive or subsystem.

    If you have a high availability (HA) configuration, specify the path as a subdirectory in shared storage (/global/cal/). See also, Chapter 6, Configuring Calendar Server 6.3 Software for High Availability (Failover Service).

  6. When you have completed editing the ics.conf file, restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.