Raspi cannot be used for a semi serious server application due to microsd card write wear issues. All other methods of attaching external storage by USB bus to an rpi are not reliable or suitable for this sort of purpose. Nowhere near the longevity of something with a native sata or m.2 SSD interface and a real SSD.
There's also the added complication of the fact it's an ARM based device so in some cases you might run into compatability issues, or testing your container locally becomes problematic.
"Raspi cannot be used for a semi serious server application due to microsd card write wear issues."
As an end user, I run a personal authoritative DNS server that has small RAM requirements. The RPi (or other SBC) boots to a mfs mounted root, then mounts all directories as tmpfs. Then I remove the SD card.1 As such, the logs for this server, which are automatically rotated and do not exceed 5M in total, are written to RAM.
1 I only use the SD card to boot. The only files on the card are a bootloader, a bootloader config and two kernels, each with an embedded filesystem. If updates are necessary, I make them to one of the kernels at a time. The other is the backup. The bootloader and bootloader config lets me specify which kernel to boot.
Don't most modern SD cards contain some wear leveling logic?
I did a bunch of research on this a while back and the conclusion I found was: yes, but buy name-brand better rated cards to avoid cheapo cards that do not do wear leveling or do it very badly.
It's nowhere near as good as SSD drives, but it's better than just a naked flash chip... unless I'm wrong.
Hey if you see this can you answer one more question:
How much abuse was your high availability product delivering to these cards in terms of writes? Was it something like a video recorder, database, cryptocurrency, or some other application that did large amounts of write I/O?
I ask because we're about to ship something that uses SD cards, but the I/O is very low. It's a network appliance and doesn't do anything locally that is high write throughput.
The Linux kernel in raspbian treats the SD card like a normal block device. I'm not aware of any special optimization for write wear leveling at the OS level, or on the board's sd card controller.
SD card wear-levelling is usually supposed to be handled on the controller inside the SD card. SD cards aren't like having raw access to flash, you basically write over SPI and the controller in the SD card decides where to actually put it.
This talk about SD cards is really great and explains some of this:
