Sun Java System Calendar Server 6 2005Q4 Administration Guide

Chapter 10 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. It contains the following sections:


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 System Communications Services 6 2005Q4 Deployment Planning Guide.

Automatic Backups Overview

This section covers the following topics:

How Automatic Backups Work

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.

How csstored Works

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 you did not choose automatic backups in the configuration program, they are disabled, but the csstored process still runs. However, until automatic backups are enabled, the only function csstored performs is to generate an informational administrator message every 24 hours saying csstored is not configured (meaning automatic backups have not been enabled).


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.


How Circular Backups Work

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

csstored 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 Tuning Automatic Backups.

High Level Steps for Enabling Automatic Backups

The following is a high-level list of the tasks to perform to enable automatic backups:

Setting up Transaction Log Files

This section covers the following topics:

Understanding Transaction Log Files

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

    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.

Specifying the Administrator’s Email Address

This section covers the following topics:

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 Administrator’s Email Address

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

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

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

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

    alarm.msgalarmnoticercpt=”admin@email_address

  5. Save the file as ics.conf.

  6. 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.

Enabling Hot Backups

This section covers the following topics:

What are Hot Backups?

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 How Circular Backups Work.

ProcedureTo Enable Hot Backups

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

    cd /etc/opt/SUNWics5/config

  2. Enable hot backups by setting the following ics.conf parameter to “yes”:

    caldb.berkeleydb.hotbackup.enable=”yes”

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

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

    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 7, Configuring for High Availability (Failover Service).

  4. 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.

Enabling Archive Backups

This section covers the following topics:

What are Archive Backups?

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 How Circular Backups Work.

ProcedureTo Enable Archive Backups

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.archive.enable=”yes”

  3. 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 7, Configuring for High Availability (Failover Service).

  4. 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.

Disabling the Warning Message

This section describes the daily warning message from an unconfigured csstored process and how to stop it. This section contains the following topics:

Why is the Message Emitted?

The start-cal program starts the csstored process by default. If you have chosen not to configure csstored for your backups on a back-end machine, or you have a front-end machine that does not contain any databases that need to be backed up, you will still receive informational messages every 24 hours, from every machine not configured. If you do not want these messages to be emitted by csstored, you must disable csstored from running.

ProcedureHow to Disable csstored from Running

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

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

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

  4. Add the parameter that follows to the ics.conf file to disable csstored from running:

    service.store.enable="no"

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    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.


    Note –

    Be sure not to disable csstored on machines where you have csstored configured for automatic backups.