Just about every Raspberry Pi I used suffered the same fate: the micro SD card died. It is generally accepted that the expected lifespan of an SD card is around ten years of normal use.

What’s “normal” use for an SD card? It is re-writable storage medium introduced in 1999 as an improvement over MultiMediaCard (MMC). The primary purpose of the SD standard was the same as that of the MMC: to store digital photos, videos, and audio recordings.

As any flash memory media, the individually erasable segments of an SD card can be put through a limited number of erase cycles before becoming unreliable. When you pop an SD card into your digital camera you will be mostly writing to it. Erasing data from the card will be a relatively rare operation.

Running an operating system off an SD card is an entirely different scenario. Depending on what exactly you’re doing with the OS, erase operations may be very frequent, shortening the lifespan of the card. It may last you several months, maybe a couple of years, but certainly nowhere near ten years. And then it will die without warning.

Backing up just the files on a Raspberry Pi is no different than running a backup on any other Linux box. You can try the excellent rsync-time-backup tool as a very time- and space-efficient backup solution. However, when the SD card does give out, you will need to reinstall the entire OS, configure it, and only then you can restore certain data from the backup. This can be a lot of work.

A very basic stand-alone SD card 1-to-2 duplicator may set you back around $150

A much easier solution is to power down the Pi, pull the SD card, and clone it with a PC or some stand-alone SD duplicator. The obvious problem with this approach is its extreme inconvenience. You may do this once or twice and then you’ll give up, ending up with an entirely outdated and nearly useless backup in time of need.

You can use dd from command line to create a file containing the image of your SD card on locally- or network-attached storage. Syntax is fairly simple:

# Create the image file
sudo dd bs=4M if=/dev/mmcblk0 | gzip > /mnt/destination/$(hostname)_image_$(date +%Y-%m-%d).gz

You can later use the latest image file to re-image a new SD card, should the old one kick the bucket.

Newer Pi models offer USB 3 ports, so you should take advantage of fast USB readers for micro SD cards

For about ten bucks you can get a USB micro SD card reader (these gadgets are often included with various Raspberry Pi kits) and use the dd command to clone the active SD card to the one connected via the USB reader.

# You need to double-check that /dev/sda is indeed the correct address
# containing the USB reader with your backup SD card
sudo su -
touch /boot/forcefsck
dd if=/dev/mmcblk0 of=/dev/sda bs=1M 
/bin/rm -f /boot/forcefsck

Since your Raspberry Pi is active when the dd process is running, the resulting image will be somewhat inconsistent – fuzzy, as they say. Running touch /boot/forcefsck will force filesystem integrity check should you ever boot from the backup SD card.

Instead of mucking about with dd, I would recommend using the rpi-clone script. Here’s how I installed it:

sudo su -
cd ~
git clone https://github.com/billw2/rpi-clone
cd rpi-clone/
/bin/cp rpi-clone rpi-clone-setup /usr/local/sbin

And here’s how I run it:

sudo su -
t=sda
umount -f $(egrep "^/dev/${t}([0-9]{1,})?" /etc/mtab | awk '{print $2}') 2>/dev/null
cd ~ && nohup rpi-clone -u ${t} &

You will need to set the correct target device – t=sda in my case. This is the USB micro SD card reader. The umount command is there to make sure that the target device is not mounted, as USB storage is often auto-mounted when it is inserted or when the system is rebooted. The -u switch allows for unattended backup. You can check on the progress by tailing /root/nohup.out file.

You can easily put these commands in a little script and run it from root cron as often as you like. I would suggest scheduling this overnight once a week and supplementing this process with the rsync-time-backup I mentioned above.

#/bin/bash
t=sda 
umount -f $(egrep "^/dev/${t}([0-9]{1,})?" /etc/mtab | awk '{print $2}') 2>/dev/null 
cd /root
nohup /usr/local/sbin/rpi-clone -u ${t} &

The restore process is as simple as shutting down the Pi and replacing the failed SD card with the one contained in the USB card reader. You may notice that initial boot-up is taking longer than usual. Don’t panic – it is likely that fsck is running to ensure integrity of the filesystem.

Since the best backup option seems to be SD-to-SD cloning, this is probably a good time to say a few words about selecting the right micro SD cards. The Pi 4 supports up to DDR50 (max bandwidth: 50MB/s) transfer mode and you are looking for an A1 card that offers the best random access (IOPS) performance.

The A1 specification offers random read of up to 1500 IOPS and random write of up to 500 IOPS. The A2 class offers random read of up to 4000 IOPS and random write of up to 2000 IOPS. At the time of this writing, Pi 4B does not yet support A2, however, this may change in the near future with the release of new firmware.

I am using SanDisk Extreme Plus 32 GB Class 10 UHS-I U1/U3 micro SD cards that sell for less than ten bucks. This is the same card you would get with most popular Pi kits, like the CanaKit.

No matter how you look at it, SD card performance is what’s making even the Pi 4 with four cores and as many gigabytes of RAM appear sluggish at times. Overclocking is not recommended and will not result in substantial performance improvement. What you need is a faster system disk. Unlike the previous Pi versions, Pi 4 cannot boot directly from USB. You will still need the SD card that will redirect the boot process to the SSD.

Sandisk Extreme Pro Micro SDXC

You have a couple of options here: you can either buy a high-performance USB 3 micro SD reader with an equally decent SD card (a good example would be Sandisk Extreme Pro Micro SDXC that will set you back around sixty bucks for the 64-GB model); or you can get an SSD SATA expansion board (around $30) and an mSATA internal SSD (also round $30 for 120GB model). And here’s a good set of instructions for making it all work.

In terms of performance increase, either a USB 3 micro SD adapter or the mSATA expansion board will make a dramatic difference. But you also need to think about your backup options. If you go the USB 3 micro SD route, you will need to double up on those so you can do your SD cloning. And these readers and cards aren’t cheap.

If you go with mSATA SSD, a setup for cloning the disk will be even more complex and pricey. On the other hand, an SSD, unlike micro SD, is actually designed to run in computers and offers a lot more stability and longevity in this role.

P.S. No more than two seconds after I pushed the “Publish” button on this post, a momentary electrical outage fried the power supply in one of my NASes. I already ordered a replacement, but for a few days I will need to find a new destination for my own backups. So there you go, backups are important because shit happens.