Dell PERC Configuration Guide for RAID Setup

A Dell PERC configuration guide is most useful before an operating system is installed, not after a server has entered service with the wrong virtual disk layout. On Dell PowerEdge Gen12, Gen13 and Gen14 platforms, the controller choice, drive interface, RAID level and cache policy all affect recoverability, usable capacity and application performance. Treat the initial configuration as part of the server build specification rather than a quick BIOS task.

Start with the PERC controller and drive topology

Confirm the exact controller model before fitting drives or creating any virtual disks. Dell PERC controllers vary substantially between generations. A PERC H330 is an entry-level RAID controller with limited cache capability, while H730, H730P, H740P and H755 controllers provide hardware cache and are generally better suited to transactional workloads, virtualisation hosts and larger disk groups. Older PowerEdge Gen12 systems may use H310, H710 or H710P controllers; Gen13 commonly uses H330, H730 and H730P; For Gen14, Dell's PowerEdge R740 specifications list H330, H730P and H740P among the supported internal RAID controllers. H755 is listed in the PowerEdge R750 controller specifications; check the exact server's supported-controller list rather than assuming support from the PERC family name.

The controller must also match the intended drive type. SAS and SATA hard drives can often be mixed at the chassis level, but they should not normally be mixed within the same virtual disk. SSD and HDD groups should be kept separate for the same reason. A RAID set only performs as well as its slowest member, and combining different endurance classes or capacities complicates replacement planning.

Check the physical layout before proceeding. Record the backplane type, drive bay numbering, cable routing and any rear-mounted storage. On some PowerEdge servers, front bays connect to one controller while rear flex bays connect to another. A virtual disk cannot span controllers, even if all installed drives appear within the same iDRAC inventory.

Dell PERC configuration guide: choose RAID for the workload

RAID selection should follow the service requirement, not the maximum usable capacity. RAID 1 remains a sensible choice for a pair of boot SSDs or small operating system drives. It is simple to rebuild and gives predictable read performance, but only half of raw capacity is available.

RAID 10 is usually the practical option for virtual machine datastores, databases with sustained writes and other latency-sensitive workloads. It needs at least four drives and sacrifices 50% of raw capacity, yet it avoids the parity penalty associated with RAID 5 and RAID 6. Rebuild exposure is also easier to manage because each failed disk is mirrored rather than reconstructed from parity across the full set.

RAID 5 offers useful capacity efficiency for read-focused file storage, archive tiers and lower-write applications. It tolerates one disk failure but may be a poor fit for large-capacity spinning disks, particularly where rebuild windows are long. RAID 6 provides dual-parity protection and tolerates two drive failures, making it more appropriate for larger HDD arrays where capacity matters but a second failure during rebuild cannot be ignored. Its write penalty is higher, so controller cache and workload behaviour need consideration.

Do not create a single large RAID 5 or RAID 6 array simply because the drives are identical. Separating operating system, application and data volumes can make recovery and performance management more straightforward. Conversely, creating numerous small virtual disks from one disk group does not create independent fault domains. They still depend on the same physical drives and controller.

Before creating a virtual disk

Back up any data on installed drives. Initialisation, foreign configuration clearing and virtual disk creation can destroy existing data. This is especially relevant when fitting refurbished drives or a replacement controller into an existing server. A controller may detect metadata from a previous array and report a foreign configuration.

A foreign configuration should not be cleared automatically. First establish whether the metadata belongs to an array that needs importing. If a controller has failed and been replaced with the same or a compatible PERC model, importing the foreign configuration may restore access to the virtual disk. If the drives are being repurposed and the data is no longer required, clear the foreign configuration only after confirming the disks are not required elsewhere.

Also inspect drive status. Each disk should show as Ready before it is added to a new array. Drives marked Failed, Offline, Foreign or Non-RAID require investigation. If a disk is set to Non-RAID mode, convert it only where the controller and intended configuration support it. Do not force a drive online as a substitute for understanding why it dropped from the array.

Create the virtual disk in Lifecycle Controller or iDRAC

For a local build, enter the Dell Lifecycle Controller during POST with F10 and open Hardware Configuration, then Configuration Wizards and RAID Configuration. The exact menu labels vary by generation and firmware version, but the workflow is consistent: select the controller, choose the physical disks, select the RAID level and define the virtual disk parameters.

iDRAC provides the same essential functions remotely and is generally preferable where the server is deployed in a rack or remote site. Check that iDRAC and PERC firmware are current enough for the installed drive types before making configuration changes. Firmware consistency matters, particularly with enterprise SAS SSDs and larger-capacity disks.

When naming the virtual disk, use a functional identifier rather than a generic default. Labels such as `OS_RAID1`, `VM_DATA_RAID10` or `FILE_ARCHIVE_RAID6` are clearer during later support work. Confirm the selected disks against bay numbers, capacities and serial numbers before applying the job. A configuration job may not take effect until the next reboot, depending on the platform and interface used.

Stripe size, read policy and write policy

For most standard deployments, leave stripe size at the controller default unless the application vendor specifies otherwise. Larger sequential workloads may benefit from a larger stripe, while highly random workloads are often less sensitive than expected once cache and application behaviour are considered. Changing stripe size is not a routine tuning exercise and usually requires recreating the virtual disk.

Read policy choices commonly include Adaptive Read Ahead, Read Ahead and No Read Ahead. Adaptive Read Ahead is a reasonable default for mixed workloads because it reacts to sequential reads without permanently allocating resources to read-ahead activity. A known sequential workload may justify Read Ahead, while random-access workloads may suit No Read Ahead.

Write policy needs more care. Write Back can improve write performance where the controller has a healthy cache protection module, such as a battery-backed cache or non-volatile cache arrangement. Write Through is slower but commits writes more conservatively. Never select Force Write Back merely to improve benchmark results if cache protection is unavailable or reporting a fault. That setting increases the risk of data loss during a power event or controller failure.

Initialise correctly and monitor the rebuild path

After creating a virtual disk, choose the appropriate initialisation method. Fast initialisation prepares the array quickly and is often adequate for new deployments, while background initialisation continues parity preparation after the virtual disk becomes available. Full initialisation writes across the entire set and takes longer, but can be appropriate where the operating procedure requires a complete media pass before production use.

Allow background initialisation to complete where possible. Performance may be reduced while it runs, especially on HDD arrays. Check progress through iDRAC, OpenManage or the controller utility rather than assuming the server is ready because the operating system can see the logical volume.

Set up a realistic spare strategy. A dedicated hot spare is assigned to one disk group; a global hot spare can protect multiple compatible groups. A spare must be at least as large as the drive it may replace, and it should match the interface and performance class. Keeping one unassigned, tested replacement drive on site can be more useful than relying solely on a global spare, particularly for older or discontinued disk formats.

Monitor controller health after deployment. Review predictive failure alerts, cache status, battery or supercapacitor status, physical disk media errors and rebuild activity. A degraded RAID set is not a normal operating condition. Replace the failed component, verify that the rebuild starts, and confirm the virtual disk returns to an Optimal state.

A well-specified PERC configuration gives a refurbished PowerEdge server a clear operating role and an easier maintenance path. Match the controller, disks and RAID policy to the workload, retain documented bay maps and keep compatible replacement parts available before the first failure occurs.