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. For more information.
The following sections describe procedures for assigning a hot spare:
•![]() |
Assign and Unassign Global Hot Spare |
•![]() |
Assign and Unassign Dedicated Hot Spare |
Setting Hot Spare Protection Policy
The Hot Spare Protection Policy is supported only on Serial Attached SCSI (SAS) controllers.
The Hot Spare Protection Policy provides you with a higher protection level for the virtual disks by enabling you to specify the number of dedicated/global hot spares to be assigned to the virtual disks/controller. You can also specify the severity levels for the protection policy. Dell OpenManage Storage Management sends alerts when the hot spare protection policy is violated.
Storage Management does not provide a default policy; however, you can determine the hot spare protection policy best suited for your environment.
Dedicated Hot Spare Protection Policy
Resetting the Hot Spare Protection Policy
Deselect the RAID Layout to reset the dedicated hot spare protection policy.
Global Hot Spare Protection Policy
![]() ![]() |
NOTE: When assigning a global hot spare, consider a physical disk that has higher capacity, which can replace any failed disk in the controller. |
Considerations for Hot Spare Protection Policy
•![]() |
The dedicated hot spare protection policy is not applicable to SCSI, SAS/iR, PERC H200, and CERC SATA 6ch/2s controllers. |
•![]() |
RAID 0 does not support assigning hot spares. Also, the protection policy is not applicable for RAID 0. |
•![]() |
For SAS/iR and PERC H200 family of controllers, you can assign only two global hot spares. |
•![]() |
If the status of the virtual disk is displayed as Degraded or Failed because of the hot spare protection policy violation, you must assign the required number of hot spares (as defined in the protection policies) for the status to be displayed as normal. |
•![]() |
Hot Spare Protection Policy is not applicable to PERC S100 and S300 controllers. |
Considerations for Enclosure Affinity
•![]() |
Enclosure affinity settings for dedicated hot spare are applicable only on PERC 5 and PERC 6 family of controllers. |
•![]() |
Enclosure affinity settings for a global/dedicated hot spare are not automatically set when you upgrade to Dell OpenManage version 6.1. |
Enclosure affinity settings for a global/dedicated hot spare are not automatically set when you import a foreign virtual disk.
Considerations for Hot Spares on PERC 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, PERC 5/E, PERC 5/i, PERC 6/E, PERC 6/I, and CERC 6/I Controllers
On the PERC 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, 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 non-redundant 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 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, 4e/Di, 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 is also either striped or mirrored in equal portions across its member physical disks. The amount of data requiring a rebuild is therefore not 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 is not 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. To determine whether the controller is using SCSI or SAS technology, see RAID Controller Technology: SCSI, SATA, ATA, and SAS.
On the PERC 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, and 4e/Di 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 is not activated until the controller performs an I/O operation. For more information, see I/O and Reboot Requirements for Detecting Physical Disk Status Changes.
Dedicated Hot Spare Considerations
The following considerations apply to dedicated hot spares:
•![]() |
Considerations for RAID 10, RAID 50, and RAID 60—If you have created a RAID 10 or RAID 50 virtual disk that does not fully consume its member physical disks, then you cannot 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 therefore do not encounter this situation if you use 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 cannot assign a dedicated hot spare to the virtual disk. |
![]() ![]() |
NOTE: For H700 and H800 controllers, you can assign a dedicated hot spare to RAID 10, RAID 50, and RAID 60. |
•![]() |
Considerations for Multiple Dedicated Hot Spares—From Storage Management version 3.1 onwards, Storage Management enables you to assign more than one dedicated hot spare to a virtual disk. |
![]() ![]() |
NOTE: This feature is applicable only on PERC 5 and PERC 6 family of controllers. |
Physical Disk State, Alert Messages and Hot Spares on PERC 4/SC, 4/DC, 4e/DC, 4/Di, 4e/Si, and 4e/Di 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, the hot spare displays 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.
For information on Alert Messages, see the Dell OpenManage Server Administrator Messages Reference Guide at support.dell.com/manuals.
Considerations for Hot Spares on CERC SATA1.5/6ch, S100, and S300 Controllers
For the CERC SATA1.5/6ch, S100, and S300 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 are not rebuilt.
On the CERC SATA1.5/6ch, S100, and S300 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 are rebuilt. When using Storage Management, a disk that is assigned as a hot spare on a CERC SATA1.5/6ch, S100, and S300 controller cannot be used as a member of a virtual disk.
![]() ![]() |
NOTE: When using the BIOS on a 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 CERC SATA1.5/6ch, S100, and S300 Controllers
When assigning a physical disk as a global hot spare on a CERC SATA1.5/6ch, S100, and S300 controllers, the physical disk should be as large or larger than the largest physical disk on the controller.
Dedicated Hot Spare Considerations on 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 must 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. |