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:
Enable hot backups by setting the following ics.conf parameter to “yes”:
Specify the directory path for the hot backup 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:
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.