The R710 years: what a secondhand 2U server taught me

My homelab started, as many do, with a Dell PowerEdge R710 bought secondhand for less than a nice monitor costs.

It was a genuinely great decision, and I would not make it again.

Both of those are true, and the gap between them is most of what I actually learned. Here’s the version I’d give someone standing where I was.

How it ended

A power surge took out the drives.

To be fair to the surge, it had help. I was running a mix of secondhand drives in RAID 0 — striped, no parity, no redundancy of any kind. One drive dies and the array is gone, and I’d stacked the odds by using disks with unknown hours already on them.

I knew that. It was a deliberate trade: I wanted the capacity and the throughput, the drives were nearly free, and I accepted that the array was disposable. That part of the reasoning was fine.

The part that wasn’t fine is that “this array is disposable” was a thing I believed rather than a thing I had acted on. There was no backup of the data I’d have actually missed. A known risk you haven’t mitigated is just a risk you’ve rehearsed an excuse for.

Three decisions — used drives, no redundancy, no surge protection — each of which I’d have defended on its own, compounding into one event that ended the machine. That is how infrastructure usually fails: not one catastrophic mistake, but several choices that share a failure mode.

The part I own is that I made all three, and never once sat down and looked at them together.

It was the right way to start

The case for old enterprise hardware is that it teaches you concepts you cannot learn from a Raspberry Pi, because consumer gear simply doesn’t have them.

Out-of-band management. The R710 has iDRAC — a dedicated management processor with its own network port, running whether or not the machine is powered on. Remote console, remote power cycling, hardware health independent of the OS. The first time you fix a host that won’t boot, from a laptop, in another room, you understand why every serious server has this. Nothing in the consumer world does.

Real storage controllers. A PERC RAID controller with a battery-backed write cache is a different object from the SATA ports on a desktop board. Learning the difference between write-back and write-through, what happens when the cache battery dies, and why a controller in RAID mode makes drives illegible to anything else — that’s knowledge that transfers directly to production systems.

ECC memory and redundant PSUs. Two power supplies on separate circuits, either of which can run the box. Memory that corrects single-bit errors instead of silently corrupting your data. These are the physical expressions of ideas I’d only read about.

Hypervisor-level isolation. I ran vSphere on it, and proper VMs are still a meaningfully stronger boundary than containers. Separate kernels, real resource limits, snapshots you can roll back. I miss it, and containers are not a straight replacement — that’s a whole post of its own, and I’ll write it eventually.

For a few hundred dollars, I got a machine that behaves like the machines I’d work on professionally. That was worth it.

Lesson 1: the purchase price is the cheap part

The R710 pulled somewhere around 200 watts at idle. Not under load — idle, sitting there doing nothing, 24 hours a day.

200 W × 8,760 h/yr ÷ 1,000 = 1,752 kWh/yr

At Pennsylvania residential rates, call it $250–300 a year, every year. The server cost less than one year of running it.

The M4 Mac Mini that replaced it idles in the single-digit watts and peaks well below what the R710 drew doing nothing. Same arithmetic puts it around 130 kWh/yr — roughly a tenth.

Substitute your own rate and your own idle draw, but do the multiplication before you buy. It’s the number that decides whether a homelab is a hobby or a subscription.

Lesson 2: twenty-four slow threads are not twelve fast ones

The spec sheet was seductive. Two sockets, twelve cores, twenty-four threads, and more DDR3 than any laptop I’d owned.

The reality is that those are 2010-era Westmere cores. Per-core performance is roughly a third of a modern core, the memory is slow, and most of what I actually ran was single-threaded or latency-sensitive rather than embarrassingly parallel. A compile, a database query, a web request — all of it felt sluggish in a way the core count said it shouldn’t.

“Lots of cores and lots of RAM” is the right shape for some workloads. It is not the right shape for a homelab running a dozen small services, where you mostly want one thing to be fast right now. I optimized for a benchmark I wasn’t running.

Lesson 3: don’t put compute and storage in one box

This is the big one, and the one I’d most want to go back and tell myself.

The R710 was everything: hypervisor, VMs, and all the bulk storage, in one chassis. It’s efficient in the sense that there’s one machine to buy and power. It is catastrophic in the sense that every reason to take the box down is also a reason to lose access to your data.

Upgrading the hypervisor meant no storage. A failed PSU meant no storage. Wanting to reboot after a kernel update meant negotiating with myself about whether I needed those files in the next twenty minutes. And when the machine eventually died, it didn’t take down “my compute” — it took down everything at once, because everything was the same box and the same array.

The split I run now is deliberate: a Mac Mini for compute, a Synology NAS for storage, connected over the network. I can reinstall the compute host on a whim. The data doesn’t care. Two failure domains instead of one, and the one holding the irreplaceable stuff is the one I almost never touch.

The general principle is older than homelabs: separate the stateless thing from the stateful thing. It’s the same instinct that says don’t run your database on your web server. I knew that professionally and hadn’t connected it to the machine in my own basement.

Lesson 4: you need a UPS, and it needs to talk to the host

The term I kept failing to remember is uninterruptible power supply — a rack-mount UPS, sized for your load.

Two things I got wrong here. First, I didn’t have one for far too long, which means every brownout was an unclean shutdown of a machine with a write cache and spinning disks. That is a slow way to corrupt a filesystem.

Second — and this is the part people miss — a UPS without signaling is just a delay. If the battery can’t tell the host “power is out, you have four minutes,” all it does is postpone the same hard shutdown. You want USB or network monitoring, with the host configured to shut down gracefully at a battery threshold. The battery buys time; the signaling is what spends it usefully.

Third, and this is the one that actually got me: a surge is not an outage. I’d been thinking about UPSes purely as protection against the power going away. The event that killed my array was power arriving too enthusiastically. Any decent UPS includes surge suppression, and a line-interactive model adds automatic voltage regulation to smooth sags and swells without touching the battery. If I’d had one for its least interesting feature, the story ends differently.

There’s also a sizing trap that ties back to Lesson 1: battery runtime is a function of load. A 200W server needs several times the UPS that a 15W machine does for the same minutes of runtime. Power-hungry hardware costs you twice — once in electricity, again in the battery you need to ride it out.

Lesson 5: hardware ages out of software support

The R710’s CPUs eventually fell off VMware’s compatibility list. The hardware still worked perfectly; the software I wanted to run on it simply stopped supporting that generation of processor.

This is the quiet expiration date on all secondhand enterprise gear. It doesn’t fail — it just stops being able to run current software, and you’re left choosing between an unpatched hypervisor and a hardware replacement. Budget for it when you buy something a decade old.

Lesson 6: noise, heat, and where it lives

2U of enterprise hardware is loud in a way that spec sheets don’t communicate. The fans are sized for a datacenter with ambient noise and cold aisles, not a room where someone sleeps. It also dumps its 200 watts into your house as heat, which is charming in February and considerably less so in July.

I don’t think this is a reason to avoid the gear. It’s a reason to think honestly about where it will physically sit, before it arrives.

Where I landed

The Mac Mini is better at nearly everything I actually do: faster per-core, silent, an order of magnitude less power, and small enough to be unobtrusive. Paired with a NAS, it fixed the failure domain problem at the same time.

What I lost is the vSphere-grade isolation, and I do feel it. Containers share a kernel, and for some of what I run I’d rather have a real VM boundary.

So the rack isn’t done. The plan is small Linux boxes — NUCs or similar — to bring back genuine machine-level separation without going back to a 200-watt space heater. Several cheap efficient nodes rather than one expensive hungry one, which is roughly the same conclusion the rest of the industry reached about twenty years ago.

I don’t regret the R710. It taught me out-of-band management, storage controllers, hypervisors, and failure domains, and it charged me about $300 a year in tuition. That’s a reasonable price for an education. It’s an unreasonable price for a file server.