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:
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.
This section covers the following topics:
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.
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).
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.
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.
The following is a high-level list of the tasks to perform to enable automatic backups:
This section covers the following topics:
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.
At a command line, change to the directory where the ics.conf is located:
cd/etc/opt/SUNWics5/config
Specify the transaction log name:
logfile.store.logname=storename.log
Specify the directory path for the transaction log directory:
The default value is: logfile.logdir="logs"
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.
This section covers the following topics:
When certain events or errors occur, the administrator is notified by email. The events causing an email message to be generated are:
Automatic backups not enabled or not configured properly.
Every 24 hours, when its time to take a snapshot, if automatic backups are not enabled, the csstored process reports that automatic backups are not properly configured.
The disk space threshold has been exceeded.
This message is sent out periodically until the condition has cleared.
A service has stopped and can’t be restarted.
The notification email will explain what required action is needed before the service can be started.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameter that follows to specify the administrator’s email address:
alarm.msgalarmnoticercpt=”admin@email_address”
Save the file as ics.conf.
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.
This section covers the following topics:
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.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable hot backups by setting the following ics.conf parameter to “yes”:
caldb.berkeleydb.hotbackup.enable=”yes”
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).
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.
This section covers the following topics:
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.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable archive backups by setting the following ics.conf parameter to “yes”:
caldb.berkeleydb.archive.enable=”yes”
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).
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.
This section describes the daily warning message from an unconfigured csstored process and how to stop it. This section contains the following topics:
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Add the parameter that follows to the ics.conf file to disable csstored from running:
service.store.enable="no"
Save the file as ics.conf.
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.
Be sure not to disable csstored on machines where you have csstored configured for automatic backups.