I'm putting together a compact, energy-efficient server for a 20-person office. It would run Proxmox with three Ubuntu virtual machines: Samba-based directory and file services, management and security tools, and several light-to-medium workloads such as a database-backed business system and occasional Jitsi meetings for around 30 participants. The server would run continuously, although its workload would be fairly light for most of the day.
To keep the budget and power usage down, I'm considering 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. How risky would it be to use ordinary non-ECC memory in this situation? Is an undetected bit flip likely to cause crashes or silently corrupt files, databases, virtual machines, or backups? Would frequent backups make non-ECC memory reasonably safe, or could corrupted data already be copied into those backups?
I'm specifically asking about the reliability impact of non-ECC RAM, not whether the overall server architecture should be changed.
5 Answers
For a production office server, I’d choose ECC if the platform supports it. The important benefit is detection as much as correction: the system can report failing memory and, depending on the hardware, correct certain single-bit errors before they affect applications. Without ECC, intermittent errors can look like random application bugs, filesystem problems, or unexplained VM crashes.
You don’t necessarily need an expensive enterprise tower. Just verify that the exact Ryzen, motherboard, and DIMM combination supports unbuffered ECC correctly, and make sure the firmware exposes memory-error reporting. Ryzen systems generally require unbuffered ECC rather than registered memory.
Non-ECC memory can work, but it provides no way to detect or correct many memory errors. A flipped bit might cause an obvious crash, but it could also alter data silently while it is being processed or written. In the worst case, that bad data gets copied into multiple backups before anyone notices.
There isn’t a useful percentage for the risk in one particular office. Memory errors depend on the DIMMs, motherboard, environment, workload, and luck. They may be rare for years, but the consequences are difficult to diagnose when they do happen. Since this is a business system holding shared files and databases, ECC is a relatively inexpensive form of risk reduction.
There are people who have run non-ECC servers for many years without seeing a problem, so using it does not guarantee disaster. For a lightly loaded small office, the absolute probability may be low. But the question is whether avoiding ECC saves enough money to justify accepting silent corruption on a system that several employees depend on every day.
Use ECC alongside a UPS, reliable storage, snapshots or versioned backups, and regular restore tests. ECC is not magic—disks, firmware, software, and power can still fail—but it removes one avoidable failure mode.
If the cost difference is only a modest amount, ECC is an easy decision. If the system is truly disposable and can be rebuilt from verified backups, non-ECC is more defensible, but that doesn’t sound like this use case.
The exact crash probability can’t be estimated from RAM capacity alone. More memory and longer uptime provide more opportunities for an error, but real-world error rates vary widely. If the server supports ECC at a reasonable price, I would use it; if not, non-ECC may run perfectly well, but treat it as a conscious reliability trade-off rather than assuming backups eliminate the risk.
If you use ZFS or another system that relies heavily on memory for caching and checksumming, remember that it cannot protect data before the checksum is calculated. A memory error can potentially cause bad data and a matching bad checksum to be written. ZFS is not a substitute for ECC, although it can detect some corruption that occurs later on storage.
Likewise, backups only help if they are independent, retain older versions, and are routinely verified. A single backup job running on the same machine can preserve corruption just as efficiently as it preserves good data.
Good backups are still essential, even with ECC. ECC reduces the chance that a memory error reaches the operating system or storage, but it cannot replace versioned, tested, and preferably off-site backups.