When replacing slices in a mirror or a RAID5 metadevice, follow these guidelines:
Always replace slices in the "Maintenance" state first, followed by those in the "Last Erred" state.
After a slice is replaced and resynced, use the metastat(1M) command to verify the metadevice's state, then validate the data to make sure it is good. Replacing or enabling a slice in the "Last Erred" state usually means that some data has been lost. Be sure to validate the data on the metadevice after repairing it. For a UFS, run the fsck(1M) command to validate the "metadata" (the structure of the file system) then check the actual user data. (Practically, users will have to examine their files.) A database or other application must have its own way of validating its internal data structure.
Always check for state database replicas and hot spares when replacing slices. Any state database replica shown to be in error should be deleted before replacing the physical disk and added back before enabling the slice. The same applies to hot spares.
RAID5 Metadevices - During slice replacement, data is recovered, either from a hot spare currently in use, or using the RAID level 5 parity, when no hot spare in use.
Mirrors - When you replace a slice, DiskSuite automatically starts a resync of the new slice with the rest of the mirror. When the resync completes, the replaced slice becomes readable and writable. If the failed slice has been replaced with data from a hot spare, the hot spare is placed in the "Available" state and made available for other hot spare replacements.
The new slice must be large enough to replace the old slice.
As a precaution, back up all data before replacing "Last Erred" devices.
A submirror or RAID5 metadevice may be using a hot spare in place of an errored slice. When that errored slice is enabled or replaced using the procedures in this section, the hot spare is marked "available" in the hot spare pool, and is ready for use.