Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Three-Disk Configuration
Whenever possible, use a third disk to protect the boot environments of systems with high availability requirements. This third disk could be used as a hot spare for the mirror, but in most cases, this is not optimal. Instead, we recommend that you configure the disk as a contingency system disk.
A contingency disk is a disk that contains backup / and /var file systems. These file systems are mounted at regular intervals and are synchronized with the active / and /var file systems. During the rest of the time, the file systems are unmounted and inaccessible.
The system and vfstab files on the contingency disk are modified to remove any dependencies on a volume manager. The contingency disk is made bootable and, as such, provides instant recovery from the accidental removal or corruption of system files (or of entire file systems) that are essential for booting. A contingency disk can also provide recovery from a failure of the only remaining disk in the mirror before the broken disk is replaced and completely synchronized.
A contingency disk is more likely to prove its usefulness during the lifetime of a server than a hot spare disk. Especially at those moments where an important reconfiguration or intervention is planned, it is very comforting to know that the contingency disk is there as a safety net (versus a much less attractive recovery from tape).
The protection provided by a contingency disk is not absolute. When a system file is modified or removed, the impact may not be seen until the next boot. By then, errors may have propagated to the contingency disk. While you should be aware that this is possible, it is rather unlikely. Bootability problems usually result from mistakes or setbacks that occur during major software or hardware reconfigurations, and they generally appear immediately.
Absolute protection can only be provided by synchronizing the contingency disk manually, on scheduled maintenance, after verifying that the system boots correctly. Between these maintenance slots, incremental backups must be made and stored separately, and must not be directly applied to the contingency disk.
Note that in the runbook we have chosen ufsdump to create the contingency disk. Another option would be to use Live Upgrade software. Refer to the Solaris Live Upgrade Guide at http://docs.sun.com for more information.