Unmirroring – The Enhanced Storage tool within the Solaris Management Console does not support unmirroring root (/), /opt, /usr, or swap, or any other file system that cannot be unmounted while the system is running. Instead, use the command-line procedure for these file systems.
Attaching – You can attach a submirror to a mirror without interrupting service. You attach submirrors to mirrors to create two-way and three-way mirrors.
Detach vs. Offline – When you place a submirror offline, you prevent the mirror from reading from and writing to the submirror, but you preserve the submirror's logical association to the mirror. While the submirror is offline, Solaris Volume Manager keeps track of all writes to the mirror and they are written to the submirror when it is brought back online. By performing an optimized resynchronization, Solaris Volume Manager only has to resynchronize data that has changed, not the entire submirror. When you detach a submirror, you sever its logical association to the mirror. Typically, you place a submirror offline to perform maintenance. You detach a submirror to remove it.
Before you create a mirror, create the RAID 0 (stripe or concatenation) volumes that will make up the mirror.
Any file system including root (/), swap, and /usr, or any application such as a database, can use a mirror.
When you create a mirror for an existing file system, be sure that the initial submirror contains the existing file system.
When creating a mirror, first create a one-way mirror, then attach a second submirror. This strategy starts a resynchronization operation and ensures that data is not corrupted.
You can create a one-way mirror for a future two-way or three-way mirror.
You can create up to a three-way mirror. However, two-way mirrors usually provide sufficient data redundancy for most applications, and are less expensive in terms of disk drive costs. A three-way mirror enables you to take a submirror offline and perform a backup while maintaining a two-way mirror for continued data redundancy.
Use components of identical size when creating submirrors. Using components of different sizes leaves wasted space in the mirror.
Adding additional state database replicas before you create a mirror can improve the mirror's performance. As a general rule, add two additional replicas for each mirror you add to the system. Solaris Volume Manager uses these additional replicas to store the dirty region log (DRL), used to provide optimized resynchronization. By providing adequate numbers of replicas to prevent contention or using replicas on the same disks or controllers as the mirror they log, you will improve overall performance.
You can change a mirror's pass number, and its read and write policies.
Mirror options can be changed while the mirror is running.