Flash memory generally doesn't have great lifespan for repeated writes; using it as a root device is going to kill it pretty quickly. I had a similar problem once running a NAS off a USB stick; within a year of so the stick would no longer accept new data and I swapped it out for an SSD instead.
I found GoPros to cook SD cards from time to time. It makes me wonder if normal sized SD are still manufactured and are they more resistant. For years in stores I only saw miro SD with adapter to full size.
I suspect most of the "corruption" RPi users experience is likely bad power (shitty undersized USB power bricks) glitching the CPU and causing the filesystem to corrupt. The SD card is likely doing exactly as it's being told by the host system - write (invalid) data to blocks, which it does.
I have always bought the official power supply, yet of the two Pi 3s that I have connected to my TV at home, the one that runs Kodi/OSMC to serve up movies has never suffered any filesystem corruption, despite it suffering repeated power outages without warning (it's low enough to the ground that the toddler has often pulled the power cable out, and I haven't been able to find a better place to keep it). The other one, bought at the same time from the same source, is meant to be the one the kids use for programming in Snap!, a variant of MIT Scratch that doesn't have the artificial limitations that Scratch has. (Snap! functions — the exclamation mark is part of the name — can take lists as input, whereas Scratch functions can only take numbers or strings, giving it an artificial ceiling; also, Snap! functions can take functions as input and return functions, making higher-order programming possible, while Scratch deliberately does not allow that). However, that Raspberry Pi has suffered two SD card failures in the past year; it's been down more often than it's been up, and I've ended up using either my laptop or my wife's laptop for my kids' programming lessons.
It's actually weird that Raspberry Pis seem so bad at using SD cards.
I've just scrapped a large PBX which had a whopping 8MB SD card in it. Its 486 processor booted Linux off the SD card, it wrote CDRs to the SD card, it served said CDRs up over a web interface off it, it saved its logs to the card, and all the other day-to-day chatter of a running system.
It was installed pretty much 20 years ago. The date sticker on the SD card shows that it was replaced 18 years ago, presumably as part of an upgrade.
I'm going to guess that it was not a normal COTS SD card, and instead designed for continuous writes.
The factors for SD card failures in raspberry pi seem to be mostly SD cards not meant for the purpose and having things like swap, atime or disk logs enabled which leads to unnecessary writes.
We “lost” a signage device in a facility we were doing an IoT refresh on.
It was an old wyse terminal, and at some point a CF adapter with an SD card was added, and a construction project buried it inside of a block wall. lol. It’s still there.
I’ve had the same issues in the Pi1-3 era, can’t say for sure if it was the Pi, the SD card, or the software running on top (HA was a big culprit). The last issues were probably before 2018-2018. Since then I don’t remember having any failure and I have a bunch of Pi3s and 4s running with flawlessly for about that long, including HA.
Since then I’ve been careful to buy high quality cards, oversized them a bit, optimize the OS and apps with regards to writes (like no unnecessary logging), and paid attention to airflow. The software probably also evolved to fix the issues.
"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
By "RPI owner behaviour" I mean the decision made by the RPi owner in choosing what operating system software to run and how to configure it
When I bought RPi Model B the hardware did not come with an OS pre-installed
It booted only from SD card
It was up to me to choose which OS to run. I did not choose any of the "recommended" operating systems. I was already booting other "diskless" computers using USB sticks with root mounted on tmpfs so I wanted to use that same OS for the RPi
I never experienced SD card corruption with RPi hardware
However I have experienced SD card corruption with other SBCs that had an OS pre-installed, an OS not chosen by me
By choosing to run a "recommended" OS on the RPi perhaps I would experience SD card corruption
But if that happened I would not attriubute it to the RPi. I would blame myself. And I would make different choices going forward
And when you say "due to RPi owner behaviour" what you're saying is "due to the default setup". It's a Raspberry Pi problem. The devices are notorious for this issue for good reason.
I have a rasperry pi 2 and 4 that have been running on the same size uSD (reputable brand) for 5 years and haven’t had any issues. I have swap turned off. You just have to be aware of the i/o and not do anything stupid. Clearly for heavy i/o with multitasking they are not ideal.
You can buy cards that support SMART if you want to track wear, but they are expensive.
My 3 Pis have destroyed 6 SD cards. One of them also somehow drew too much power when trying to boot and got so hot it burnt me and melted itself but that could have been the power supply. I know the 4s and 5s can blow SD cards if you run them without heatsinks.
What I'm saying is, your anecdotal evidence of two pis doesn't justify saying we did something wrong with the configuration. In my experience raspberry pis still behave like "throwaway devices" but their price tags do not justify it anymore.
Alternatively cheapest fix is an m10 optane and nvme enclosure. You maybe need to enable usb quirks in the kernel depending on on enclosure. Costs about 20 bucks all in
That’ll keep the rasp online for essentially forever cause optane isn’t going to wear out
> 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.
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.
Could be some other hardware issue for you, yeah. I recall there are some problems that can happen if the usb power supply is too weak. But this fixed it for me.
Yeah that's more or less my goal for the setup in the post... I didn't have much time to investigate what else I could move off of the SD card but I suspect there's a few other things I could do. NixOS makes it super easy too.
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.
Can confirm, I've got a pi 5 here that's been running 24/7 for over a year (possibly two)... it boots fine, but anything else makes it run so slowly because the sdcard is trashed.
The current setup writes to the systemd journal at least twice every minute... It's next iteration is getting a proper nvme.
Ho-ho my friend! You want to buy storage for your computer before 2030? I'm so sorry, but you now pay big time, now you sell your car for one nvme drive.
There is no need to bring this up on every mention of buying a computer part. And this is also very wrong. TLC nvme drives go below $40, and the smallest ones have more than enough storage for a pi.
Really would just prefer a working, non-buggy, Pi2 maybe without all the crazy extra power + compute + RAM. Or at least have the option, because $20 is more my style for a lot of these tasks, not $150CDN.
Classic power failure and raspberry pi with SD cards. When I last set up things for my parents, I simply imaged a bunch of SD cards and had the data stored on an external hard drive. I live in the US and they live in India and this is for their RaspBMC. With the SD cards they just swap a broken one with a new one and call it a day.
Been 12 years or so now. Went back to their home a few years ago and everything but the opensubtitles integration works. I was surprised. I could never recreate it now. Even has one of these flirc setups so the remote works.
India has unreliable power too so the SD card death was inevitable. I made a few more images and called it a day.
My Raspberry Pi 4 has been used to run both a Jitsi and Trackmania server over the years. I never considered using the SD card since it can boot and run from a USB 3 flash drive. Later on, I picked up an Argon One case to add a SATA SSD.
Thankfully, modern Rockchip SBCs tend to come with NVMe slots.
I use a Waveshare hat for my Pi 5s. It does PoE and has a spot for an SSD. What I particularly like about this setup is the single wire running to each board, looks very clean.
The failure everyone plans for is the disk; the failure that actually gets you is the boot media. The fix is making a rebuild boring, not making the hardware immortal.
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 devices to expire.
There are plenty of sensors and systems that can "predict" failure and in some cases try and work round them.
Do most people actually use them? Pretty rarely. S.M.A.R.T is just trash anyway.
But you do need to properly design your systems to limit the amount of "use". No un-needed writes to disk etc. Proper ambient detection, no point trying to rush to shut down servers when the AC pops it, and you just so happen to walk into a server room.
I'm running my own home server on an old 2014 Mac mini, 24/7 basically. It both has a SSD and a HDD (old "Fusion" disk type of machine, but I use both parts separately, the SSD part for the OS, the HDD part for the data.)
A few days ago the HDD had its 100,000 Power_On_Hours anniversary. :) According to SMART this is way past the expected/ designed life time of the disk (the normalised value reports "1" since a few years when the disk hit about 42,000 Power_On_Hours)
So you never know. It either works or it doesn't. You have backups for the worst case.
My main desktop machine with assorted components is from 2014, also with an SSD and HDD. Each component has lasted all this time somehow. The total uptime of each drive is 11.5 years (101,023 hours) with 159 power cycles. The SSD is 256 GB and has 71 TB written, it's my main drive. It has 46% lifetime remaining, I hope everything lasts another 10+ years.
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 and a source of spare parts.
My main "tank" server is 16 years old this year, and has blown out one motherboard - it was a bit annoying to be "offline" for a few days as a replacement wandered in from eBay, but it worked. If it happened today I might import the zpool into another device temporarily - or permanently, who knows? This R510 probably takes more power than a datacenter.
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.
My primary home zfs server is from 2010, running 24x7 since then. It has a 4-way mirror zfs pool for data. Over the years I have replaced two of the four drives, so two are still original from 2010. Everything else on the machine is from 2010.
You can get unlucky and have components fail quickly, but usually if they last, they'll last for a long time.
But trying to run a server from an SD card like in the article, seems silly. False economy, just get a good SSD.
For drive health monitoring there is SMART, but IME while it does monitor drive usage and lifetime, it rarely predicts catastrophic failure since that happens suddenly. Both drives that failed in this system went from healthy (according to SMART) to unresponsive overnight.
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.
> 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).
Life expectancy really depends on how the hardware gets used. I run a small fleet of servers that are heavily CPU / GPU loaded, and the most frequent hardware failure I see is power supplies, with RAM as #2 and spinning HDDs as #3. Each of these (on enterprise-grade gear) has some amount of reporting / monitoring, but it's rarely the case that I get any advance warning before a failure. The RAM is probably the nicest, as it sometimes starts with correctable ECC warnings. Nearly all of the PSU failures have been sudden deaths, with the only saving grace being N+1 redundant supplies usually keeping the victim server alive.
Hardware wearing out is not common at the individual component level. It only becomes common when you are running a large number of servers, those individual small probabilities add up.
About the only thing that regularly wears out is spinning drives, and those have SMART data to give you an idea of when they'll die, but generally yif you're actually committing to high uptime you'll have redundant hardware so any one server failing doesn't take the service down, giving a bit of a grace period on hardware failures
> Swap is not generally about getting emergency memory, it's about making memory reclamation egalitarian and efficient. In fact, using it as "emergency memory" is generally actively harmful.
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.
Moving swap off of sdcard is indeed a good plan.
But since swapping is done when ram is depleted, using a ramdisk for it (which uses ram) is ... exactly what you dont want.
Since OP states they have disks attached to the machine as well, the better thing is use a partition there for swap.
> Not eager to ruin the evening by starting a debugging session
Use a clanker. Nothing has brought back so much joy into homelabbing for me as having LLMs handle the boring stuff.
I launch it in opencode on the system or elsewhere to ssh in (I think giving it KVM is an overkill but an option nonetheless) and tell it to fix things. Not just ask questions and generate configs. I have backups, let it rip. They have gotten shockingly good at it even when they write bash wrappers just to catch some logs.
If i'm reading this correctly, can run Immich from a Raspberry Pi 4? That's pretty cool.
I bought all the stuff (new case, networking card and a Jonsbro N4 to repurpose some intel i7-9700 era processor and motherboard, but didn't get it setup yet, as I was starting to rethink the power consumption....
Also looking to use this rebuild as an opportunity to learn Nix.
Let me know if you all have some good article references, to point me at. I've been doing some research, but could always do more.
I may end up putting a low power NUC in the case, or something. I don't know...
> If i'm reading this correctly, can run Immich from a Raspberry Pi 4? That's pretty cool.
Yes! It runs completely fine on a Pi, except for the machine learning service. The good news is that you can run that service on a separate computer with a GPU and point Immich to it. Immich will use it when it's available and I think you can configure it to run all the queued ML jobs at a certain time when you expect the computer running the ML service to be on.
You can, I am self-hosting Immich via Docker on Raspberry Pi 4 with small SSD and it's nothing but good experience so far (but I keep the photos backed up elsewhere just in case, I use Immich mostly to share curated sets of photos)
Lack of proper IO connector is the reason I abandoned Raspi. SD card crashes are nearly a guarantee. Total pita too since there’s no display during the BIOS.
Another useful advise would be to keep your boot drive 60% used at max and run TRIM after freeing a huge chunk of files to let the wear leveling algo do its job.
And every few years reinstall the OS to free up unwritten cells.
Personally I would get a used Dell Optiplex / Lenovo ThinkCentre / HP EliteDesk. Either the "mini" / "micro" if you really want small. I am a fan of the SFF (Small Form Factor) size and the Dell Optiplex models. In particular the 70XX versions that offer Intel AMT / vPro for remote management.
I run a Proxmox server on my Dell Optiplex SFF 7070. With the SFF size you can add two low-profile PCIe cards, if desired. In my case I added a 10Gbit NIC.
The reason I would go with a used Dell / Lenovo / HP is that these tend to be well-built machines that run for years and years 24/7 in offices and proven to work well.
I picked Beelink a couple years ago. It didn’t last long. I can’t simply reboot it. I have to unplug it, wait 5 minutes, plug it in, and then boot it. It turns OS installs and even system updates into such a hassle that it’s not even worth using anymore. I wanted to run it headless and just connect remotely, and that doesn’t really work well with this issue, as I need regular physical access.
I assume it’s a bad capacitor or something. I tried changing out the power adapter, but that didn’t help.
Raspberry Pis are notorious for SD card corruption with unknown causes. In this era you might replace it with a mini-PC (NUC style).
Flash memory generally doesn't have great lifespan for repeated writes; using it as a root device is going to kill it pretty quickly. I had a similar problem once running a NAS off a USB stick; within a year of so the stick would no longer accept new data and I swapped it out for an SSD instead.
Yeah but it's also SD cards in particular and Raspberry Pis in particular.
I found GoPros to cook SD cards from time to time. It makes me wonder if normal sized SD are still manufactured and are they more resistant. For years in stores I only saw miro SD with adapter to full size.
Are there other computers that run off of SD cards long term successfully that are not Raspberry Pi’s?
I work on embedded linux machines that go a decade plus in active use with micro sd cards, it's not a problem at all
I suspect most of the "corruption" RPi users experience is likely bad power (shitty undersized USB power bricks) glitching the CPU and causing the filesystem to corrupt. The SD card is likely doing exactly as it's being told by the host system - write (invalid) data to blocks, which it does.
I had more than my fair share of SD failures running pis off their official power supplies.
It really is a high failure rate.
"Enterprise" Boot SD's in servers love to die.
More than likely due to being in a warm box...
Do pis have an official power supply?
Yes. https://www.raspberrypi.com/products/power-supply/
I have always bought the official power supply, yet of the two Pi 3s that I have connected to my TV at home, the one that runs Kodi/OSMC to serve up movies has never suffered any filesystem corruption, despite it suffering repeated power outages without warning (it's low enough to the ground that the toddler has often pulled the power cable out, and I haven't been able to find a better place to keep it). The other one, bought at the same time from the same source, is meant to be the one the kids use for programming in Snap!, a variant of MIT Scratch that doesn't have the artificial limitations that Scratch has. (Snap! functions — the exclamation mark is part of the name — can take lists as input, whereas Scratch functions can only take numbers or strings, giving it an artificial ceiling; also, Snap! functions can take functions as input and return functions, making higher-order programming possible, while Scratch deliberately does not allow that). However, that Raspberry Pi has suffered two SD card failures in the past year; it's been down more often than it's been up, and I've ended up using either my laptop or my wife's laptop for my kids' programming lessons.
I've had enough SD and micro-SD cards die on phones and cameras to doubt that is the only problem.
People probably see more of a problem on raspberry pis because they write more to the memory than other systems.
Reminds me of years ago, I had to send a load of photos to a client of something I'd travelled 5 hours to photograph.
Didn't even check, just took and sent. Then went back.
Only to find that the SD card in the phone was dying, and every image was corrupted from about 1/3 down...
It's actually weird that Raspberry Pis seem so bad at using SD cards.
I've just scrapped a large PBX which had a whopping 8MB SD card in it. Its 486 processor booted Linux off the SD card, it wrote CDRs to the SD card, it served said CDRs up over a web interface off it, it saved its logs to the card, and all the other day-to-day chatter of a running system.
It was installed pretty much 20 years ago. The date sticker on the SD card shows that it was replaced 18 years ago, presumably as part of an upgrade.
Because of a properly configured, boot disk. Just boots once per power cycle.
Meanwhile something like the pi, on most images, is writing logs to the storage CONSTANTLY. Not to mention is regularly booted.
I'm going to guess that it was not a normal COTS SD card, and instead designed for continuous writes.
The factors for SD card failures in raspberry pi seem to be mostly SD cards not meant for the purpose and having things like swap, atime or disk logs enabled which leads to unnecessary writes.
It just appears to be a pretty standard Sandisk SD card.
We “lost” a signage device in a facility we were doing an IoT refresh on.
It was an old wyse terminal, and at some point a CF adapter with an SD card was added, and a construction project buried it inside of a block wall. lol. It’s still there.
Been there before, the amount of times when you're in shared spaces that you come one day to find your kit disconnected, or even outright buried.
We came one day to a plant room where our rack was, to find it was in an entirely different "room", with a locked door....
Early on Raspbian didn't specify noatime or even relatime; every time something was read off disk, a write happened.
Let alone things like putting /var/tmp and/or /var/log in RAM, or long commit intervals.
No idea what the current situation is; Pis are too dear for the likes of me now.
> Early on Raspbian didn't specify noatime or even relatime; every time something was read off disk, a write happened.
relatime is a default for a while now, like decade+, you don't need to set up mount option just to get relatime
I’ve had the same issues in the Pi1-3 era, can’t say for sure if it was the Pi, the SD card, or the software running on top (HA was a big culprit). The last issues were probably before 2018-2018. Since then I don’t remember having any failure and I have a bunch of Pi3s and 4s running with flawlessly for about that long, including HA.
Since then I’ve been careful to buy high quality cards, oversized them a bit, optimize the OS and apps with regards to writes (like no unnecessary logging), and paid attention to airflow. The software probably also evolved to fix the issues.
"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
By "RPI owner behaviour" I mean the decision made by the RPi owner in choosing what operating system software to run and how to configure it
When I bought RPi Model B the hardware did not come with an OS pre-installed
It booted only from SD card
It was up to me to choose which OS to run. I did not choose any of the "recommended" operating systems. I was already booting other "diskless" computers using USB sticks with root mounted on tmpfs so I wanted to use that same OS for the RPi
I never experienced SD card corruption with RPi hardware
However I have experienced SD card corruption with other SBCs that had an OS pre-installed, an OS not chosen by me
By choosing to run a "recommended" OS on the RPi perhaps I would experience SD card corruption
But if that happened I would not attriubute it to the RPi. I would blame myself. And I would make different choices going forward
And when you say "due to RPi owner behaviour" what you're saying is "due to the default setup". It's a Raspberry Pi problem. The devices are notorious for this issue for good reason.
Default setup is 100% softwareless
... and the default instructions guide you to install the Raspberry Pi Imager which will format and configure an SD card for your hardware.
The recommended OS during this process is .... "Raspberry Pi OS" i.e. Raspbian.
I have a rasperry pi 2 and 4 that have been running on the same size uSD (reputable brand) for 5 years and haven’t had any issues. I have swap turned off. You just have to be aware of the i/o and not do anything stupid. Clearly for heavy i/o with multitasking they are not ideal.
You can buy cards that support SMART if you want to track wear, but they are expensive.
My 3 Pis have destroyed 6 SD cards. One of them also somehow drew too much power when trying to boot and got so hot it burnt me and melted itself but that could have been the power supply. I know the 4s and 5s can blow SD cards if you run them without heatsinks.
What I'm saying is, your anecdotal evidence of two pis doesn't justify saying we did something wrong with the configuration. In my experience raspberry pis still behave like "throwaway devices" but their price tags do not justify it anymore.
More just that lots of standard images don't bother with tmpfs for logging. So all that IO onto the disk kills them
I suspect it isn’t the hardware but the bullheaded approach of running a desktop Linux environment from an SD card.
You suspect correctly. Embedded applications are less affected, and mounting the card r/o solves the problem completely.
Alternatively cheapest fix is an m10 optane and nvme enclosure. You maybe need to enable usb quirks in the kernel depending on on enclosure. Costs about 20 bucks all in
That’ll keep the rasp online for essentially forever cause optane isn’t going to wear out
> 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.
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.
I’ve got an rpi4 booting from an usb ssd and bought a n100 minipc anyway… last February for $150. Should have bought a 40ft container of these
I regret selling mine
Make the sdcard a read only root fs, problem solved
Doesn't actually help. It eventually goes corrupt anyway. It might be related to power ripple or something.
Makes it easy to replace, though.
Could be some other hardware issue for you, yeah. I recall there are some problems that can happen if the usb power supply is too weak. But this fixed it for me.
Yeah that's more or less my goal for the setup in the post... I didn't have much time to investigate what else I could move off of the SD card but I suspect there's a few other things I could do. NixOS makes it super easy too.
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.
Can confirm, I've got a pi 5 here that's been running 24/7 for over a year (possibly two)... it boots fine, but anything else makes it run so slowly because the sdcard is trashed.
The current setup writes to the systemd journal at least twice every minute... It's next iteration is getting a proper nvme.
Ho-ho my friend! You want to buy storage for your computer before 2030? I'm so sorry, but you now pay big time, now you sell your car for one nvme drive.
Somebody set up us the bomb.
There is no need to bring this up on every mention of buying a computer part. And this is also very wrong. TLC nvme drives go below $40, and the smallest ones have more than enough storage for a pi.
This is the first time I've every brought this up, ever.
I'm super happy with an Odroid H3 as a NAS: low power usage, silent, x86, nvme + 2 sata ports. Runs home assistant, smb shares and a few more things
Just have the raspberry pi boot from a USB/SSD.
Rpi5 has a pcie slot if you want a cleaner setup.
Really would just prefer a working, non-buggy, Pi2 maybe without all the crazy extra power + compute + RAM. Or at least have the option, because $20 is more my style for a lot of these tasks, not $150CDN.
That was a good read.
But this is the kind of experience that makes technical people fall in love with self-hosting, but also keeps the majority of the population away.
Most of the people don't want the hassle of managing a self-hosting box.
I think a middle ground option might where someone hosts it for you, but you can also move to your own hardware at any time might be best
Classic power failure and raspberry pi with SD cards. When I last set up things for my parents, I simply imaged a bunch of SD cards and had the data stored on an external hard drive. I live in the US and they live in India and this is for their RaspBMC. With the SD cards they just swap a broken one with a new one and call it a day.
Been 12 years or so now. Went back to their home a few years ago and everything but the opensubtitles integration works. I was surprised. I could never recreate it now. Even has one of these flirc setups so the remote works.
India has unreliable power too so the SD card death was inevitable. I made a few more images and called it a day.
Abusing frontier AI to determine what the hell I did with ancient installs, and then modernizing it, as been quite useful.
My Raspberry Pi 4 has been used to run both a Jitsi and Trackmania server over the years. I never considered using the SD card since it can boot and run from a USB 3 flash drive. Later on, I picked up an Argon One case to add a SATA SSD.
Thankfully, modern Rockchip SBCs tend to come with NVMe slots.
I use a Waveshare hat for my Pi 5s. It does PoE and has a spot for an SSD. What I particularly like about this setup is the single wire running to each board, looks very clean.
The failure everyone plans for is the disk; the failure that actually gets you is the boot media. The fix is making a rebuild boring, not making the hardware immortal.
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 devices to expire.
There are plenty of sensors and systems that can "predict" failure and in some cases try and work round them.
Do most people actually use them? Pretty rarely. S.M.A.R.T is just trash anyway.
But you do need to properly design your systems to limit the amount of "use". No un-needed writes to disk etc. Proper ambient detection, no point trying to rush to shut down servers when the AC pops it, and you just so happen to walk into a server room.
I'm running my own home server on an old 2014 Mac mini, 24/7 basically. It both has a SSD and a HDD (old "Fusion" disk type of machine, but I use both parts separately, the SSD part for the OS, the HDD part for the data.)
A few days ago the HDD had its 100,000 Power_On_Hours anniversary. :) According to SMART this is way past the expected/ designed life time of the disk (the normalised value reports "1" since a few years when the disk hit about 42,000 Power_On_Hours)
So you never know. It either works or it doesn't. You have backups for the worst case.
Reminds me of the old forum posts where people show off their uptimes.
Uptime is fine, until you restart. And poof
Not unlike a combustion engine, cycles can do more damage than hours.
My main desktop machine with assorted components is from 2014, also with an SSD and HDD. Each component has lasted all this time somehow. The total uptime of each drive is 11.5 years (101,023 hours) with 159 power cycles. The SSD is 256 GB and has 71 TB written, it's my main drive. It has 46% lifetime remaining, I hope everything lasts another 10+ years.
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 and a source of spare parts.
My main "tank" server is 16 years old this year, and has blown out one motherboard - it was a bit annoying to be "offline" for a few days as a replacement wandered in from eBay, but it worked. If it happened today I might import the zpool into another device temporarily - or permanently, who knows? This R510 probably takes more power than a datacenter.
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.
That’s the biggest danger with hot fail over at homelab setting. It keeps working so there’s no reason to fix it.
My primary home zfs server is from 2010, running 24x7 since then. It has a 4-way mirror zfs pool for data. Over the years I have replaced two of the four drives, so two are still original from 2010. Everything else on the machine is from 2010.
You can get unlucky and have components fail quickly, but usually if they last, they'll last for a long time.
But trying to run a server from an SD card like in the article, seems silly. False economy, just get a good SSD.
For drive health monitoring there is SMART, but IME while it does monitor drive usage and lifetime, it rarely predicts catastrophic failure since that happens suddenly. Both drives that failed in this system went from healthy (according to SMART) to unresponsive overnight.
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.
> 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).
Life expectancy really depends on how the hardware gets used. I run a small fleet of servers that are heavily CPU / GPU loaded, and the most frequent hardware failure I see is power supplies, with RAM as #2 and spinning HDDs as #3. Each of these (on enterprise-grade gear) has some amount of reporting / monitoring, but it's rarely the case that I get any advance warning before a failure. The RAM is probably the nicest, as it sometimes starts with correctable ECC warnings. Nearly all of the PSU failures have been sudden deaths, with the only saving grace being N+1 redundant supplies usually keeping the victim server alive.
Hardware wearing out is not common at the individual component level. It only becomes common when you are running a large number of servers, those individual small probabilities add up.
About the only thing that regularly wears out is spinning drives, and those have SMART data to give you an idea of when they'll die, but generally yif you're actually committing to high uptime you'll have redundant hardware so any one server failing doesn't take the service down, giving a bit of a grace period on hardware failures
SSDs have a fairly linear wear-out mechanism although the exact end point is unpredictable as always. HDDs fail randomly or from mechanical shock.
If you're using a USB adapter on a Pi 4 you can use raspi-config to enable booting from an external drive and not worry about SD cards at all
For anyone trying this with a Pi older than the Pi 4, you might still need an SD card with one file on it: https://www.raspberrypi.com/documentation/computers/raspberr...
> I chose to enable zram for swap
swap is used when you run out of ram. using a ramdisk for swap ... You see how that doesnt make sense?
It's more complicated than that, same as PAGING on Windows. It's about offloading some of the less accessed data from RAM onto slower hardware.
You can compress the swap, so you can squezze a bit more by using CPU in that tiny amount of read you do.
> swap is used when you run out of ram
This is not correct. Swap is not a RAM overflow.
> Swap is not generally about getting emergency memory, it's about making memory reclamation egalitarian and efficient. In fact, using it as "emergency memory" is generally actively harmful.
https://chrisdown.name/2018/01/02/in-defence-of-swap.html
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.
Moving swap off of sdcard is indeed a good plan. But since swapping is done when ram is depleted, using a ramdisk for it (which uses ram) is ... exactly what you dont want. Since OP states they have disks attached to the machine as well, the better thing is use a partition there for swap.
Exactly. The previous install of the system had no swap at all so enabling zram is an improvement.
> Not eager to ruin the evening by starting a debugging session
Use a clanker. Nothing has brought back so much joy into homelabbing for me as having LLMs handle the boring stuff.
I launch it in opencode on the system or elsewhere to ssh in (I think giving it KVM is an overkill but an option nonetheless) and tell it to fix things. Not just ask questions and generate configs. I have backups, let it rip. They have gotten shockingly good at it even when they write bash wrappers just to catch some logs.
What a great example of nice writing. I just liked reading it.
The RPi Compute Module is mush better with on board flash. Completely removes the SD Flash Achilles heel of the RPi.
this would have been the perfect era for home servers - but damn Ram is expensive.
every other component is cheap enough but not Ram.
I've been running a CUPS server on a Pi Zero W since 2017. I suppose I should back up the SD card.
Back in the day I ran s××× coin miners off flash drives without any apparent problems.
Teslas though... ;)
If i'm reading this correctly, can run Immich from a Raspberry Pi 4? That's pretty cool.
I bought all the stuff (new case, networking card and a Jonsbro N4 to repurpose some intel i7-9700 era processor and motherboard, but didn't get it setup yet, as I was starting to rethink the power consumption....
Also looking to use this rebuild as an opportunity to learn Nix.
Let me know if you all have some good article references, to point me at. I've been doing some research, but could always do more.
I may end up putting a low power NUC in the case, or something. I don't know...
> If i'm reading this correctly, can run Immich from a Raspberry Pi 4? That's pretty cool.
Yes! It runs completely fine on a Pi, except for the machine learning service. The good news is that you can run that service on a separate computer with a GPU and point Immich to it. Immich will use it when it's available and I think you can configure it to run all the queued ML jobs at a certain time when you expect the computer running the ML service to be on.
You can, I am self-hosting Immich via Docker on Raspberry Pi 4 with small SSD and it's nothing but good experience so far (but I keep the photos backed up elsewhere just in case, I use Immich mostly to share curated sets of photos)
A few years ago I decided to give up on sdcards for my main 24/7 homelab server.
I now use a small SSD connected via USB3 and a slightly modified version of this : https://framps.github.io/raspiBackupDoc/introduction.html
...to take snapshots to my NAS periodically.
I keep a similar small SSD in the drawer ready for a restore and swap if the main system drive fails.
Lack of proper IO connector is the reason I abandoned Raspi. SD card crashes are nearly a guarantee. Total pita too since there’s no display during the BIOS.
ARM doesn't have BIOS, BIOS is even legacy to pre-x86
Another useful advise would be to keep your boot drive 60% used at max and run TRIM after freeing a huge chunk of files to let the wear leveling algo do its job.
And every few years reinstall the OS to free up unwritten cells.
Why not get a Beelink N95 and call it a day?
Personally I would get a used Dell Optiplex / Lenovo ThinkCentre / HP EliteDesk. Either the "mini" / "micro" if you really want small. I am a fan of the SFF (Small Form Factor) size and the Dell Optiplex models. In particular the 70XX versions that offer Intel AMT / vPro for remote management.
I run a Proxmox server on my Dell Optiplex SFF 7070. With the SFF size you can add two low-profile PCIe cards, if desired. In my case I added a 10Gbit NIC.
The reason I would go with a used Dell / Lenovo / HP is that these tend to be well-built machines that run for years and years 24/7 in offices and proven to work well.
Or a used tower form factor PowerEdge if you want a little bigger, but still designed to be quiet in an office environment.
I picked Beelink a couple years ago. It didn’t last long. I can’t simply reboot it. I have to unplug it, wait 5 minutes, plug it in, and then boot it. It turns OS installs and even system updates into such a hassle that it’s not even worth using anymore. I wanted to run it headless and just connect remotely, and that doesn’t really work well with this issue, as I need regular physical access.
I assume it’s a bad capacitor or something. I tried changing out the power adapter, but that didn’t help.
I don’t see myself ever buying another Beelink.