Considerations for a long-running Raspberry Pi

I started buying Lenovo mini PCs instead, 18cm x 18cm x 3cm so it&#x27;s still really small.<p>And you can get them dirt cheap nowadays, has proper casing and cooling etc <a href="https:&#x2F;&#x2F;psref.lenovo.com&#x2F;syspool&#x2F;Sys&#x2F;PDF&#x2F;ThinkCentre&#x2F;ThinkCentre_M720_Tiny&#x2F;ThinkCentre_M720_Tiny_Spec.pdf" rel="nofollow">https:&#x2F;&#x2F;psref.lenovo.com&#x2F;syspool&#x2F;Sys&#x2F;PDF&#x2F;ThinkCentre&#x2F;ThinkCe...</a><p>I have one right next to me, i5-8500T, 32GB RAM, 2x SSDs and currently 5W at idle with powertop auto-tune <a href="https:&#x2F;&#x2F;wiki.archlinux.org&#x2F;title&#x2F;powertop" rel="nofollow">https:&#x2F;&#x2F;wiki.archlinux.org&#x2F;title&#x2F;powertop</a>

First advice is to enable journaling mode on FS.<p>First advice must be to mount FS in read only mode, mount &#x2F;var in memory and forward al logs to one nide, which may be not RPi but something with proper UPS and nut running. Power loss becomes absolutely bening if your FSes RO or temporary.<p>It is overkill if you have one RPi but author claims that he uses multiple RPis all around a house.<p>Also, good idea to have A&#x2F;B system partitions and upgrade system with full partition rewrite and changing active one. Thus way your system will have one good system partition in any case, even if new version has fatal bugs, and recovery become trivial.<p>I&#x27;m using several small&#x2F;single board PCs im different roles in such way for 20+ years with great success.

Back in 2011 I made a commercial product that ran on the earliest plug computers from global scale technologies. I only sold 20 of &#x27;em and every single one of them was being returned with SD card corruption problems. I had to quickly pivot to keeping the rootfs read-only. I&#x27;ve been a fan ever since.<p>Incidentally, that early commercial product was a home security product with a very small amount of home automation. I released this into open source with a new name in 2021 and now runs on the Jetson series SBCs (<a href="https:&#x2F;&#x2F;github.com&#x2F;hcfman&#x2F;sbts-install">https:&#x2F;&#x2F;github.com&#x2F;hcfman&#x2F;sbts-install</a>). Except then including high end YOLO models as triggers.<p>Because it was intended to be a standalone product it supported https with a GUI wrapper around all of the certificate operations. This still exists in my open source version, making it easy to use self signed certificates for intra-device rest calls.<p>But I&#x27;ve kept and expanded upon the multi-partition memory overlayFS approach and the installation of this system first asks you to install the sbts-base system, which installs the multi-partition memory overlayFS so that other&#x27;s can use this as their own base systems.

I am urging everyone who wants to do this to see if they can&#x27;t first do what they need with a small board like an ESP32. Their energy usage is a small fraction, they cost ones of dollars, and they&#x27;re sufficient for a whole lot. If you&#x27;re of the Python persuasion, many boards support both MicroPython and CircuitPython.<p>It&#x27;s worth looking into for the cost savings on initial purchase and ongoing power draw.

&gt; This feels like a hack, but based on hours of reading online discussions, most people seem to settle on a script that periodically checks whether the WiFi connection is good, and restarts the WiFi interface or the whole Pi if it’s not.<p>It&#x27;s <i>not</i> a hack, it&#x27;s best practice! Just like important servers in a data center should have some kind of out of band connectivity (IPMI, remote controllable RPDU outlets, etc), Important servers in remote difficult to reach locations should have some kind of watchdog script. The script should of course be tuned to the specific use case, considering the impact of a reboot vs downtime until reboot. At the very least it could log adverse events for later investigation.<p>A simple bash watchdog script was the very first thing I did when I deployed a remote RPI. Not just for wi-fi issues but for any of the dozens of things that could break and be fixed with a reboot.

We’ve been running thousands of Pis in production for about a decade now. We’re beginning to shift to x86. The price&#x2F;performance isn’t what it once was for the Pi. I gave a talk about our experience recently at State of Open Con here (<a href="https:&#x2F;&#x2F;youtu.be&#x2F;vX-qK9mxKZI" rel="nofollow">https:&#x2F;&#x2F;youtu.be&#x2F;vX-qK9mxKZI</a>).

I did exactly zero of any of those things and have had some Pis run for multiple years without any issues until being replaces by a newer model (my HomeKit&#x2F;Zigbee gateway and data logger is now a Pi 4). I guess it all boils down to good SD cards and stable power supplies.

I&#x27;m shocked the SD card bit isn&#x27;t first, and more surprised that the post doesn&#x27;t suggest USB boot (I have one pi that&#x27;s been on ~24&#x2F;7 for years now, and I attribute its lack of problems to 1. using Alpine configured to barely touch disk, and 2. not <i>having</i> an SD card to corrupt - I don&#x27;t know why USB would be more reliable, but anecdotally it is)

I have 2 Pis running basically non-stop (2-3 power outages) with the same SD card since 2017 (DNS&#x2F;print server and Kodi, media is on external NFS). The only thing I did was to disable <i>all</i> logs. Never had a single problem.<p>They both have SanDisk 2 GB cards in them. I vaguely remember naively thinking along the lines of &quot;less space =&gt; less bit density =&gt; better reliability&quot;.

&quot;Keeping a Raspberry Pi online and working with zero intervention for weeks, months, or years is somewhat of an art form.&quot;<p>I just boot NetBSD kernel with embedded filesystem, e.g., INSTALL kernel or custom kernel. SDCard can be removed immediately after boot. Optionally chroot to attached storage. This runs for weeks, months or years. Have not experienced any of the issues cited by the blog author. Only issue I find is with the power connector when using a case; the connection can be brittle, e.g., if using a replacement cable. Perhaps this has improved on more recent Pis. (But I could say the same about most computers. The cables and connectors are usually fragile. It&#x27;s always cheap stuff.) If power is interrupted because of movement, then the Pi reboots automatically.

<p><pre><code> a) Cable ethernet b) SSD (via USB3.0 adapter on my RPI4) c) Ubuntu Server LTS 22.04. d) cheap UPS. </code></pre> Mine runs Yggdrasil network, HAproxy, Caddy server, a couple of webservers in containers, and a TMUX instance that I log into almost daily to write code (slow computer reveals bad code much better). Since I put it (and my router) on the UPS, in the last 2 years it has literally never gone offline other than a couple of times I rebooted it for firmware upgrades.

I use some Pis for various things in my house including Zeroes through CM4s and 4Bs.<p>The Zeroes run Raspbian configured with the read-only filesystem option. I have found it necessary to uninstall `unattended-upgrades` because the overlayfs employed for read-only root caches disk writes in RAM and the update&#x2F;upgrade process exhausts RAM. For the same reason I disable swap. It makes no sense to swap to RAM on a 512GB system.<p>Upgrades are tedious since they require disabling overlayfs, rebooting, upgrading, rebooting, and enabling overlayfs. I wrote Ansible playbooks to perform these tasks. (<a href="https:&#x2F;&#x2F;github.com&#x2F;HankB&#x2F;Ansible&#x2F;tree&#x2F;main&#x2F;Pi">https:&#x2F;&#x2F;github.com&#x2F;HankB&#x2F;Ansible&#x2F;tree&#x2F;main&#x2F;Pi</a>)<p>I have a Pi 4B performing as a file server and running Debian (not Raspbian) It boots from an SD card so that the entire HDDs can be used for a ZFS pool. To reduce wear and tear on the SD card I have mounted `&#x2F;var` to a ZFS filesystem. I should probably use `tmpfs` for `&#x2F;tmp`.<p>I use a Pi CM4 to run HomeAssistant and that boots and runs from an NVME SSD where durability is less an issue.

As someone using many, many Pi&#x27;s at home and many times that at work, the preferred approach is to boot them all diskless (and for those that actually need an SD card, boot them off a read-only SD card and get everything else off the home server). This is so much easier than having lots of different SD cards&#x2F;Pi versions etc, and makes them trivial to replace in the event of failure.

Just read the data sheet of the Sandisk Max Endurance and, oh boy, what a fsck’ing marketing bs language.<p>They state the endurance on thousands of hours of FHD video, but what assumptions do they make in bitrate etc?<p>Can‘t they state total TB written or drive writes per day or something sensible?

Switching to gokrazy[0] was the best thing I did for my Raspberry Pi uptimes. I think a lot of that is because it defaults to using read-only partitions so the common issue of SD cards falling over when you run apt upgrade no longer happens.<p>But I also think that gokrazy&#x27;s simplicity and design helps it be just a solid, reliable foundation to build on top of.<p>[0]: <a href="https:&#x2F;&#x2F;gokrazy.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gokrazy.org&#x2F;</a>

The longest running RPi I have has run continuously for over 5 years. The big secret was not to use the SD card at all[1], I mount all file systems over the network to a NAS device (TruNAS from iX systems). It has a &quot;UPS&quot; in the form of a USB battery pack that is both charging from main power and powering the Pi. When power goes out the battery pack takes over, it has about a day of &quot;hold up&quot; time depending on Pi power usage. It is &#x27;hard wired&#x27; to the local network (it doesn&#x27;t use WiFi).<p>I got there from having SD cards (nearly[2]) always be the failure point. Everything else has been pretty reliable when used within tolerances.<p>[1] It does &quot;boot&quot; from the SD card but that acts kind of like a third stage bootloader which loads and boots the &quot;real&quot; OS (FreeBSD) from the NAS device.<p>[2] I have had one fairly spectacular looking &quot;melt down&quot; of a no-name USB power supply wallwart PSU which, to appears to have also put something like 12V directly across the USB power pins (my best guess at what the secondary winding of the xformer in the wall wart was putting out on the &#x27;low&#x27; side)

This covers the readonly filesystem, but doesn&#x27;t cover the write protect flag that you can set on the microSD card itself[1]. The flag will configure the card&#x27;s controller to drop any writes, and is thought to resist the corruption issues that can still occur even when the filesystem is readonly.<p>Also, creating a readonly root out of an existing disto is a bit of a pain, my preference is to use a distro (like TinyCore) that&#x27;s already a readonly root.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;BertoldVdb&#x2F;sdtool">https:&#x2F;&#x2F;github.com&#x2F;BertoldVdb&#x2F;sdtool</a>

Half of the post is about SD cards, wear, data loss and reliability. Just use SSD?

I&#x27;ve been running a bunch of Pi&#x27;s for years now, and the biggest problem I&#x27;ve had is the Pi itself dying: 24&#x2F;7 usage is hard on a small device. I&#x27;ve also found that stable power is essential, and to that end I&#x27;ve always used 5v 3a branded power cubes, plugged into a pure sine wave UPS. Choice of micro-SDHC cards is important and I ended up getting ATP industrial cards (<a href="https:&#x2F;&#x2F;www.atpinc.com&#x2F;products&#x2F;industrial-sd-cards" rel="nofollow">https:&#x2F;&#x2F;www.atpinc.com&#x2F;products&#x2F;industrial-sd-cards</a>) - expensive but really long-lived. Finally, using RPi-clone (<a href="https:&#x2F;&#x2F;github.com&#x2F;billw2&#x2F;rpi-clone">https:&#x2F;&#x2F;github.com&#x2F;billw2&#x2F;rpi-clone</a>) on a regular basis has been a life-saver. I clone to Sandisk Extreme micro-SDHCs and can recover from an outage in minutes.

It&#x27;s worth noting that SD card firmware is usually optimised for the FAT32 filesystem, which has a very predictable access (specifically write) pattern, and using filesystems that have a more &quot;free-form&quot; layout can lead to lower performance and higher write amplification:<p><a href="https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;428584&#x2F;" rel="nofollow">https:&#x2F;&#x2F;lwn.net&#x2F;Articles&#x2F;428584&#x2F;</a>

I have an original Pi 2012 running buildroot. It&#x27;s a perfect fit. Need just enough to run a Linux kernel and ser2net for doing RS485 stuff with solar inverters. I think the image size was around 100MB and no volatile filesystem whatsoever.<p>Buildroot was surprisingly easy to use. Use a menuconfig to pick what you need and a burnable image for your SD card comes out the other side. Think I only spent an hour on the whole project.

I have a cluster of 7 SBCs, 1 pi 3b and 6 Tinkerboards of various models. The Pi I got in 2016&#x2F;17 and ran Gitlab without issue until 2022, something in the SD card got corrupt and linux was no longer able to boot, I was able to salvage all of the data and continued with a new SD card. The tinkerboards, which have various tasks as VPN, Nextcloud, staging servers using docker have never corrupted an SD card.<p>I think the tinkerboards are better than Pi’s especially the ones that come with 16gb of onboard flash storage. However you don’t get all the niceness of PiOS but have to use TinkerOS (which was less than barebones when it came out) or Armbian which is nice but not built specifically for the tinkerboard.<p>I have a few friends who complained about Pi’s corrupting SD cards and it also happened to my only long running Pi so there is something going on.

My sound localizing Raspberry Pi installs a resilient base system as part of its install.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;hcfman&#x2F;sbts-aru">https:&#x2F;&#x2F;github.com&#x2F;hcfman&#x2F;sbts-aru</a><p><a href="https:&#x2F;&#x2F;hackaday.com&#x2F;2023&#x2F;12&#x2F;30&#x2F;localizing-fireworks-launches-with-a-raspberry-pi&#x2F;" rel="nofollow">https:&#x2F;&#x2F;hackaday.com&#x2F;2023&#x2F;12&#x2F;30&#x2F;localizing-fireworks-launche...</a><p>With one command it for all Pi’s for both Raspbian and bookworm it:<p>* Shrinks the file system (Gee, how does it do that with just one disk ? ;-) )<p>* Creates new partitions<p>* Installs a memory overlayFS<p>* Installs and configures the system as an audio recorder with micro second time accuracy<p>* updates &#x2F;etc&#x2F;rc to do a forced repair of the data and config portions, in case they were damaged. This avoids system hangs waiting for human interaction with fsck<p>For the partitioning scheme it creates a swap partition, not as a wow but as an enabler if you really need it to install some large software.<p>It creates a small config partition. The idea here is that you keep it read only and remount it read write if you need to change config then remount it read only again.<p>And finally a data partition, which in this projects case is where the audio files are written.<p>I maintain a version of an overlayFS boot for the Pi but it needs revisiting for bookworm. The easiest way to use do this is to install the sbts-aru and then just don’t use it. Then everything is done for you in one command. And that version works for all Pi’s.<p>I also do this for the Jetson SBCs. But I need to revisit this for the Orin series. I have it working here for myself and friends but need to update the installer. Note, due to kernel behavior changes with Orin the older Pi like overlayFS code will not work. But I solved this and will release it when I release the Orin release of sbts-install soon.<p>I’ve been using memory overlayFS like installs for years for long running Pi systems.

I&#x27;d consider enabling the hardware watchdog as well.<p>While one could argue that you should figure out the source of your device freezing in the first place;<p>Nothing is better than having to ask someone to power cycle your Raspberry Pi while you&#x27;re away.

I&#x27;ve been running a Pi 4 as a home server for a few years. When boot-from-USB became available, I moved to that, with a good-quality USB thumb drive for boot&#x2F;root (I&#x27;ve had had SD card issues in the past) (and also speed, though I doubt it makes much practical difference). A couple of weeks ago I started getting intermittent disk errors. I thought it was the USB drive, so I cloned it (still worked well enough on my laptop) to another drive. Same thing happened. So everything points to the USB controller glitching out. Have gone back to an SD card, and everything seems fine.

It is the the time for mini PCs as many have noted it. I am getting one for one of my offices, instead of building or buying a desktop.<p>I used to build my machines and loved it. Some are still chugging along after over 10 years. They were worthwhile <i>before</i> the mini PCs reaching comparable capabilities at lower cost.<p>One thing I still cannot seem to find is a good site that compares various vendors in similar fashion as &quot;PC builder&quot; sites do of build components.<p>Any suggestions?

I have been running a Raspberry 2 cluster for 10 years.<p>A few weeks back the first SD card to fail got so corrupted it failed to reboot!<p>My key learning is use oversized cards, because then the bitcycling will wear slower!<p>I&#x27;m going from 32GB to 256&#x2F;512&#x2F;1024!<p>That said &quot;High Endurance&quot; cards are a scam, they fail way quicker than regular cards!<p>All SD cards except SanDisk have latency problems. There is no competition.<p>If you can get SLC SD cards use them for workload instances = no db or file storage.

I&#x27;m still using a Sandisk 8GB microSD from 2008 running 24&#x2F;7: smartphone expansion 6 years -&gt; Orange Pi as a router for 3 years, Pi 4 running Frigate for 3 years.<p>I&#x27;m guessing it&#x27;s SLC&#x2F;MLC.<p>Had a Transcend 32GB in 2016 die after a year.<p>The biggest issues with set-and-forget setups is software upgrade for security or other reasons, jumping major versions ends up breaking things. Compared to cloud which is (usually) regularly updated.

For the life of me I don&#x27;t really get it why Raspberry Pi Foundation does not include onboard eMMC or SSD storage in their non-compute modules products.<p>Yes with the new PCIe expansion in the latest RPi 5 you can have external SSD for example, but if you decided to use it for other purposes as well like extra Ethernet port expansion then you cannot use it for booting anymore.

And here is me, who is running a Pi1 in my cellar for 10 years straight, which logs all my temperature sensors over 433Mhz + triggers my door openers via physical relay over WIFI, without doing anything special. After some years I only connected it to a UPS, after the sdcard filesystem died after some power outages....

Going to plug my own side project from the past here: <a href="https:&#x2F;&#x2F;cattlepi.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cattlepi.com&#x2F;</a> <a href="https:&#x2F;&#x2F;github.com&#x2F;cattlepi&#x2F;cattlepi&#x2F;blob&#x2F;main&#x2F;README.md">https:&#x2F;&#x2F;github.com&#x2F;cattlepi&#x2F;cattlepi&#x2F;blob&#x2F;main&#x2F;README.md</a><p>Been running pis (mostly 3b+) for eons with this solution and at this point i can say it&#x27;s bulletproof.<p>The key is to minimize the sdcard wear and tear (it uses an overlay filesystem with squashfs as base and tmpfs as write top layer) and to keep zero stare on the device. You can build the image starting from normal raspbian. You can also update it over the network.<p>As far as usage in the wild the largest &quot;deployment&quot; (i know about) is at around 1000 pis.

Buy a decent SD card and overprovision the space and wear leveling will take care of the rest. I have a Pi with a 128GB SD card and a 32GB filesystem on it running for 6 years straight without problems now. No need to disable logs, just disable debug logging so you won‘t generate gigabytes a day.

Also: consider using overlayfs to make root fs read-only

A few people have mentioned achieving long uptime. What is often overlooked is that it is possible for uptime to be too long.<p>It is quite possible for updates to not break a running system but make it so that it will break on the next reboot. E.g., a dynamic library gets updated in a way that breaks a server process. It doesn&#x27;t affect the running server because it still has the old library loaded.<p>Next time you boot your server process doesn&#x27;t start.<p>These kind of problems can be annoying to deal with, especially when your system has an uptime of years and for all you know whatever change broke it could have been in any one of dozens of updates you&#x27;ve applied over that time.

&gt; This is unlikely to do anything unless you’re hitting some unusual bug, but it’s worth noting that IPv6 has, in the past, led to all sorts of strange behaviors in different networking contexts.<p>This makes me sad. I don&#x27;t doubt that there are scenarios in which <i>having</i> IPv6 connectivity makes things worse, but these days, the opposite is more common, so I don&#x27;t think &quot;disable IPv6 just in case&quot; is a good blanket recommendation to make anymore.<p>&quot;If disabling IPv6 fixes your issue consistently, consider disabling it&quot; would achieve the same outcome, without potentially causing problems&#x2F;inefficiencies down the road.

Step 1 is to question why you&#x27;re using a Raspberry Pi. It&#x27;s almost never the correct answer.<p>If there&#x27;s a really really good reason, step 2 is to get rid of the SD card. Personally, none of mine even have an SD card inserted (ok, one does). I use network boot&#x2F;NFS for everything. Some people attach other kinds of SSDs.<p>The one I lied about is a reverse telnet server that has been quietly doing its thing for 4 years without a hitch, apart from the time I had to replace the (PiJuice) backup battery because it was looking a little swole. But I should take the time to at least have a backup of the card ready to swap out when it fails.

Another nice thing you can do if you use the multi-partitioned memory overlayFS approach I mentioned earlier is you can make &#x2F;var&#x2F;docker be a symlink to your read-write data partition. Obviously you are going to have problems using docker with the standard memory overlayFS approach.<p>Also nice, is you can make your data or other partitions be encrypted. I&#x27;ve done this before. On the Pi 5 you can use the standard encryption as there&#x27;s hardware support. On earlier Pi&#x27;s you can use the encryption used for android. This does means there&#x27;s a manual step in the startup for you to enter your encryption password.

Their suggestion for log2ram does help for the most part but depending on what the pi is running, even that doesn&#x27;t completely solve it. I&#x27;ve burnt out a number of microSD cards running a Pi-hole instance. I finally gave up and moved it to a tiny x86 with a SSD.<p>Yet I&#x27;ve been feeding ADSB-Exchange and FlightAware from a Pi Zero for years and never had SD card problems.<p>I really like Alpine Linux for the Pi, running in it&#x27;s own read-only mode where changes must be committed to disk. But unfortunately, Pi-hole isn&#x27;t compatible with Alpine (at least last time I checked)

I use a USB connected SSD as boot. Been running Home Assistant and Pihole for years with zero issues.<p>EDIT: Also, make sure the power supply is sufficient. I was using a cheap adapter and had random errors and reboots.

I have a Raspberry PI 1 model B running almost non-stop for over 8 years (except during power outages) serving as my front gate controller. Custom python code uses the GPIO pins to trigger an RF remote to open or close the gate, and does not write to SD for logs&#x2F;etc (to prevent SD wear)<p>I use a USB network card, and a high-quality SD card. Other than that, no other special configs (except for another spare SD card with a full system image clone).<p>Rock solid performance and uptime over 8 years.

Also no mentioning of the power connector? I have too little experience with USB-C, but the micro USB connector used on early Raspberry Pi&#x27;s is just asking for trouble. That might be (barely) good enough for charging, but a computing device w&#x2F;o battery-backup won&#x27;t take lightly the power interruptions when jiggling the cable a little. I finally got around to replace it with an old-fashioned (time tested!) barrel connector. Easy way to improve the robustness significantly.

Anything long running shouldn&#x27;t happen over that piece of crap that WiFi is. Data centers aren&#x27;t build over WiFi. My network at home neither.<p>I&#x27;ve been running RPi for years (including a VoIP server on a RPi 1!). The two tricks if you want a really long running Pi are: SD cards mounted read-only and ethernet.<p>FWIW I ve got a Pi running the <i>unbound</i> DNS resolver and it just works. It is not an art. There s a reason businesses are scooping up millions of Pi: they just work.<p>P.S: I ve got an army of NUCs too.

Around early 2019 I set up a raspberry pi 3 running Raspbian. I made the &#x2F;var&#x2F;log partition a ramdisk. Haven&#x27;t touched it since. It goes down for power outages but probably has been out for a couple minutes total over five years (aside from power outages). Most of its job is to translate analog audio to a USB speaker system. Whole house audio for about $150. Anyway, I never touch it, it just works, all the time.

Do people really have such a neurotic aversion to the sight of cables that they&#x27;d rather struggle with workarounds to an always-inferior wifi than just using an ethernet cable? It seems unhealthy to get that stressed out over the sight of a 3cm wide cable.<p>I&#x27;ve had an RPi4 running continually for close to a year and never had a single network connectivity issue between the RPi4 and my router, connected via a 30m cat5 cable in my 75m² condo.

I got one of those super low profile USB thumb drives and then set the Pi to boot from that. It ran automation here in my house for 2.5 years without a blip.

I have a few long time running Pis - and have been keeping them up for a decade now. No SD Card corruption ever and i got close to 1000 days uptime on one.<p>The biggest problem is loss of wifi, after a few months one will lose wifi, but keep working - it’s constantly recording data so a reboot is not a good idea. I’d prefer a solution where I could just reset the wifi, but all attempts to script that reliably so far failed.

I can appreciate the effort and time put into this, but seems completely overkill. I’ve been running 4x Pi 4B’s in a Kubernetes cluster for over 3 years 24&#x2F;7&#x2F;365. Only thing I did is disable swap (which you should do for Kubernetes anyway) and used SanDisk Extreme 128GB cards[1].<p>[1] <a href="https:&#x2F;&#x2F;a.co&#x2F;d&#x2F;ipehodH" rel="nofollow">https:&#x2F;&#x2F;a.co&#x2F;d&#x2F;ipehodH</a>

having used an original model b (rev 2) since 2013 with running 24&#x2F;7 for about 80% of the time, i feel that a lot of this depends on how much you want to push your pi.<p>for context, my workload was bursty in nature and nowadays it is mostly idle. but i never had any issues with the SD card, and i only upgraded to a new one for getting more capacity all this time (only twice).<p>keeping the dust out and managing the temperatures would go most of the way. i have served files directly from the sd card but it is always better to mount an external drive for this, while providing enough power to the board to power usb devices. limiting debug logs for stable applications can also help avoid write cycles, but using sd card on a pi has been a similar workload to using one in older smartphones for storing media.

When I worked with that, we had the SD card entirely read-only, and a usb stick mounted for writing. I think the rpi wouold detect a broken file system on boot and reformat the usb stick. It also made it easy to pull the usb stick and format it in any windows pc to reset it.

I’ve got 2 rPI’s thats been running for 4+ years each. Only thing I do is update them once in a while. Both have workloads running 24&#x2F;7. no issues. I have however experienced issues in the past but those were due to a faulty power adapter not keeping voltage within spec.

Haven’t followed any of these tips, yet I have barely stumbled upon any issued with my long running pi

All the SD problems go away if you get a RPi Compute Module instead. Well worth the additional cost.

Admittedly, I only have one long-running Raspberry Pi, but it&#x27;s currently sitting at a few months uptime. And that was an intentional reboot. I&#x27;ve never had to take any measures like these in the four or so years I&#x27;ve had it up.

i very much so enjoyed these articles even if i don’t use raspberry pi anymore. it has a very much so research notes cleaned up for sharing feel and reminds me of some of my teams internal articles, particularly on research the author wasn’t sure on but wanted to put out there regardless. it was very easy to get their decisions and the limit of their research and knowledge so i had pretty clear idea what i need to still check on my own and what i might adopt if i were to use rpi devices.<p>i don’t really get what to use a rpi for but i guess not important, it was just a nice series of articles

As far a I know (and my knowledge inly goes to version 4) the RasPi does not support different power states or sleep modes. It would be interesting how it compares in power consumption to other solutions.

I wonder if Raspberry OS comes configured not to swap on the SD by default …

Anything long running should have ECC RAM, which the Pi doesn&#x27;t have.

All my home Pis network boot, so there is no card to fail. You can also change what OS they boot into by just renaming a symlink on the server and rebooting them. Very convenient.

I&#x27;ve been plagued with the wifi problem since changing routers. Devices on the local network will randomly lose the ability to connect to it, but everything else is fine.

I don&#x27;t think I took many special precautions and a Pi I had running as a VPN server survived for about 10 years, aside from a power supply failure or two.

I don&#x27;t understand what&#x27;s hard about adding like 256MB of flash soldered to that thing, I&#x27;d pay $5 more if it did.<p>Everytime there&#x27;s a RPI I cry about it.

No mentioning of flashybrid? I&#x27;d thought that&#x27;s the obvious solution to SD wear (or rather the danger of SD corruption on sudden power loss).

My experience with long-running raspberry pi&#x27;s is that there are USB problems. One sometimes loses the connection to these devices.

Not a single mention of netbooting the Pi instead of relying on crappy SD cards which wear faster than I can type this.

&gt; Your SD card can wear out or completely fill up<p>Why is the author not considering using an SSD instead of an SD-Card here?

Not sure about the SD cards he recommends. Use Swissbit SD cards. But they will cost you.<p>Mouser is your friend.

I run my RPi&#x27;s 24&#x2F;7 from initramfs. I can even remove card after boot.

I use OpenWrt whenever it&#x27;s possible, to avoid SD card wear completely.

Alpine in diskless mode and an ethernet cable solve 2&#x2F;3 of that.

Does that have a hardware stall timer?

eventually you&#x27;ll think about power outages. i had a pihat battery nearly explode on me. beware!

&gt; Keeping a Raspberry Pi online and working with zero intervention for weeks, months, or years is somewhat of an art form.<p>What are you talking about?<p>It is literally zero effort. Just set up crontab reboots in case of power outage. That&#x27;s it.<p>I&#x27;ve had a pi running as a BLE gateway &#x2F; security cam for over 4 years with zero intervention.