Build your own server: from a parts list to a reliably operable system

When a self-build fits the operation

A server assembled from individually chosen parts can make sense for clearly bounded requirements. You choose the case, storage and expansion to suit the use and avoid unnecessary components. In return, you take responsibility for matching the parts and for faults between motherboard, firmware and memory that cannot clearly be assigned to one component.

For an application with a tight recovery window, a binding replacement service may matter more than the parts-list price. A fully validated system can also simplify finding compatible spares. A self-build is therefore particularly plausible when the team can maintain the hardware, outage consequences are limited and a tested replacement route exists. A cheap shopping basket alone is not sufficient justification.

A requirements profile instead of a universal shopping list

Our hypothetical business needs a file service, a small internal application and a few virtual machines. The first year holds 1.5 TB of production data, with planned growth of 300 GB per year. The service may restart during an agreed maintenance window. A separate recovery target is agreed for a hardware failure. These assumptions are not minimum requirements for any particular software.

An initial 1.5 TB plus four annual increments of 0.3 TB gives 2.7 TB by the end of year five. For a self-selected maximum utilisation target of 75 per cent, at least 2.7 / 0.75 = 3.6 TB of usable capacity would be required. A mirror of two nominal 4 TB drives provides about 4 TB before filesystem overhead, not 8 TB. Snapshots, metadata and temporary working data must also fit within the budget.

Choose CPU and motherboard for the whole system

Many cores help only if the application can work in parallel. A compute-intensive single task may benefit more from one core's performance. Also check whether software is licensed by core count or another metric and which platforms its vendor approves. A cheaper processor can lose its appeal through follow-on costs or missing compatibility.

The motherboard determines memory expansion, PCIe slots, networking and remote management. Count the expansions actually needed beforehand. An extra network card and several fast SSDs may compete for connectors or available PCIe connectivity. The specific board's block diagram or manual is decisive. A long connector list on a product page does not always reveal which combinations can be used simultaneously.

Remote management can save a site visit, but it needs its own access and update plan. It should be reachable only through the protected management environment intended for it. Keep access, cover arrangements and recovery securely documented. A system nobody can operate without a display after a restart is unnecessarily difficult to manage during an incident.

Confirm ECC and module population before buying

An appropriately labelled memory module is not enough for ECC. Intel lists processor and chipset support as prerequisites. Check approval for the specific platform and the motherboard's memory list; DIMM type and population must match. After installation, check whether capacity and error correction are actually recognised. Intel: check ECC support ↗

Plan memory channels and later expansion together. An initial configuration that requires every module to be replaced for the next step may cost more over its lifetime. Conversely, keeping slots free must not compromise required bandwidth without investigation. Support the decision with the manual and the application's load profile.

Assess SSDs by write load and everyday behaviour

A maximum sequential transfer rate does not tell you how quickly an SSD responds to many small writes or after sustained load. For databases and virtual machines, response times under mixed load, write endurance and behaviour during power loss matter. Kingston lists these properties separately for its data-centre SSDs. Check the specifications for the exact model and capacity. Kingston: properties of data-centre SSDs ↗

As our own planning calculation: 300 GB of logical writes per day gives around 547.5 TB over five years of 365 days each. This is a starting point for checking the drive specification, not a lifetime prediction. Internal write amplification, workload type and warranty conditions must also be considered. A high TBW rating promises neither protection from every fault nor a particular recovery time.

Mirroring keeps identical data on multiple drives and can help maintain operation when a single drive fails. However, it also preserves an accidental deletion on both sides. An independent backup with a tested restore remains necessary. Boot media, production data and backups should also be more than different folders on the same physical drive.

Plan software, cooling and location together

Choose the operating platform before ordering. A storage operating system may have different requirements for boot media and controllers than a virtualisation host. The TrueNAS hardware guide, for example, sets out separate requirements and recommendations for memory, boot devices and drive connectivity. Such documentation is a checklist for the selected platform; its minimum figures do not replace your own load planning. TrueNAS: Hardware Guide ↗

The enclosure needs a clear airflow path, space for drives and maintenance access. Check temperatures under sustained simultaneous CPU and memory load and in the actual room. A device that is unremarkable in winter can develop problems in a warm, unventilated cabinet. Rack equipment is not automatically suitable for a workspace either: assess noise and heat before production use.

Size the power supply and UPS around the intended configuration and measured load. A UPS should bridge a defined period or allow a controlled shutdown. It does not turn one site into two. Plan the sequence from power failure through the later restart and test it in a safe maintenance window; electrical installations belong in qualified hands.

Before production data: documented acceptance

1. Create an inventory: record components, serial numbers, firmware versions, warranties and suppliers.
2. Check compatibility: inspect recognised capacity, memory population and all required drives and interfaces.
3. Test hardware: run memory diagnostics and a longer representative load while checking temperatures and error messages.
4. Check the application: test concurrent users, imports, reports and backups against agreed response times.
5. Accept restart behaviour: check services, dependencies and monitoring after a planned restart.
6. Practise recovery: build a separate test environment from a backup and have the application approved by its business users.
7. Hand over operations: confirm responsible people, the spare-parts route, alert contacts and maintenance windows in writing.

Successful acceptance contains results and deviations, not just ticks. If the backup takes longer than planned, resolve whether network, drives or retention need adjustment before launch. If a hardware fault remains unexplained, production use does not begin yet. This protects the future team from a machine whose known weakness was passed on only verbally.

Include the second build in the first plan

Record how the application can be deployed again on different hardware. Installation media, configurations, required access and backups must be available independently of the failed device. A replacement motherboard with the identical model number is not always available quickly. Recovery should therefore depend as little as possible on that one component.

Plan regular reviews of capacity, support lifetime and repairability. A self-built server can remain useful for a long time if its limits are known. If the application becomes more business-critical or internal hardware expertise disappears, a managed system becomes a new, objectively justified option. The architecture must fit today's operation and allow a later change.