HPE RAID Configuration Guide: Choosing the Right RAID Level for Your Server

Planning server storage is not only about choosing how many terabytes you need. The RAID configuration also affects storage performance, usable capacity and protection against drive failures.

The right RAID level depends on the workload, number and type of drives, performance requirements and how much drive-failure protection the business needs.

HPE ProLiant servers can use HPE storage controllers to manage RAID configurations. Before finalising a server, it is important to check the exact controller because supported RAID levels and features vary between controllers.

This guide explains RAID 0, RAID 1, RAID 5, RAID 6 and RAID 10 and where each may make sense.

What Is RAID and Why Does It Matter?

RAID (Redundant Array of Independent Disks) combines physical drives into one or more logical storage arrays.

Depending on the RAID level, data may be striped across drives, mirrored or protected using parity.

The RAID level mainly affects three things:

• Redundancy – what happens when a drive fails?
• Performance – how quickly can data be read or written?
• Usable capacity – how much of the installed raw storage can actually be used?

There is always a trade-off.

More redundancy usually means giving up some usable capacity. Some RAID levels also introduce additional write overhead because parity has to be calculated.

This is why RAID should be selected according to the workload rather than simply choosing the highest RAID number available.

If you are planning the complete server rather than storage alone, see our HPE Server Sizing Guide for CPU, RAM, storage, networking and server-selection guidance.

RAID Levels at a Glance

RAID Level	Minimum Drives	Drive-Failure Protection	Usable Capacity*	Typical Consideration
RAID 0	1	None	100%	Performance or temporary/non-critical data
RAID 1	2	1 drive in a two-drive mirror	Around 50%	Small servers, OS volumes
RAID 5	3	1 drive	Total capacity minus one drive	Capacity efficiency with redundancy
RAID 6	4	2 drives	Total capacity minus two drives	Larger capacity-focused arrays
RAID 10	Usually 4	Depends on which mirrored drives fail	Around 50%	Performance-sensitive workloads

*Simplified examples assume drives of equal capacity and do not include hot spares or other overhead.

HPE’s current Smart Array documentation confirms these minimum drive requirements, although supported RAID levels vary by controller.

RAID 0: Performance Without Redundancy

RAID 0 stripes data across the drives in the array.

This can provide strong performance and makes efficient use of the installed raw capacity.

The problem is that RAID 0 provides no fault tolerance.

If a drive fails, data in the array can be lost or become unavailable.

For this reason, RAID 0 is generally not suitable for important production data unless the data is temporary, disposable or can easily be restored from another source.

RAID 1: Simple Mirroring

RAID 1 stores matching copies of data across mirrored drives.

In a basic two-drive RAID 1 configuration, if one drive fails, the other can continue providing access to the data.

The trade-off is capacity.

Two 2TB drives in RAID 1, for example, provide roughly 2TB of usable capacity, rather than 4TB.

RAID 1 can be a practical choice for:

• smaller servers;
• operating-system volumes;
• simple business applications; and
• environments where straightforward redundancy matters more than maximum capacity.

RAID 5: Capacity and Redundancy

RAID 5 combines striping with distributed parity.

It requires at least three drives and can tolerate the failure of one drive.

Compared with mirroring, RAID 5 can provide better usable-capacity efficiency as the number of drives increases.

However, parity creates additional write overhead, and rebuild behaviour should be considered carefully, particularly with large-capacity drives and busy arrays.

RAID 5 can make sense where:

• capacity efficiency is important;
• one-drive fault tolerance is acceptable; and
• the workload does not have very demanding write-performance requirements.

It may be suitable for some general business applications and capacity-focused storage, but it should not automatically be selected for every server.

RAID 6: More Fault Tolerance

RAID 6 is similar to RAID 5 but uses additional parity.

It requires at least four drives and can tolerate two drive failures.

This additional protection comes with a trade-off in usable capacity and write performance.

RAID 6 can be useful for:

• larger drive arrays;
• capacity-focused file storage;
• backup repositories;
• archive storage; and
• environments where protection against a second drive failure during a rebuild is important.

Whether RAID 6 is appropriate still depends on the drive technology, array size, workload and controller.

RAID 10: Performance and Redundancy

RAID 10 combines mirroring and striping.

Data is mirrored for redundancy and striped across the mirrored sets for performance.

A typical RAID 10 configuration requires at least four drives and provides around half of the raw storage capacity as usable space.

For example:

4 × 2TB drives = approximately 4TB usable before formatting and other overhead

RAID 10 can be a strong choice for workloads with frequent read/write activity because it avoids the parity calculations used by RAID 5 and RAID 6.

It is commonly considered for:

• virtualisation;
• databases;
• transactional applications; and
• other performance-sensitive workloads.

The main disadvantage is cost per usable terabyte because around half of the raw capacity is used for mirroring.

Which RAID Level Should You Choose?

There is no single best RAID level.

A useful starting point is:

Workload / Requirement	RAID to Consider	Why
OS / small server	RAID 1	Simple redundancy
Virtualisation	RAID 10, or RAID 5/6 depending on workload	Performance vs capacity trade-off
Database / SQL	RAID 10 often worth considering	Strong read/write performance without parity overhead
General business applications	RAID 1, 5 or 10	Depends on size and performance
File storage	RAID 5 or RAID 6	Capacity efficiency can be important
Backup / archive	RAID 6 may be useful	Capacity plus two-drive fault tolerance
Temporary/non-critical data	RAID 0 in limited cases	Performance without redundancy

These are starting points, not fixed rules.

An NVMe-based RAID 5 array, for example, behaves very differently from a RAID 5 array built from large HDDs. The controller, drive count and workload also matter.

RAID for Virtualisation

Virtualisation can create significant random I/O because several virtual machines may access storage at the same time.

RAID 10 is often considered when storage performance and predictable write behaviour are important.

However, RAID 5 or RAID 6 may still make sense when usable capacity is more important and the storage system can comfortably handle the workload.

Before choosing, consider:

• number of VMs;
• IOPS requirements;
• read/write pattern;
• drive type;
• RAID controller;
• usable capacity; and
• expected growth.

RAID for Databases and SQL

Database workloads can be sensitive to storage latency and write performance.

RAID 10 is commonly considered for performance-focused database storage because it provides redundancy without parity-write overhead.

But the database design matters too.

A small business database on SSDs may have very different requirements from a high-transaction SQL environment. Application recommendations and measured storage requirements should therefore guide the final design.

RAID for File Storage, Backup and Archive

File storage, backup and archive workloads often place greater importance on usable capacity.

RAID 5 or RAID 6 may therefore be considered.

RAID 6 becomes particularly useful where two-drive fault tolerance is important, especially in larger arrays.

However, RAID should still be combined with a proper backup strategy.

RAID protects availability against certain drive failures. It does not protect the business from every form of data loss.

HPE Smart Array Controllers and RAID Support

HPE storage controllers provide hardware-based storage and RAID management on supported HPE ProLiant servers.

The controller can manage the physical drives and present configured logical storage to the operating system.

But not every HPE controller has the same capabilities.

Before ordering a server, check:

• supported RAID levels;
• SAS/SATA/NVMe support;
• controller cache;
• cache protection;
• supported drive count;
• drive compatibility; and
• required performance.

This is particularly important when configuring larger HPE ProLiant servers for virtualisation, databases or storage-heavy workloads.

The RAID controller should be selected as part of the server configuration rather than treated as an afterthought.

Drive Type Matters Too: HDD, SSD or NVMe

RAID level is only one part of storage performance.

HDD

HDDs provide large capacities at a relatively low cost per terabyte.

They can make sense for:

• file storage;
• backup;
• archive; and
• other capacity-focused workloads.

SSD

SSDs provide much lower latency and higher IOPS than traditional hard drives.

They are commonly used for:

• applications;
• virtual machines;
• databases; and
• active business data.

NVMe

NVMe storage can provide even lower latency and higher performance on supported HPE server configurations.

It can be useful for demanding databases, virtualisation and high-I/O applications.

Before selecting the RAID configuration, make sure the server, drive backplane and controller support the required drive technology.

Should You Use a Hot Spare?

A hot spare is an additional drive reserved to take over when a drive in a supported RAID array fails.

This can allow the rebuild process to begin without waiting for someone to physically replace the failed drive.

Hot spares can therefore be useful for:

• remote servers;
• data-centre systems;
• larger arrays; and
• business-critical environments.

However, a hot spare consumes a drive bay and capacity that would otherwise be available to the system.

Whether it is worthwhile depends on the server’s availability requirements and how quickly failed drives can normally be replaced.

Common RAID Configuration Mistakes

A few mistakes are worth avoiding.

Using RAID 0 for Important Production Data

RAID 0 has no fault tolerance. One failed drive can affect the whole array.

Choosing RAID Based Only on Usable Capacity

Storage performance, fault tolerance and rebuild behaviour matter too.

Ignoring Large-Drive Rebuilds

Large arrays can take significant time to rebuild depending on drive type, capacity, workload and controller behaviour.

This should be considered when choosing between RAID 5, RAID 6 and RAID 10.

Forgetting the RAID Controller

The controller affects which RAID levels and storage features are actually available.

Not Checking Drive Bays

Decide how many drives the RAID configuration requires and make sure the selected HPE server chassis has enough compatible bays, including room for future expansion where needed.

Treating RAID as a Backup

This is one of the most important mistakes.

RAID can help with drive failure, but it does not protect against:

• accidental deletion;
• ransomware;
• data corruption;
• application problems;
• theft;
• fire or disaster; or
• multiple failures beyond what the RAID level can tolerate.

A separate backup strategy is still required.

Conclusion

Choosing the right HPE RAID configuration means balancing performance, fault tolerance and usable capacity.

RAID 0 provides performance and capacity but no redundancy. RAID 1 provides simple mirroring. RAID 5 improves capacity efficiency while protecting against one drive failure. RAID 6 adds protection against two drive failures, while RAID 10 combines mirroring and striping for strong performance and redundancy.

Before choosing, consider:

Workload → Drive Type → Drive Count → RAID Level → Controller → Usable Capacity → Backup

The RAID level should fit the application rather than simply being the highest option available.

Businesses configuring an HPE ProLiant server can also use our HPE Server Sizing Guide to plan CPU, memory, storage, networking and future expansion before finalising the complete server configuration.

Frequently Asked Questions