Protecting Your Virtual Disk with a Hot Spare
When you create a redundant virtual disk using a RAID controller, you have the opportunity to maintain system operations even when a disk fails. To do so, you would assign a hot spare to the virtual disk. When a disk fails, the redundant data is rebuilt onto the hot spare without interrupting system operations.
Understanding Hot Spares
A hot spare is an unused backup physical disk that can be used to rebuild data from a redundant virtual disk. Hot spares remain in standby mode. When a physical disk that is used in a redundant virtual disk fails, the assigned hot spare is activated to replace the failed physical disk without interrupting the system or requiring your intervention. If a virtual disk using the failed physical disk is not redundant, then the data is permanently lost without any method (unless you have a backup) to restore the data.
Hot spare implementation is different for different controllers. See the following sections for more information.
The following sections describe procedures for assigning a hot spare:
Considerations for Hot Spares on PERC 3/SC, 3/DC, 3/QC, 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, CERC ATA100/4ch, PERC 5/E, PERC 5/i, PERC 6/E, PERC 6/I, and CERC 6/I Controllers
On the PERC 3/SC, 3/DC, 3/QC, 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, CERC ATA100/4ch, PERC 5/E, PERC 5/i, PERC 6/E, PERC 6/I, and CERC 6/I controllers, assigning a hot spare is equivalent to assigning a physical disk to replace another physical disk if it fails. If more than one redundant virtual disk resides on the physical disk, then all redundant portions of the physical disk are rebuilt.
![]() ![]() |
NOTE: When rebuilding a physical disk, you need to delete any nonredundant virtual disks (such as RAID 0) that reside on the physical disk before rebuilding the physical disk. |
When creating a virtual disk, the physical disks included in the virtual disk can be different sizes. When assigning a hot spare to a RAID 1 or 5 virtual disk, the hot spare only needs to be the same size (or larger) as the smallest physical disk included in the virtual disk.
This is because when using a PERC 3/SC, 3/DC, 3/QC, 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, CERC ATA100/4ch, PERC 5/E, PERC 5/i, PERC 6/E, PERC 6/I, and CERC 6/I controller, you can assign physical disks of different sizes to a virtual disk. When you have fully consumed a smaller physical disk with a virtual disk, however, any portion of larger physical disks that are not consumed by the virtual disk become unusable. Therefore, there is no data on the unused portion of a larger disk that needs to be rebuilt. A redundant virtual disk will also be either striped or mirrored in equal portions across its member physical disks. The amount of data requiring a rebuild will therefore not be larger than the smallest physical disk.
A RAID 10 or 50 virtual disk may include spans that have physical disks of different sizes. In this case, you should identify the span that has the largest “small” physical disk. The hot spare should be large enough to rebuild this physical disk. For example, if one span has three physical disks that are 60 MB, 60 MB and 40 MB and another span has physical disks that are 60 MB, 60 MB, and 50 MB, then the hot spare must be 50 MB or larger.
A dedicated hot spare can only be assigned to the set of virtual disks that share the same physical disks. A global hot spare is assigned to all redundant virtual disks on the controller. A global hot spare must be the same size (or larger) as the smallest physical disk included in any virtual disk on the controller.
After you have assigned a global hot spare, any new virtual disks created on the controller will not be protected by the hot spare in either of the following circumstances:
•![]() |
The controller is a SCSI controller and the partition size of the disk is larger than the global hot spare. |
•![]() |
The controller is a SAS controller and the disk size is larger than the global hot spare. |
In this case, you can unassign the global hot spare after creating a new virtual disk and then assign a new and larger hot spare to cover all redundant virtual disks on the controller. See "RAID Controller Technology: SCSI, SATA, ATA, and SAS" to determine whether the controller is using SCSI or SAS technology.
On the PERC 3/SC, 3/DC, 3/QC, 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, and CERC ATA100/4ch controllers, the virtual disk state is not updated until the controller performs an I/O operation. This means that when a redundant virtual disk is degraded on one of these controllers, the hot spare will not be activated until the controller performs an I/O operation. See "I/O and Reboot Requirements for Detecting Physical Disk Status Changes" for more information.
Dedicated Hot Spare Considerations
The following considerations apply to dedicated hot spares:
•![]() |
Considerations for RAID 10 and RAID 50. If you have created a RAID 10 or RAID 50 virtual disk that does not fully consume its member physical disks, then you will not be able to assign a dedicated hot spare to the RAID 10 or RAID 50 virtual disk. Storage Management does not allow you to create RAID 10 and RAID 50 virtual disks from partial physical disks. You will therefore not encounter this situation if you are using Storage Management to create your virtual disks. If, however, the RAID 10 or 50 virtual disk was created using another application and if it does contain partial physical disks, then you will not be able to assign a dedicated hot spare to the virtual disk. |
•![]() |
Considerations for Multiple Dedicated Hot Spares. Storage Management does not enable you to assign more than one dedicated hot spare to a virtual disk. On some controllers, you can use the BIOS to assign more than one dedicated hot spare. In this case, Storage Management recognizes the hot spares assigned in the BIOS but does not allow you to assign additional dedicated hot spares. |
Physical Disk State, Alert Messages and Hot Spares on PERC 3/SC, 3/DC, 3/QC, 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, and CERC ATA100/4ch Controllers
If you have a hot spare assigned to a virtual disk and a physical disk in the virtual disk fails, the failed physical disk may change from Online state to Ready state without displaying a Failed state. This occurs when the hot spare is activated before the physical disk is able to report the Failed state. Because the Failed state is not reported, the “Device failed: physical disk” event "2048" is not generated.
When the hot spare is activated it changes to the Rebuilding state. If you review the event log and identify a “rebuilding” event such as "2064" or "2065," you can assume that a physical disk has failed.
Considerations for Hot Spares on PERC 3/Si, 3/Di, and CERC SATA1.5/6ch Controllers
For the PERC 3/Si, 3/Di, and CERC SATA1.5/6ch controllers, a hot spare is assigned to a virtual disk. When a physical disk fails, only the portion of the physical disk containing the virtual disk is rebuilt onto the hot spare. Data or space on the physical disk not included in the virtual disk will not be rebuilt.
On the PERC 3/Si, 3/Di, and CERC SATA1.5/6ch controllers, individual physical disks may be included in more than one virtual disk. (Assigning a portion of a physical disk to a virtual disk does not preclude the remaining portion of the physical disk from being used by other virtual disks.) Only the virtual disks to which the hot spare is assigned will be rebuilt. When using Storage Management, a disk that is assigned as a hot spare on a PERC 3/Si, 3/Di, and CERC SATA1.5/6ch controller cannot also be used as a physical disk.
![]() ![]() |
NOTE: When using the BIOS on a PERC 3/Si, 3/Di, or CERC SATA1.5/6ch controller, it may be possible to create a hot spare from a physical disk that is also used in a virtual disk. To avoid confusion and maximize data protection, Storage Management does not allow a physical disk to be both a hot spare and a member of a virtual disk. When assigning a hot spare, Storage Management displays the physical disks that are not being used by a virtual disk. |
Size Requirements for Global Hot Spares on PERC 3/Si, 3/Di, and CERC SATA1.5/6ch Controllers
When assigning a physical disk as a global hot spare on a PERC 3/Si, 3/Di, and CERC SATA1.5/6ch controller, the physical disk should be as large or larger than the largest physical disk on the controller.
Dedicated Hot Spare Considerations on PERC 3/Si, 3/Di, and CERC SATA1.5/6ch Controllers
You can assign the same dedicated hot spare to more than one virtual disk. In this case, the hot spare attempts to rebuild all portions of redundant virtual disks that reside on a failed physical disk. To increase the likelihood that the hot spare is able to rebuild all virtual disks, you should do the following:
1 ![]() |
Create virtual disks that share the same set of physical disks. |
2 ![]() |
Only assign dedicated hot spares to those virtual disks that share the same set of physical disks. |
3 ![]() |
Assign a hot spare that is big enough to rebuild the largest physical disk in the virtual disk. For example, if the virtual disk is using physical disks that are 20 MB, 30 MB, and 50 MB, then the hot spare needs to be 50 MB or larger. |
After the hot spare is activated to rebuild a particular virtual disk, it is no longer available for rebuilding other virtual disks should an additional physical disk fail. For this reason, when a hot spare is activated it is automatically unassigned from the remaining virtual disks. To maintain data protection, you will need to add a new hot spare and assign it to the other virtual disks.
![]() ![]() |
NOTE: The "Assign and Unassign Dedicated Hot Spare" command is not available on the CERC SATA1.5/2s controller. |
Global Hot Spare Considerations on a SAS 6/iR
The SAS 6/iR controller enables you to assign two global hot spares. The controller firmware remembers the hot spare assignment even after the physical disks that you assigned as hot spares have been removed. In other words, in the case of a disk removal, the firmware may assume that a hot spare is present when it is not. In this case, the firmware may prevent you from assigning a new global hot spare as the firmware assumes that a global hot spare is already assigned.
When a physical disk fails in a redundant virtual disk, the failed disk is rebuilt onto the hot spare. In this case, the controller firmware reassigns the slot containing the failed disk as the hot spare. In this circumstance, a disk not previously assigned as a global hot spare becomes a hot spare through failure or removal.
To ensure that the controller firmware always has a healthy physical disk as a global hot spare, do the following:
•![]() |
When removing a physical disk that is assigned as a global hot spare, unassign the hot spare before removal and reassign another physical disk as the global hot spare. |
•![]() |
Immediately replace any physical disk that has failed or been removed. This ensures that a healthy disk resides in a slot that the controller firmware assumes is a hot spare. |