A 2U server with twelve empty bays does not automatically provide twelve bays of useful storage. Backplane type, controller capability, drive interface, RAID policy and the workload itself determine what can be deployed safely. Knowing how to choose server storage starts with the existing platform, then works outward from the applications it must support.
For most business estates, the lowest drive price is not the deciding figure. The relevant cost is usable capacity and performance over the expected service life, including resilience, replacement stock and the operational impact of a failed disk or failed array rebuild.
How to choose server storage by workload
Start with the application profile rather than the server chassis. File archives, backup repositories, virtualisation hosts, databases and boot volumes make very different demands on storage. A large-capacity SATA HDD may be entirely appropriate for a backup target, while it is a poor choice for a busy virtual machine datastore with sustained random I/O.
Establish whether the workload is predominantly sequential or random, read-heavy or write-heavy, and whether latency is visible to users or services. Also identify the working data set. A database may hold several terabytes, but if its active data fits within a smaller SSD tier, an all-flash design is not always necessary.
Before selecting drives, record these requirements:
- Current data volume, expected annual growth and the retention period.
- Required usable capacity after RAID overhead, hot spares and formatting.
- Peak IOPS, throughput and acceptable latency.
- Write intensity and the required SSD endurance rating.
- Recovery objectives, including how quickly a failed drive or array must be restored.
Match media to the job
Enterprise SAS HDDs remain a sensible choice where capacity matters more than latency. They suit backup repositories, archive data, surveillance retention and lower-I/O file services. SAS offers dual-port capability in suitable storage designs and is generally preferred over desktop-class SATA drives for enterprise duty cycles.
Enterprise SATA HDDs can provide lower cost per terabyte for compatible server and storage platforms. They are commonly used for bulk capacity, but confirm the controller, backplane and firmware support before mixing drive types. SATA is not a substitute for SAS where dual-path availability or higher queue-depth performance is required.
SAS SSDs are a practical upgrade route for many HPE Gen9, HPE Gen10, Dell Gen13 and Dell Gen14 servers with 2.5-inch front bays. They provide consistent low latency and fit established SAS backplane and RAID controller configurations. For virtualisation, transactional applications and active file services, they often represent the most straightforward performance improvement available to an existing server.
NVMe SSDs offer substantially higher throughput and lower latency than SAS or SATA SSDs, but their adoption is platform-specific. The server must have NVMe-capable bays or a supported PCIe adapter, with the correct backplane, cabling and processor PCIe lane availability. A standard SAS backplane cannot turn a SAS bay into an NVMe bay simply by fitting an NVMe drive. Check the exact server model, chassis configuration and riser arrangement before purchasing.
Check the server, backplane and controller together
Storage compatibility is a system question, not a drive question. Identify the exact server model and generation, chassis type, drive-bay count and bay format first. An HPE DL380 Gen9, for example, may be supplied in several small-form-factor and large-form-factor configurations, with differing backplanes and storage options. The same applies to Dell PowerEdge platforms across Gen12, Gen13 and Gen14.
Confirm whether the server has 2.5-inch SFF or 3.5-inch LFF bays. SFF chassis generally provide greater spindle or SSD density, while LFF chassis favour lower-cost high-capacity HDD deployments. Adapters can physically fit a 2.5-inch drive into a 3.5-inch carrier, but they do not solve interface, controller or cooling requirements.
Then check the controller. HPE Smart Array controllers and Dell PERC controllers vary by interface generation, cache provision, RAID support and support for mixed media. A controller designed for SAS and SATA RAID may not manage NVMe bays in the same way, while software-defined storage or direct-attached NVMe can use a different architecture entirely.
Controller cache matters for write-heavy arrays. A write-back controller with protected cache can materially improve write performance, provided its cache module and power protection are healthy. Do not specify a cache-dependent RAID design without confirming that the controller battery or capacitor-backed cache is present, supported and within service life.
Firmware also needs consideration. Enterprise servers can be selective about drive firmware, carrier type and controller firmware levels. For a production estate, standardise on known-compatible drive models where possible and retain at least one tested spare for each critical configuration.
RAID selection is a capacity and recovery decision
RAID is often discussed only in terms of fault tolerance, but it also governs usable capacity, write penalty and rebuild exposure. RAID 1 is straightforward for operating system volumes and small critical data sets. It sacrifices half the raw capacity but offers predictable behaviour and uncomplicated recovery.
RAID 10 is usually the stronger choice for latency-sensitive virtualisation, database workloads and write-heavy applications. It requires 50 per cent raw-capacity overhead, yet avoids the parity write penalty associated with RAID 5 and RAID 6. Its rebuild process is also less demanding because data is copied from the surviving mirror rather than reconstructed across all members.
RAID 5 provides a balance of capacity and protection for read-oriented workloads, but it should be treated carefully with large HDDs and write-heavy applications. RAID 6 tolerates two drive failures and is often more appropriate where large-capacity disks create extended rebuild windows. The trade-off is additional capacity loss and parity overhead.
A hot spare can reduce response time after a failure, though it consumes a bay and capacity. For environments with local support and readily available identical replacement drives, keeping a tested shelf spare may be more practical. The correct approach depends on service-level commitments, site access and whether the array is exposed during out-of-hours periods.
RAID is not backup. It protects availability against certain drive failures, not against deletion, corruption, ransomware or a controller fault affecting the array. Keep recovery copies independent of the production server and test restoration rather than relying on a successful backup job report.
Size SSD endurance and performance realistically
SSD specifications should be read beyond capacity and interface. Look at endurance, commonly expressed as drive writes per day or total bytes written, alongside sustained write performance and latency consistency. A read-intensive SSD may suit a largely static virtual desktop image store, but it can wear prematurely in a write-heavy database, log volume or virtualisation host.
Do not assume that more SSDs always solve an I/O problem. The controller, RAID layout, cache policy, network path and hypervisor configuration may be the constraint. Equally, a small number of high-capacity SSDs can create a resilience issue if each drive holds a large share of the array. More smaller drives may provide better aggregate IOPS and shorter rebuild exposure, although they increase bay use and replacement cost.
For mixed workloads, separate storage tiers where the platform and budget allow. Keep operating systems on mirrored SSDs, place latency-sensitive virtual machines or databases on enterprise SSD storage, and use HDD arrays for backup or archive capacity. This prevents backup activity from competing directly with production I/O on the same set of spindles.
Plan for procurement, replacement and lifecycle
A storage design should be supportable after the initial installation. Record drive part numbers, firmware revisions, carrier types, controller model and RAID configuration in the asset record. This makes replacement purchasing faster when a failure occurs and reduces the risk of introducing an incompatible drive into an established array.
Refurbished enterprise hardware can make sensible lifecycle extensions possible, particularly where a business already operates HPE or Dell platforms and needs compatible capacity or performance upgrades without a full server replacement. The priority is traceable specification, compatible carriers where required, appropriate testing and a clear plan for matching spares.
KahnServers supplies refurbished HPE and Dell server hardware, storage drives, controllers and upgrade components for businesses maintaining established enterprise platforms. When ordering, use the server generation and exact controller or backplane details, not only the drive capacity, to narrow the correct options.
The best storage choice is the one that meets the application requirement with known recovery behaviour and parts you can obtain again. Specify the platform first, size the usable array second, then choose the media and RAID level that keep failure, growth and replacement work within acceptable limits.