I'm planning a compact, energy-efficient server for a 20-person office. It would run Proxmox with three Ubuntu virtual machines: Samba-based directory services, management and security tools, and several low-to-medium workload services such as Jitsi Meet for occasional meetings. It would also support a simple CRUD application, databases used by desktop software, and private file storage.
My tentative hardware is an ASRock Rack motherboard with IPMI, a Ryzen 9 5900X, and 64 GB of memory. The board supports both ECC and non-ECC unbuffered RAM, but ECC would increase the cost. The system would run 24/7, although its heavier workload would generally be limited to around 10 hours per day.
How significant is the risk of silent corruption, crashes, or other problems when using non-ECC memory in this situation? Would frequent backups make non-ECC acceptable, or could a memory error also corrupt the backups before the problem is noticed? I'm mainly asking about the practical reliability difference between ECC and non-ECC memory, not about changing the overall server architecture.
5 Answers
Non-ECC is reasonable for a lab or a low-consequence home system, especially with good backups. For this use case, though, the server is effectively a small production system: shared files, databases, authentication, and services for employees. Since the proposed CPU and board can use unbuffered ECC, the modest extra cost is probably worth it. Also verify that the exact motherboard firmware supports the particular ECC modules you buy; not every board handles every memory type the same way.
For a production server that several people depend on every day, I would choose ECC if the platform supports it. ECC does not make the machine immune to failures, but it can correct single-bit errors and report more serious memory problems instead of allowing them to silently reach the operating system. You’ll still need tested backups, storage monitoring, a UPS, and preferably drives with power-loss protection.
The amount of memory matters somewhat, since more installed RAM and more operating time create more opportunities for an error, but there isn’t a reliable percentage you can calculate for this specific build. A system might run indefinitely without a noticeable fault, or one transient error could hit something important tomorrow. I wouldn’t treat a guessed failure probability as a safety guarantee.
ZFS and virtualization can still run on non-ECC memory, but neither one can protect data from corruption that occurs before it reaches the storage layer. Filesystem checksums may detect some damage later, but they cannot necessarily reconstruct the correct data without a valid redundant copy. Use ECC if practical, and combine it with versioned, offline or off-site backups that are regularly restored and verified.
Non-ECC memory can work for years without an obvious problem, but the main risk is silent corruption rather than a dramatic crash. A flipped bit could affect a file, database record, virtual machine, or filesystem metadata, and you might not notice until the damaged data has already been copied into a backup. Backups are still essential, but they don’t replace error detection and correction.
The chance of an error in any particular day may be small, but this is business data running continuously. ECC is relatively inexpensive insurance when compared with the cost of tracking down unexplained corruption or losing work.
There’s no universal rule that every non-ECC system will fail, and many have run for years without an incident. The point is that ECC gives you detection and correction, which is valuable when the server supports shared business data.