A file server looks like the simplest box in the rack until you have to build one that stays fast for fifty people, never loses a byte and still has room to grow in three years. Capacity is the easy part; the decisions that actually matter are the storage layer that protects and presents the data, the network that feeds it, and the memory that turns spinning disks into something that feels instant. This is how we spec an SMB and NFS file server for UK customers, built around throughput and resilience rather than the enterprise-array comparison that suits a much larger estate.
Start from usable capacity and growth, not raw disks
A file server is sized backwards from the usable space your users and applications need, with realistic headroom on top. Decide the protected, usable figure first, then work outwards to the raw drive count once you have chosen a redundancy scheme, because parity and mirroring both consume capacity that never reaches the share. A pool planned to sit permanently above eighty per cent full will fragment and slow down, so build in room to breathe and a path to expand before you are forced to.
Growth is where file servers quietly fail. Unstructured data tends to grow faster than anyone forecasts, so the chassis you choose should have spare drive bays, and the storage layer should let you grow the pool by adding drives rather than rebuilding it. Plan the second expansion at the same time as the first build, because the cheapest capacity is the bay you left empty on day one, not the disk shelf you bolt on in a panic later.
ZFS or Storage Spaces: pick the storage brain
The storage layer is the real decision. ZFS, on a Linux or BSD base such as TrueNAS, gives you checksummed end-to-end integrity, snapshots, compression and a mature understanding of how to protect data on commodity drives. It expects a tuned hardware recipe, plenty of ECC memory and an HBA in pass-through mode rather than a hardware RAID card, but in return it is forgiving of failing disks and exact about what it has stored.
Storage Spaces, on Windows Server, is the natural choice when the file server lives inside an Active Directory world and the team is fluent in Windows. It integrates cleanly with SMB, Active Directory permissions and the wider Microsoft estate, and Storage Spaces with ReFS gives you resilient volumes and integrity streams. Either way the rule is the same as for any other server: present disks to the software layer through a plain host bus adapter, not a RAID controller pretending the disks are one volume.
- •ZFS / TrueNAS: checksummed integrity, snapshots, compression, wants ECC RAM and an HBA
- •Windows Storage Spaces + ReFS: best when AD-integrated and the team is Windows-first
- •Either way, use HBA pass-through so the software owns each disk natively
- •Snapshots are not backups: keep a separate, ideally immutable, copy
RAM and caching: why a file server wants memory
Memory is what makes a disk-backed file server feel quick. Both ZFS and Windows use otherwise-free RAM as a read cache, holding the hot working set in memory so the most-requested files never touch a disk. On ZFS this is the ARC, and it is the single biggest lever on perceived performance for a read-heavy share; give it generous, ECC-protected memory and the pool behaves far better than its drive count suggests.
For write-heavy or latency-sensitive workloads a small, fast NVMe tier in front of the capacity disks absorbs bursts and smooths out the spinning-disk penalty. The exact mechanism differs between platforms, but the principle is universal: a little flash and a lot of RAM turn a bulk-capacity HDD pool into something that feels like flash for the files that matter, which is far cheaper than going all-flash for cold archive data.
Network: 10GbE is the floor, 25GbE the headroom
A capacity file server can saturate a 1GbE link with a single large copy, so 10GbE is the practical floor for any shared server in 2026, and 25GbE is the sensible headroom for a busy server feeding many clients or a media workflow. The network, not the disks, is often the real ceiling once you have enough spindles or flash behind the share, and a single bonded pair of fast links is usually the difference between snappy and sluggish under concurrent load.
Build the link redundant and sized to role: a bonded pair of 10 or 25GbE ports for resilience and aggregate throughput, on server-grade adapters with offload, chosen from our network cards range. Match the switch ports and cabling to the same speed, because a fast server behind a slow uplink simply moves the bottleneck one hop away and hides it from the people trying to diagnose it.
Resilience: redundancy is not backup
Drive redundancy keeps the server running through a disk failure; it does nothing about deletion, ransomware or a corrupted file written by an application. Mirrored or parity layouts protect against hardware faults, and on large drives a mirror or double-parity scheme is wise because a single-parity rebuild across multi-terabyte disks is slow and exposed. But redundancy is availability, not a backup, and the two must not be confused.
Pair the file server with a proper backup and, where the data warrants it, an immutable or offsite copy, so a logical disaster cannot take the only copy with it. Snapshots give you fast local recovery from accidental change, but they live on the same pool, so they are the first line, not the last. The boot device should also sit on its own mirrored pair, separate from the data pool, so a boot failure never threatens the data and rebuilds stay trivial.
Putting it together
For most UK file and NAS roles this lands on a 2U dual-socket or value single-socket server with plenty of drive bays, generous ECC memory, an HBA in pass-through, a small flash tier and a bonded pair of 10 or 25GbE links. The form factor follows the bay count: a storage-dense chassis for capacity, a standard 2U where growth is modest. Build and price the exact configuration in our Lenovo configurator, or let us design the whole thing in our server configuration service.