I'm using/running different SBCs, but my experience is very similar, I only had issues with them when the PSUs or SD cards were having problems. SD cards are known to die, it's only a matter of time for their cells to wear out. But you can extend their lifespan by minimizing the amount of data written to them, or even using them completely in read-only mode.
I found these guides helpful when researching the topic:
I have have been doing this for years also. Not only is it much faster, and less prone to failure, it doesn't take long to clone the whole drive to a spare.
I do this before any major updates, then swap to the cloned disk to do the updates, so it's easy to roll back.
Swapping disks reduces wear and small SSD are just as cheap as SD cards these days.
I have one running a bit over five years with no issues. Seems odd one would die so soon. Maybe the environment??
I have some rpi3 that are running in outdoor rated enclosures going on 7 years now? rpi 4 for about 6? (i guess just after they came out). Only SD cards needing replaced so far.
Was reading through this thread last night before bed. Get to work today and see that my pi has stopped its API requests.
As far as I can tell the cellular signal dropped or the hotspot reset. Reconnect to the hotspot, transmit my data and reboot for good measure…
Pi doesn’t boot back up, can’t establish ssh through wireless or wired. Several power cycles later pull the Sid card, extract my flow files and reflash the card.
Running again now as expected. Very strange occurrence though. First time I’ve had it happen, and this particular pi wasn’t in operation all that long <1y.
32GB pny card, perhaps it will need something better.
@DWoodlock Did you check the logs? Any recent auto updates? Are you just running bog standard?
I did not. In retrospect I probably should have, but didn’t occur to me at the time. I have been aware of the SD card risk, just this is the first time it’s actually been an issue for me.
I was just thrilled I was able to read the card and get my flows file out because I had forgotten to back it up after the most recent change.
Fair enough.
To answer the OP, I think longevity for these devices really comes down to 3 things;
I think that last one is probably the biggest impact. I've not done this for a few years now, but I did some light testing on an older Raspberry Pi when I was running it as an always-on PiHole, and installing better active cooling on certain components made performance better and imo extended its life. I'll see if I can dig up the data I recorded back then.
I don't consider a SD card a pi failure. That's more of a consumable along the lines of a hdd. To me a pi failure is when something on board, cpu, ethernet port, memory fail.
Something more or less soldered in
Recently I started using DietPi, and its default logging configuration is to store logs in RAM, preventing (very frequent and most of the time unnecessary) writes to the SD card. More info here: Log System Choices - DietPi.com Docs
Of course it has downsides, logs are lost on reboot, etc., so debugging certain issues could be harder, but in that case I think one can just switch to persistent logging temporarily, and then switch back to RAM logging after their issue is solved.
So this is another quick and simple way to ensure SD card longevity.
Really, nowadays, we don't need to worry about logs, assuming something is not spamming the log with hundreds of MB daily. Use good quality SD cards from reputable suppliers and use cards that are twice the size you need, so that the wear algorithm has plenty of space to work. Cards will last many years.
Keep an image backup of each system so you can easily recover if one does go bad.
I don't consider a SD card a pi failure. That's more of a consumable along the lines of a hdd.
I mean I guess it's what you consider a fault vs. a failure. For me, it's a Pi hardware fault but definitely a Pi failure in the chain of things. That's all semantics though - but I do think using a better card for storage probably makes more efficient use of write resources, probably has some non-trivial heat additions to the overall system, etc.
But yeah fair enough in the actual baseline health/survival of the Pi itself.
Not sure exactly what you mean by that, especially the heat part. Did you mean that a larger sized card generates more heat? If so, I don't believe that is true in any meaningful way.
However, quality SD-Cards include wear levelling which is why having an oversized card is important. None of the cheap cards (some of the more expensive ones too) have wear levelling and this drastically reduces the lifespan of the card as does not having enough spare space for the levelling to work effectively.
Even if you do these the lifespan of an SD card is limited and it will go bad eventually. Then why would you intentionally choose not to extend its lifespan? I don't understand this logic. For me personally the longer lifespan far outweighs the the cons of setting up RAMlog or an equivalent. Or simply just use DietPI, which comes with this feature enabled by default.
No, my point was that speed, size, and quality all have impacts on write operations and heat management. Low-quality high-density cards tend to have really poor electronics under the hood and generate a ton of heat, which ironically slows write operations which only generates more heat. So you end up creating a little resistive heater in your system, and if you're using a Pi - especially if you're using it in an IIoT scenario where you might use passive cooling - this can impact thermals across the entire unit.
That's not even to mention that lower quality cards can have internal shorts or other issues that could risk the device.
But this is a really niche sub-topic of a sub-issue of a core issue when it comes to longevity, so I hesitate to place too much importance in it outside of just noting that it could be an issue.
That isn't so much about lifespan of cards but rather about memory constraints. For most Pi's, day-to-day memory is far more important than the multi-year lifespan of the card. Tying up memory with logs is not a priority.
Not heard of either of those issues. However, I've never used low-quality cards in a Pi. Why would I? It isn't as though a mega-sized card is needed and so even good quality cards are not expensive - well they weren't last time I looked anyway. Even a 32GB Samsung Evo (or even better one of the higher tiers of Evo's) wasn't at all expensive and those are what I always use - for everything actually, Pi's, cameras, etc. Cheap cards are never worth it and if you are using an SD-Card, no matter what for, I can't think of any situation where using a cheap card would be acceptable.
Do keep in mind that it's only people like us that really are aware that the few bucks you save on low-cost cards don't justify the potential loss in data, potential heat issues, etc. The number of new students who think they can just buy a no-name SD card from their local Daiso or whatever and be good to go is outrageous in my experience.
And to be clear, I'm not saying low-quality cards should be acceptable or common - I'm just sharing it as a potential variable in this conversation on life expectancy. All things being equal, if you use the right power adapter, you use high quality memory, you use proper cooling (specifically moving to active if you're doing high-load work), and don't shove the Pi between two hot machines or something, you should be golden when it comes to life expectancy. But if you skip one of those...well it's likely that you're going to start skipping more than one of those.
Well, I am not an educator these days but if I were an educator, I would certainly be educating students in this.
And, in regards to this forum, this is exactly why we take pains to explain these things repeatedly over time.
Of course, unloading writes to cards on a Pi does reduce the wear but the balance equation is not as straight-forward as it may seem. Shifting logs to memory for example can actually make write worse if the memory use results in additional swap file use. So looking at things any which way, the recommendation to get good cards comes first. Tweaking Linux to reduce writes comes 2nd and becomes less useful the less memory the Pi model has.
Memory limitation is a valid concern in very constrained environments, but FYI the default RAMlog size in DietPi is 50MBs, which is not a lot to make any difference 
And writing that much daily to an SD card is not going to make a measurable difference in lifetime.
Copyright OpenJS Foundation and Node-RED contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation, please see our Trademark Policy and Trademark List. Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them.
The OpenJS Foundation | Terms of Use | Privacy Policy | OpenJS Foundation Bylaws | Trademark Policy | Trademark List | Cookie Policy