Storage Dedicated Servers

A storage dedicated server is the machine you reach for when the problem is capacity, not compute. Most dedicated servers are sized by cores and memory; a storage server is sized by drives — how many, what kind, how arranged, and how protected. In 2026 the design of these machines has been reshaped by a single fact: the price gap between flash and disk widened dramatically rather than closing as everyone expected, which makes the choice of drive type the most consequential decision in the whole build. This page covers what a storage server is, why the SSD-versus-HDD economics changed, how to tier drives to your data, why drive class matters more than raw capacity, how to lay out RAID and ZFS, and why storage belongs on bare metal rather than in a virtual machine.

What is a storage dedicated server?

A storage dedicated server is a single-tenant machine built around capacity: many drive bays, high raw storage, and a redundancy layout, designed to hold large volumes of data reliably rather than to run compute-heavy work. The sizing language is different from a compute server. Instead of cores and memory first, you start from drives — how many bays the chassis has, what class and capacity of drive fills them, how they are arranged for redundancy and throughput, and how much of the raw capacity survives the redundancy as usable space.

These machines scale from a compact archive box with a few bays up to a dense chassis carrying three dozen or more drives and a petabyte of raw capacity. The CPU and memory still matter — enough processor to drive the I/O, and enough memory for a caching layer or for a filesystem like ZFS that uses RAM aggressively — but they exist to serve the storage rather than the reverse. The workloads that justify a storage server are the data-heavy ones: backup and disaster-recovery repositories, media libraries, object storage, big-data and AI training lakes, file servers, and log or compliance archives. If your need is processing rather than capacity, a compute-focused dedicated server is the better fit; this page is about the machines whose job is to hold data.

Why did SSD and HDD prices diverge in 2026?

For most of the last decade the industry expected flash to keep getting cheaper until it met disk somewhere around 2026 to 2028. Enterprise SSD cost per terabyte fell roughly 80% between 2015 and 2023, while HDD declined more modestly, and the lines looked set to cross. Then the AI build-out broke the trajectory. Training large models created storage demand of a different shape and scale, pulling NVMe and memory into short supply and pushing enterprise SSD prices up sharply through late 2025 and into 2026.

Disk did not escape entirely — HDD prices rose by something like 35 to 46% as hyperscalers consumed nearline capacity for AI training data, with some drive models on backorder — but the increase was far smaller than on flash. The outcome is a wide and, for now, widening gap: enterprise HDD lands around $9 to $15 per terabyte while NVMe sits at roughly $80 to $150, a difference of more than tenfold. For storage design this is decisive. All-flash, which looked like the inevitable future, is uneconomic for bulk data in 2026, and the sensible architecture once again tiers a small amount of fast flash over a large amount of inexpensive disk. Anyone refreshing a storage platform on the old assumption that flash and disk are converging is budgeting from a model the year invalidated.

How do you match drive types to your data?

The principle is to place each dataset on the cheapest storage that meets its access pattern, which sorts most data into a few tiers. The diagram below shows the shape; the text after it explains the moves.

The hottest data — active database pages, real-time analytics, anything latency-sensitive — goes on NVMe and is usually a small share of the total. Warm operational data and active virtual-machine images sit on SAS or SATA SSD. The large majority — historical records, completed logs, prior backups, and media read sequentially when accessed — belongs on nearline HDD, where disk throughput of a couple hundred megabytes a second comfortably exceeds what streaming even high-resolution video requires, and where the cost per terabyte is a fraction of flash. The coldest, multi-year compliance data can drop to deep HDD or tape. The table sums up the choices.

The practical rule that falls out of this is concrete: a 50 TB workload with 5 TB of genuinely hot data should be 5 TB of NVMe plus 45 TB of HDD, not 50 TB of flash. The tiering overhead is minor and the saving is on the order of 80 to 90%.

Drive class matters more than capacity

It is tempting to choose drives by capacity and price per terabyte alone, but in a multi-drive server the class of drive matters more, because class determines how a drive behaves under sustained load and, crucially, when something goes wrong. The first distinction is recording technology. CMR drives handle the random writes and array rebuilds of a RAID or ZFS pool predictably; SMR drives, which pack more capacity by overlapping tracks, can spike latency badly during the reshuffling that scrubs and resilvers trigger, which makes them a poor and sometimes dangerous fit for active arrays. If a high-capacity drive is priced suspiciously low, it is worth confirming it is CMR before trusting an array to it.

Beyond that, enterprise and NAS-class drives are rated for 24/7 multi-bay operation with predictable error behavior, where a desktop drive may not fail faster but can behave worse at the critical moment — spending a long time trying to recover a sector, hanging on a command, and triggering the controller to drop it from the array, turning one drive’s trouble into a degraded pool. SAS drives, common in enterprise designs, run at higher spindle speeds and support multipath for high-availability layouts; SATA is fine for bulk where that is not needed. And QLC flash, while cheap per terabyte, carries unpredictable latency and lower endurance that make it a risky choice for serious server workloads. The summary is simple: in a storage server, start from the right drive class for the role, then optimize capacity within it.

Class is also why commissioning matters as much as the purchase. Burning in new drives before trusting them, keeping temperatures controlled, tuning rebuild and scrub behavior, and monitoring SMART data on a schedule often do more for reliability than a small difference in price per terabyte — because the failures that hurt are the ones a well-run array catches early and absorbs without drama, and the ones that become incidents are usually the ones nobody was watching for.

RAID, ZFS, and NVMe caching

How drives are arranged is as important as which drives they are. For backup and archive pools, double-parity layouts — RAID 6 or RAID 60, or ZFS RAIDZ2 — are the usual choice, because they survive the loss of two drives at once, which matters when a rebuild on large drives takes long enough that a second failure is a real risk. ZFS is the common foundation for serious storage on Linux and its relatives: it adds checksums that catch silent corruption, transparent compression that reclaims capacity, snapshots, and the scrubs and resilvers that keep a pool healthy — with the requirement that ZFS pairs properly with ECC memory, since its integrity guarantees assume the RAM holding the data is itself reliable.

A storage server does not have to choose between cheap capacity and fast access, because caching bridges them. A layer of NVMe in front of an HDD pool — as a read cache for frequently-touched data and a write log for synchronous writes — accelerates the hot path while the bulk stays on inexpensive disk, which is how a mostly-HDD machine can still feel responsive for the data that is actually in use. The worksheet below shows the shape of such a layout.

# storage layout · nvme cache in front of an hdd bulk pool · mcsnet
# example: dense archive node, zfs raidz2 (double parity)
zpool create tank raidz2 /dev/sd[b-m]  # 12x HDD, survives 2 failures
zpool add tank cache /dev/nvme0n1      # nvme read cache for hot data
zpool add tank log /dev/nvme1n1        # nvme write log for sync writes
zfs set compression=lz4 tank           # transparent compression saves space
zfs set atime=off tank                 # less write churn on bulk storage
ecc ram assumed: zfs checksums plus ecc guard against silent bit-rot

One technical note worth knowing: with all-NVMe pools, software RAID through mdraid or ZFS is usually the better choice than a hardware RAID controller, which tends to top out on PCIe bandwidth and becomes a bottleneck once many fast drives are attached. HBA passthrough, which hands the drives directly to the software stack, is the right approach for ZFS.

Why does storage belong on bare metal, not a VM?

A storage stack wants direct, predictable access to physical drives, and a virtualization layer works against that. Storage software relies on talking to the hardware: reading SMART data to catch a failing drive early, calculating parity, and, with ZFS, managing checksums, scrubs, and resilvers that assume real device access. Push that through a virtual machine or a container with device passthrough and you introduce fragility — passthrough can be inconsistent, health monitoring becomes unreliable, and you create initialization dependencies where the storage daemon and the filesystem must start in the right order before anything else can use them.

The common temptation to run storage inside a container to save resources tends to produce a setup that is harder to reason about and quicker to break, with weaker isolation than a real machine. On bare metal the path is clean and ordinary: the machine boots, the drives spin up, the filesystem mounts, and the storage stack has the direct access it was built for. For data you intend to keep, that directness is worth more than the apparent savings of squeezing storage onto a shared host.

RAID is not a backup

This deserves its own heading because it is the misunderstanding that loses data. RAID gives you redundancy — an array survives a dead drive and stays online — but it does nothing about the events that actually destroy most data: accidental deletion, corruption, ransomware, a bad write propagated across the array. In every one of those, RAID faithfully mirrors the damage. A backup is a separate, off-machine copy, and the sound practice is to keep more than one copy in more than one place with at least one off-site, and to prove the backup by occasionally restoring from it, since a backup never tested is a hope rather than a plan.

Redundancy and backup do different jobs and you need both: RAID carries you through a hardware failure, and backups carry you back from everything else. The redundancy also has a capacity cost, since parity and mirroring reduce usable space below the raw total, which is part of sizing a storage server honestly rather than by its headline capacity. Drives also warn before they fail, so SMART monitoring with proactive replacement turns most failures into a planned drive swap rather than an incident.

Common storage workloads, and the network they need

The workloads that justify a storage server share a shape: large volumes, sequential access, and a need to move data in and out. Backup and disaster-recovery repositories handle big sequential writes during backup windows and big reads during restores, both well-served by HDD, where the tenfold cost advantage over flash translates into far more retained history at the same budget. Media libraries store content read sequentially, where disk throughput exceeds streaming needs. Object storage — S3-compatible systems such as MinIO or Ceph — and big-data and AI training lakes follow the same pattern of high capacity and sequential bandwidth. Object storage deserves a specific mention, because it changes how redundancy is done: distributed systems such as Ceph and MinIO often replicate or erasure-code data across many drives or nodes in software, which can make a plain drive-passthrough layout preferable to hardware RAID, with the storage software rather than a controller providing the resilience. The right foundation for that is a chassis full of drives handed directly to the software — another case where bare metal’s direct access earns its place.

Because storage servers move large volumes, the network is part of the spec rather than an afterthought. Uplinks range from 1 Gbit/s up to 100 Gbit/s, often with bonded NICs for throughput, and the transfer policy matters: metered plans bill overage per terabyte, while unmetered suits a repository that constantly ingests and serves data. Under-sizing the network on an otherwise capable storage server is a common way to bottleneck it, since the drives can hold far more than a narrow pipe can move in a reasonable window.

Storage for email infrastructure

Email at scale generates more storage than people expect, and it has the access pattern a storage server is built for. Mail archives and compliance retention — keeping years of sent and received mail for legal or regulatory reasons — are classic cold-to-warm data, large in volume and read rarely, which makes them a natural fit for tiered HDD-backed storage rather than expensive flash. Log retention for a high-volume sending platform is similar: large, sequential, and valuable mostly for the occasional audit or investigation.

We pair sending infrastructure with appropriately tiered storage so that the hot path — active queues and recent logs on fast storage — stays responsive while the bulk of archived mail and historical logs sits on cost-effective capacity. For senders with retention obligations, getting this split right keeps compliance affordable rather than paying flash prices to store mail that is almost never read. It is the same tiering discipline as any storage workload, applied to the specific shape of email data.

Built to order from Toronto

Storage servers are rarely off-the-shelf, because the right build depends on your data: the bay count, the mix of NVMe and HDD, the RAID or ZFS layout, the cache tier, and the uplink all follow from how much data you have and how it is accessed. So this is a built-to-order tier. Our home data center is in Toronto, giving Canadian data residency and a stable North American base, and we run servers in Frankfurt, Strasbourg, Amsterdam, Singapore, Panama City, and Miami, so a storage platform can sit close to where its data is produced or where residency rules require it.

We spec the platform around your workload rather than handing you a fixed plan — drive class and count, redundancy layout, NVMe caching, ECC memory sized for ZFS, and the network to match — and for managed servers we monitor drive health and replace failing drives proactively. You can start a configuration in our configurator and our engineers build out from there, including dense chassis and high-capacity arrays that the standard options do not list.

Why work with us?

We size storage to the data, which mostly means refusing to sell you flash for cold archives. The honest build in 2026 tiers a small amount of NVMe over a large amount of HDD, chooses drive class by role rather than by price per terabyte, lays out redundancy that survives a realistic failure, and treats backups as separate from RAID rather than a synonym for it. We will tell you when a smaller machine fits, and when your data genuinely needs the dense, high-capacity build.

The perspective comes from running storage for our own sending infrastructure — mail archives, logs, and backups — where paying flash prices for cold data or confusing redundancy with backup would be a cost we feel directly. We would rather build the storage server your data actually needs than the one with the most impressive raw capacity on the quote. Storage matched to the data is the service.

Who this is for, and who it is not

A storage dedicated server is for capacity-heavy workloads: backup and disaster-recovery repositories, media libraries, object storage, big-data and AI training lakes, file servers, and log or compliance archives — anywhere you need to hold large volumes of data reliably and economically. If that is your need, a built-to-order storage server with tiered drives, a sound redundancy layout, and separate backups is the right tool, and in 2026 it will lean on HDD for the bulk for good economic reason.

It is not for compute-bound or latency-critical workloads that happen to need some storage; those belong on a compute or business server with fast local NVMe, sized by cores and memory rather than by bays. Read this page as a design conversation: if your problem is capacity, talk to us about tiering and building it economically; if your problem is compute, we will point you to the machine that fits. Storage sized and tiered to the data is the service.