A file server is one of the easiest builds to get wrong, because it looks simple and is not. Buy too few spindles and rebuilds take days; pick the wrong filesystem and you inherit a snapshot and integrity story you did not want; under-size the network and a room full of users wait on a single saturated link. This guide is the build method our engineers use when we configure an SMB or NFS file and NAS server for UK customers, working from usable capacity and concurrent throughput rather than a headline drive count.
Start from usable capacity, not raw
The number that matters is usable terabytes after the parity scheme and a sensible free-space margin, not the raw figure on the invoice. A pool of large drives in double-parity loses two drives to redundancy and should never run past about eighty percent full, or both performance and rebuild safety degrade. Work backwards: take the data you must hold, add realistic annual growth across the life of the box, then size the raw pool so the usable figure clears that target with headroom to spare.
Drive count matters as much as drive size. Fewer very large drives give cheap capacity but slow, risky rebuilds; more moderate drives spread the rebuild load and lift aggregate throughput. For a general-purpose share, a wider set of mid-capacity drives is usually the better engineering choice than a handful of the largest disks on the market.
ZFS or Storage Spaces: pick a deliberate filesystem
The filesystem decision shapes everything that follows. ZFS, on TrueNAS or a Linux distribution, brings end-to-end checksums, copy-on-write snapshots, transparent compression and a mature replication story, at the cost of planning your RAM and pool layout up front. Windows Storage Spaces with ReFS suits shops that want to stay inside the Windows world, integrate with Active Directory natively and lean on familiar tooling.
Neither is universally correct. Choose ZFS when data integrity, snapshots and send/receive replication are priorities and the team is comfortable with the platform. Choose Storage Spaces when the file server is one Windows role among many and operational consistency with the rest of the estate wins. Whichever you pick, match the controller to it: software-defined pools want an HBA in passthrough, not a RAID card hiding the disks. Our host bus adapter guidance covers that distinction.
Memory, cache and the role of NVMe
ZFS uses free RAM as a read cache, so a capacity file server benefits from generous memory; size it to the working set you expect to be hot rather than to a fixed rule of thumb. A modest pool serving documents needs far less than a busy media or project share. Where the workload is read-heavy and latency-sensitive, a small NVMe cache or special metadata device in front of spinning capacity smooths the experience without the cost of going all-flash.
Do not put the operating system on the data pool. Boot from a separate mirrored device so a boot-drive failure never touches the shares and rebuilds stay trivial. This is the same discipline we apply to every server build, file servers included.
Network: where file servers actually bottleneck
A file server is only as fast as the link feeding it. A single 1GbE port caps you at roughly a hundred megabytes a second regardless of how fast the disks are, which is why a well-specified pool can still feel slow. The current mainstream is 10GbE for a workgroup share and 25GbE where many users hit the box at once or large files dominate, with link aggregation across two ports for resilience and headroom.
Match the rest of the path to the NIC. Jumbo frames end-to-end, a switch that can actually sustain the aggregate, and clients capable of more than gigabit are all part of the design. Our network card guidance helps size the port speed to the number of concurrent users rather than guessing.
- •Size usable capacity after parity and an eighty-percent fill ceiling, then add growth
- •Prefer more mid-capacity drives over a few of the largest for rebuild safety and throughput
- •ZFS for integrity, snapshots and replication; Storage Spaces for Windows-native estates
- •10GbE for a workgroup share, 25GbE with aggregation for many concurrent users
- •Boot from a separate mirrored device, never the data pool
Putting it together
When the capacity, filesystem and network calls are made, the chassis is usually a 2U platform with the drive bays to match, configured with an HBA, the right memory and a redundant power and cooling story. You can build an exact specification and request a quote through our Lenovo configurator, or hand us the requirements via our server configuration service and we will size the pool, cache and network for you. For the generic, workload-agnostic version of this method, read how to spec a server in 2026.