Need a reliable 'disk' drive - what/how to choose?

I have a couple of Pis which run all the time, one is the DNS server for our home LAN the other is a 'NAS' in the garage. So they're on all the time but not particularly hard worked.

Over the past year or so both of them have failed once with some sort of corruption of the micro-SD card. Not life-threatening by any means but quite annoying and both took quite a while (like half a day) to restore and get back to fully configured and working.

So I'm wondering how to either find extra reliable SD cards or to change to something else such as a USB disk (on of the two systems is a Pi 4 so that one at least is easy to boot from USB).

The storage can be tiny by modern standards, a 4Gb SD card would be perfectly OK.

So what does the panel suggest? Preferably cheap! :-)

For my music/video system (Pi3), I have 128Mb SD card (FAT, boot) booting to a 128Gb USB SSD (ext4, root) and a 5Tb powered USB HDD NTFS as /media. It's been running for years with no problems. Just changed the cmdline.txt file root=UUID= to point to the SSD partition.

Re: Re: Need a reliable 'disk' drive - what/how to choose? By: Martin Gregorie to Chris Green on Sun Dec 12 2021 07:55 pm

To your list of solutons, I'd like to add

4) Use an operating system that does not write to the SD card once it has booted. (Such as PiCore)

A good, reliable way to corrupt an SD card is to have a power outage, or even just a glitch while the card is being written to. This is part of the design of SD cards - they were designed to be cheap and are not really designed to replace an HDD or SDD - the job they were designed for is one where writing to the card is FAR less frequent than reading it.

Short answer - there is no super-reliable SD card.

Solutions - in no particular order are:

1) Use a cheap SSD, but many of these may also get corrupted if there's a power fail while the SSD is being written to.

2) build or purchase a small UPS for the Pi. Designs and Pi-HAT UPS products are available.

3) Assuming that you update the Pi's software every week or so, Back up the Pi's SD card using rsync. Rsync is reliable, fast and can write the backup, via the link you use to talk to the Pi, onto backup media attached to your your main computer(s). Make the backup immediately before you do the software update.

I use the last approach. Its fast, straight-forward once you've configured a copy of rsync on the Pi to backup the whole SD card when requested to do so and configured another copy of rsync on the machine which will receive the backup to write that to your backup device.

I use a pair of Western Digital Elements USB-connected 1GB hard drives to act as a two generation backup set, and use then in strict sequence to make my backups, and keep them in a fire safe when not actually being used to make a backup.

In fact I back up four computers, weekly, to that week's backup disc (2 x Fedora laptops, my house server (also Fedora), and an RPi. The 1GB backup disks have stabilised at 37% full. If yoyu want a cheaper backup solution, you could always do what I described but instead of two USB packaged HDDs, use , say, a pair of 16GB HDDS.

Yes I have a home server Pi3B - imap, DNS, NTP, NFS, SMTP, web, syslog, backup etc server....

19:47 root@mercury:~# uptime 19:47:03 up 641 days, 23:06, 1 user, load average: 0.13, 0.05, 0.15

under a similar scheme, but with a spinning USB HD. The SD card's boot partition is mounted ReadOnly to protect it from corruption, and I keep a backup copy of the root filesystem of the USB HD on the SD card copied every week by a script that mounts the SD ext4fs rsyncs then unmounts it

- again to protect the SD card.

If I need to upgrade the OS and there is a chance the boot code might be upgraded I remount that partition readwrite for the upgrade only.

I'm commisioning a Pi4 as a replacement with 2 USB3 Attached HDs. The extra throughput on USB3 and Gigabit ethernet will make the backups go a lot quicker. Other things just work a charm.

OP here. My 'NAS' is an early Pi 4, only 1Gb memory. It has an 8TB USB drive as the backup drive and just the standard micro USB as everything else.

I have backups of everything that's extra/non standard so when it died yesterday it was [fairly] easy to reinstate but I'd prefer not to have to do it again.

This page (not mine) discusses some hardware and software options for improved reliability:

I like the idea of mounting the root fs as read-only and running in RAM. I use Tiny Core Linux for that, where it's the default (though not done the same way as in Raspbian). OpenWRT also has their own scheme for minimising wear to the flash, because cheap routers often have built-in flash chips which are only designed for occasional writes.

Yes, but how do you tell the difference between a 'cheap SSD' and a USB stick that is essentially just an[other] SD card?

That's an idea.

All my backups *to* the Pi NAS use rsync already, I use rsync everywhere. I don't have an image of the Pi software but I can restore fairly quickly, that's why it only took a few hours to sort things out when it died.

My go-to USB SSD is a Sandisk Extreme Pro, which is actually a SATA SSD in a USB stick form factor. Not the cheapest, but proper SSD reliability.

If size/power isn't a constraint, any SATA SSD or HDD in a SATA-USB case would do.

Another option is to go with a Pi Compute Module with EMMC. EMMC is product grade storage, as fitted to laptops and tablets. There are some basic carrier boards for the CM4 for not-much:

many sacrifice USB 3)

Alternatively the CM4 has PCIe and an NVMe SSD can be used, if you have a suitable carrier board. NVMe boot is now supported:

there are starting to become available carrier boards with M.2 slots:

Oh, ignore all the above then :)

Theo

On Sun, 12 Dec 2021 19:55:40 -0000 (UTC), Martin Gregorie snipped-for-privacy@mydomain.invalid declaimed the following:

Are you sure about those units? I would suspect those are 1TB drives.

Even a minimal system (Pi-Star image, no X-window or similar overhead stuff) takes 2GB here, and my "scratch" R-Pi 3B+ has 8GB of a 14GB partition in use... My smallest accessible drive is a 1TB Seagate (I may have smaller/old drives in two or three housings in the basement).

pi@rpi3bplus-1:~$ df -h Filesystem Size Used Avail Use% Mounted on /dev/root 14G 8.0G 5.4G 60% / devtmpfs 436M 0 436M 0% /dev tmpfs 468M 0 468M 0% /dev/shm tmpfs 468M 6.4M 462M 2% /run tmpfs 5.0M 4.0K 5.0M 1% /run/lock tmpfs 468M 0 468M 0% /sys/fs/cgroup /dev/mmcblk0p1 253M 49M 204M 20% /boot tmpfs 94M 4.0K 94M 1% /run/user/1000 pi@rpi3bplus-1:~$

I'd suggest partitioning the 8TB disk to have a root partition. Essentially a copy of the root image on the SD card, then do what someone else said, change the cmdline.txt file to specify the uuid of this partition at the root file system.

Alter /etc/fstab to make /boot on the SD card to be mounted readonly. Don't mount anything alse on the SDcard by default.

If the power goes unexpectedly then as the SD card has no writes is won't get corrupted. THe root partition on the spinner will get dirty, but under most circumstances it won't be corrupted too badly. Disconnet plug into another linux box - run fsck to correct problems - return to pi and all should be ok.

My bad. Of COOURRRSE (cough..cough.. hawk, spit) they are 1TB

You dont and cant. Short answer, like for SD cards, only buy them from reputable sources.

I have a SanDisk 128 GB SSD in a Lenovo R16i which just sits there and does its thing: no problems after several years, the last two spent running protein folding software 24/7. Its original disk was a Hitachi

120GB HDD that failed at around the 37000 hours mark. So, it was either fit the SanDisk 128 GB SSD or junk the laptop because its disk interface hardware doesn't support disks of more than 200GB: I know that because it would not accept a 500GB WD drive and a search of its manual didn't show acceptable replacement disks of over 250GB and, by the time the Hitachi went titsup you couldn't buy a hard disk smaller than 320GB.

Excellent. rsyncing 'live' disks to a set of at least 2 offline backup disks, stored offline, preferably in a firesafe or other building is about as good as it gets.

Doesn't running fstrim effectively try and outguess the SSD's built in wear levelling?

Yes, that's certainly one possible way to go. I guess I can re-partition it to have the rootfs partition at 'the end' so it won't take for ever to do it.

It'll have to actually happen before one knows exactly how it will react but, as you say, it should be OK. Other (Linux) systems around here with spinnig disks have survived power failures without issues (as have the Pis actually).

My Pi failures have both 'just happened' not as a result of a power failure.

Exactly, the Pi 'NAS' that started this thread is in my garage which is a fair way away from the house. The wired ethernet connection is buried now (it used to be draped through the trees!). I do inremental backups of all my systems to the Pi backup system using rsync.

There's very little 'extra' software on the Pi NAS, it's "out of the box" Raspios Lite with just syncthing and postfix added so rebuilding from scratch is pretty trivial (but does take a bit of time).

If on all the time the DNS server could simply use RAM disk for all moving data.

If writing is why the SD is failing

No, it gives it the info needed to do a better job.

there are extention boards to attach hard drives - take one and put two SSDs into raid on the NAS. Configure the NAS to support FTP and use the other one diskless. The Pi4 boots well from FTP when EEPROM is written appropriately. The not Pi4 needs a small SDHC card (64 or 128MB) with the boot partition and config to boot from network. This can be unmounted after boot too.

Also there are Li-Ion batteries with power monitor that can be used as UPS