Live data from Hacker News

The death and rebirth of my home server

sgt.hootr.club

51–60 of 116 posts

Re: The death and rebirth of my home server

#52
post #2

Raspberry Pis are notorious for SD card corruption with unknown causes. In this era you might replace it with a mini-PC (NUC style).

"Raspberry Pis are notorious for SD card corruption with unknown causes."

This is not specific to RPis. When an SD card is subjected to "unpredictable" writes it creates potential risk of corruption. The writes are triggered by software, not the RPi hardware

There is no rule that says the RPi user must mount the root filesystem r/w on the card. It can be mounted r/w on mfs or tmpfs, for example, and the card can be removed after boot. Been doing this since 2012

Zero writes to the card, no corruption

It's true these corruption issues are "notorious" but that's due to RPi owner behaviour, not the RPI hardware

Re: The death and rebirth of my home server

#53
post #7

I'm not a sysadmin but I often hear about server failures due to hardware just wearing out. Is there an expected shelf life of the hardware? I would expect for sure on the storage devices. So if that were the case then why isn't there some sore of daemon or system software service that tracks the expected life of the hardware? I would expect that the software would start showing warnings of imminent useful life of de…

I run a fairly large homelab (probably ~10 nodes when including OPNSense routers, backup NAS at our cottage, etc.), and hardware failures have been incredibly rare, especially compared to what it used to be a couple of decades ago (I had quite a few motherboards fail due to blown capacitors due to the stolen electrolyte formula scandal).

Hardware failures tend to follow a bathtub curve: there are more frequent failures early on due to manufacturing defects, then they become rare until you reach the end of the natural lifespan of the equipment. That is shorter for some components (spinning rust HDDs, fans, CMOS batteries, power supplies in noisy environments), but extremely long for others.

Re: The death and rebirth of my home server

#54
post #11
post #7

I'm not a sysadmin but I often hear about server failures due to hardware just wearing out. Is there an expected shelf life of the hardware? I would expect for sure on the storage devices. So if that were the case then why isn't there some sore of daemon or system software service that tracks the expected life of the hardware? I would expect that the software would start showing warnings of imminent useful life of de…

There is for hard drives - SMART - the problem is, unless you're an enterprise (and let's all stop and laugh because we KNOW that most "enterprises" run at least some hardware until the only person who even knows it exists is long in the grave) you're not going to do preventative replacement. And especially for home use, where nien 9s is more realistic than nine 9s, you're better off having a solid backup strategy an…

I run a k8s cluster in my homelab, with Longhorn providing storage. Except for some extra-large volumes for bulk storage (just movies in Jellyfin right now), everything is replicated three ways. I've had nodes fail to boot up after a power outage (turned out to be a dead CMOS battery) and procrastinated bringing them back up because everything just kept working.

Re: The death and rebirth of my home server

#55
post #7

I'm not a sysadmin but I often hear about server failures due to hardware just wearing out. Is there an expected shelf life of the hardware? I would expect for sure on the storage devices. So if that were the case then why isn't there some sore of daemon or system software service that tracks the expected life of the hardware? I would expect that the software would start showing warnings of imminent useful life of de…

> So if that were the case then why isn't there some sore of daemon or system software service that tracks the expected life of the hardware?

Some linux distribution will regularly check SMART data from disk and warn you if some threshold has passed (like number of corrected errors, spin up/down, total hours etc).

That said, if we talk about consumer hardware in a home lab or the like, of the disks that I bought in the past 15 years, only one broke down, and it did fairly quickly so my suggestion is to use redundant storage, make backup and change the disk when it breaks down. (Enterprise disk and usage is another can of worms of course).

Re: The death and rebirth of my home server

#56
post #2

Raspberry Pis are notorious for SD card corruption with unknown causes. In this era you might replace it with a mini-PC (NUC style).

My issues with Pis and SD cards ended when I switched to using SSDs as boot drive.

I discovered that barely-used enterprise Intel SSDs (DC S3610, S3700, S3710) were cheap on ebay a year or so ago and I may have bought a few dozen. These things have remaining endurance measured in petabytes. Sure, it’s overkill to have a 200GB enterprise SATA disk as the boot volume for a Raspberry Pi, but this is exactly my kind of overkill.

Re: The death and rebirth of my home server

#57
post #2

Raspberry Pis are notorious for SD card corruption with unknown causes. In this era you might replace it with a mini-PC (NUC style).

> Raspberry Pis are notorious for SD card corruption

True SD cards are less than ideal.

But also I suspect half the problem specifically with Pi and SD cards is that people use cheap-ass SD cards and maybe ones they found in the bottom of a drawer that may or may not have previously been used in another device (e.g. camera).

I suspect if people bought industrial SD cards instead of consumer-grade junk they might get a better lifespan out of them.

Re: The death and rebirth of my home server

#58
post #56

Earlier quoted context omitted.

My issues with Pis and SD cards ended when I switched to using SSDs as boot drive.

I discovered that barely-used enterprise Intel SSDs (DC S3610, S3700, S3710) were cheap on ebay a year or so ago and I may have bought a few dozen. These things have remaining endurance measured in petabytes. Sure, it’s overkill to have a 200GB enterprise SATA disk as the boot volume for a Raspberry Pi, but this is exactly my kind of overkill.

Yeah, as soon as I was able I upgraded my Pi 4s to be able to boot USB and used an SSD in an enclosure as my main boot volume. Works rather well.

Re: The death and rebirth of my home server

#59
post #2

Raspberry Pis are notorious for SD card corruption with unknown causes. In this era you might replace it with a mini-PC (NUC style).

> Raspberry Pis are notorious for SD card corruption True SD cards are less than ideal. But also I suspect half the problem specifically with Pi and SD cards is that people use cheap-ass SD cards and maybe ones they found in the bottom of a drawer that may or may not have previously been used in another device (e.g. camera). I suspect if people bought industrial SD cards instead of consumer-grade junk they might get…

I used to get Sandisk cards but recently I stopped using SD cards altogether. When it came time to update from Debian 12 to 13 for my Pi4 I migrated to an NVME USB enclosure for my boot drive. Just yesterday I set up another Pi4 for a project with an M.2 SATA enclosure and in both cases they work just fine.

Re: The death and rebirth of my home server

#60
post #50

Earlier quoted context omitted.

Zram creates a compressed RAM disk. https://wiki.archlinux.org/title/Zram

It's also not the optimal choice in most situations: https://chrisdown.name/2026/03/24/zswap-vs-zram-when-to-use-...

The main point is to use zswap over swap plus zram. The sd card usecase definitely doesnt want swap to disk, compressed or otherwise, so zram or no swap are the options.
Post reply on HN