I have a load-bearing raspberry pi on my network - it runs a DNS server, zigbee2mqtt, unifi controller, and a restic rest server. This raspberry pi, as is tradition, boots from a microSD card. As we all know, microSD cards suck a little bit and die pretty often; I’ve personally had this happen not all that long ago.

I’d like to keep a reasonably up-to-date hot spare ready, so when it does give up the ghost I can just swap them out and move on with my life. I can think of a few ways to accomplish this, but I’m not really sure what’s the best:

  • The simplest is probably cron + dd, but I’m worried about filesystem corruption from imaging a running system and could this also wear out the spare card?
  • recreate partition structure, create an fstab with new UUIDs, rsync everything else. Backups are incremental and we won’t get filesystem corruption, but we still aren’t taking a point-in-time backup which means data files could be inconsistent with each other. (honestly unlikely with the services I’m running.)
  • Migrate to BTRFS or ZFS, send/receive snapshots. This would be annoying to set up because I’d need to switch the rpi’s filesystem, but once done I think this might be the best option? We get incremental updates, point-in-time backups, and even rollback on the original card if I want it.

I’m thinking out loud a little bit here, but do y’all have any thoughts? I think I’m leaning towards ZFS or BTRFS.

    • FiveMacs
      link
      fedilink
      English
      191 month ago

      Or go balls to the wall and get one of these bad boys

        • Mac
          link
          fedilink
          English
          51 month ago

          I remember when businesses thought these would be all the rage

      • @trachesOP
        link
        English
        51 month ago

        lol raid1c10

  • LifeBandit666
    link
    fedilink
    English
    171 month ago

    I can’t remember the steps (they were simple though) but when my Home Assistant raspi SD card died, I bought a 128gb SSD from AliExpress and a usb-sata cable.

    I then did something to the pi that meant it can boot from the SSD, and flashed the SSD using Balenetcher or RUFUS or whatever (same program I was using to flash my SD cards basically).

    Then it was just a case of plugging in and turning it on.

    Runs exactly the same as with an SD card with less dying because SD cards aren’t meant for a lot of read/write but SSDs do.

    • @trachesOP
      link
      English
      71 month ago

      That’s true, just booting from an SSD would be a lot more reliable and simple.

  • @[email protected]
    link
    fedilink
    English
    6
    edit-2
    1 month ago

    Another option is to use Image File Utilities on the Pi to create an image backup. You can use cron + a bash script to create incremental backups using the tool (e.g., take a ‘fresh’ backup each month, with daily incremental backups in between). I mount a network ‘backup’ drive (a local NAS, but you could use anything) to save the image to so I can actually access it. Then, just use balena etcher to flash the backup iso in the event of a failure.

    • @[email protected]
      link
      fedilink
      English
      21 month ago

      I also use those, but (shame on me) I’ve never tested the backups. Have you ever restored such an image backup?

    • @trachesOP
      link
      English
      21 month ago

      Oh cool, this is exactly what I was looking for! Thanks :)

      • @[email protected]
        link
        fedilink
        English
        11 month ago

        Happy to help! There’s plenty of other options too (e.g., SSD) as folks mentioned, but this works well out of the box with no additional hardware. SD has been absolutely fine for my use (Pi-Hole), while still requiring maximum uptime so the family doesn’t riot if the internet is out.

  • Mellow
    link
    fedilink
    English
    6
    edit-2
    1 month ago

    I’ve had very bad luck with raspberry Pi’s and SDCards. They just don’t seem to last very long. I swapped to usb storage and things got somewhat better. I just had a usb drive die after 3 to 4 years of use. When I was still using SD it seemed like multiple times a year. Heat. Power loss, you can only punch holes in silicon so many times before it wears out. Whatever the reason.

    My approach for this is configuration backup not the entire os. I think this approach is better for when it’s time to upgrade the os or migrate to a new system.

    For my basic Pi running WireGuard and DNS, I keep an archive of documentation on steps to reconfigure the system after a total loss. Static configs are backed up once, and If there are critical configuration items that change then I back those up weekly. I’ve got two systems (media related servers, not Pi’s) that I keep ansible playbooks to configure 90% of the system from scratch so it’s as hands off as it can be.

    • Possibly linux
      link
      fedilink
      English
      21 month ago

      If you are killing SD cards you shouldn’t be using a raspberry pi. They aren’t exactly work horses

    • @trachesOP
      link
      English
      21 month ago

      Yeah, I’m getting a pretty strong consensus here that an SSD is the way to go. I’ve also had at least one SD card die on me, and because I didn’t have backups it was pretty inconvenient. Had to recreate my homeassistant setup from scratch.

      I get the config only backup, but when I have a mondohuge nas available and we’re dealing with like less than 100 gigs, why not just take a full disk image?

  • Noxy
    link
    fedilink
    English
    51 month ago

    I would ditch the SD cards entirely and boot off of USB attached SATA SSDs. But your idea still sounds cool if you can’t or don’t want to invest in SSDs!

    I’ve enjoyed btrfs on my laptops, definitely seems stable, and using BEES foe dedupe is rad (maybe don’t do that on an sd card tho…)

    • @trachesOP
      link
      English
      31 month ago

      I’ve also been using BTRFS for awhile, and recently I’ve been getting into zfs which IMO does a better job of handling large software raid arrays. They’re both pretty great!

  • @[email protected]
    link
    fedilink
    English
    5
    edit-2
    1 month ago

    I’ve always used dd + sshfs to backup the entire sd card daily at midnight to an ssh server; retaining 2 weeks of backups.

    Should the card die, I’ve just gotta write the last backup to a new card and pop it in. If that one’s not good, I’ve got 13 others I can try.

    I’ve only had to use it once and that went smoothly. I’ve tested half a dozen backups though and no issues there either.

      • @[email protected]
        link
        fedilink
        English
        6
        edit-2
        1 month ago

        Yeah “dd if=/dev/mmcblk0 of=$HOSTNAME.$(date +%Y.%m.%d).img” and while its running. (!!! Make sure the output is NOT going to the sd card you are backing up…)

        I deliberately chose a time when it’s not very active to perform the backup. Never had an issue, going on 6 years now.

  • Shadow
    link
    fedilink
    English
    41 month ago

    Why not just connect an ssd via USB and save yourself the hassle and torment?

    • Avid Amoeba
      link
      fedilink
      English
      11 month ago

      That wouldn’t solve the problem though would it? It might make it less likely to fail but there’s still significant downtime if there’s no hot spare for this USB drive.

      • Shadow
        link
        fedilink
        English
        3
        edit-2
        1 month ago

        I couldn’t count the number of failed sd cards I’ve seen across all my fingers and toes.

        I’ve seen like 4 ssds in my entire life fail. Plus you could just do mdraid 1 / btrfs across 2 of them if you want

        • Avid Amoeba
          link
          fedilink
          English
          0
          edit-2
          1 month ago

          Any failures of SanDisk Extreme Pro / Samsung Evo Plus?

          I buy the redundancy argument. I’d still use ZFS for that if possible though. 😂 All my machines use mdraid 1 for their system drives but now that I know enough about ZFS, I’d likely use it on root next time around.

          • Shadow
            link
            fedilink
            English
            31 month ago

            Yes. I’ve always splurged on nice cards for my personal stuff. I think it’s more about the write behavior of Linux than anything else, since I’ve never had a card die in my camera.

            I refuse to use a pi with SD at this point. Saving $50 isn’t worth my time to reinstall things.

            • Avid Amoeba
              link
              fedilink
              English
              1
              edit-2
              1 month ago

              You’re making me nervous.

              But then again, all my Pis are OpenWrt now which barely writes, so I’m probably fine. 😅

  • @[email protected]
    link
    fedilink
    English
    31 month ago

    Why not just buy a good SD card? My dashcam has been recording ~16/5 for the past 3 years onto a Sandisk extreme dashcam SD card and it’s still going strong with no issues. If it can survive the extreme heat and cold of being in a car I’m sure it will survive in a Pi just fine.

    All of my SD cards that have failed have been bargain brand cards. None of my high quality ones have failed on me, I lose them before they go bad.

    • @trachesOP
      link
      English
      31 month ago

      I have a decent Samsung card in there now, it might survive. Can’t remember what brand the one that failed was, but I don’t tend to buy crappy ones

      • @[email protected]
        link
        fedilink
        English
        31 month ago

        Which cards are you using? Just because it’s samsung doesn’t mean it’s good.

        My dashcam uses mostly this “SanDisk 256GB High Endurance Video” SD card, and my backup is a 512gb Samsung Pro Plus (not rated for dashcam use). For anything that I want reliability I use one of these SanDisk cards, that Samsung, or a SanDisk extreme that I bought the other day. My “I don’t really care about this, but I’d like it to not fail” cards are Samsung Evo Select drives (or something green and Samsung). Only my “I really don’t give a shit about these” drives are those $3 Microcenter cards.

  • @sugar_in_your_tea
    link
    English
    31 month ago

    Do you need a backup image?

    For my NAS, all I do is:

    • keep notes of what’s installed and how to configure OS things
    • automatic, offsite backups of important configs and data

    Any full-disk backups just make the restore process easier, they’re hardly the primary plan. If you want that, just take a manual backup like once a year, and maybe swap them out every 2-3 years (or however long you think the SD card should last). If you keep writes down, it should last quite a while (and nothing in your use-case seems write-heavy).

    But honestly, you should always have a manual backup strategy in case something terrible happens (e.g. your house burns down). Make that your primary strategy, and hot spares would just be a time-saver for the more common case where HW fails.

    • @trachesOP
      link
      English
      31 month ago

      Well, this is my DNS server which means if it’s down the internet is down and I can’t resolve hostnames to ssh into. I know that can be worked around, but I’d really like a quick and easy fix that I could even talk someone through over the phone if I had to.

      My real backups are squared away, no worries. Nightly automatic restic snapshots, one to an external drive on this very pi and another to a NAS at my parents’ house.

      • @sugar_in_your_tea
        link
        English
        2
        edit-2
        1 month ago

        I ended up making my router my DNS server, so if my router goes down, the internet is down anyway. I have static routes for things on my LAN, so if I hit mydomain.com, I can route it to an internal address instead of going over the internet. So far it works pretty well.

        That said, I don’t have a PiHole setup, so I don’t know if that complicates things (I’m guessing pointing the router at the PiHole with a fallback to external DNS would just show ads or whatever if the PiHole is down).

        But yeah, having a quick fallback is important. I think that should be as automatic as possible.

        • @trachesOP
          link
          English
          1
          edit-2
          1 month ago

          I like the DNS on the router idea, I’ll look into it. I do have some split DNS set up as well as adblocking lists (technitium). Not sure what my router can do.

          Edit: autocorrect got me

          • @sugar_in_your_tea
            link
            English
            21 month ago

            I think most can do it (esp. if you flash something like OpenWRT), but I have an entry-level enterprise router from Mikrotik and that’s a pretty standard feature on that tier.

  • @[email protected]B
    link
    fedilink
    English
    2
    edit-2
    1 month ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    DNS Domain Name Service/System
    LVM (Linux) Logical Volume Manager for filesystem mapping
    NAS Network-Attached Storage
    PiHole Network-wide ad-blocker (DNS sinkhole)
    RAID Redundant Array of Independent Disks for mass storage
    SATA Serial AT Attachment interface for mass storage
    SSD Solid State Drive mass storage
    ZFS Solaris/Linux filesystem focusing on data integrity

    8 acronyms in this thread; the most compressed thread commented on today has 6 acronyms.

    [Thread #911 for this sub, first seen 8th Aug 2024, 15:25] [FAQ] [Full list] [Contact] [Source code]

  • Avid Amoeba
    link
    fedilink
    English
    2
    edit-2
    1 month ago

    Perhaps the best answer by far is ZFS but I don’t know how much pain it is to set it up to boot from on a Pi. The easiest to setup is probably LVM.

    With ZFS you can trivially keep a hot spare even over the network. Just tell syncoid where to replicate.

      • Avid Amoeba
        link
        fedilink
        English
        3
        edit-2
        1 month ago

        I used it on a Pi 4 in 2019 for an USB-connected mirror and it worked well. Unencrypted throughput was upwards from 200MB/s. Encrypted throughput dropped down to under 100MB/s due to insufficient compute. The Pi 4 is a powerful computer and the Pi 5 even more so. Pi 3 and older, not so much.

        • @trachesOP
          link
          English
          21 month ago

          It’s a 4gb pi4, think it could boot from ZFS?

          • Possibly linux
            link
            fedilink
            English
            41 month ago

            You could boot from from an SD and then store data on a external drive. I would go Btrfs over ZFS unless you have at least 3 or more disks

          • Avid Amoeba
            link
            fedilink
            English
            11 month ago

            I would try it. My only issue is I have no idea how to set it up on root on a Pi. Perhaps there’s docs somewhere. If had to setup a new Pi with Pi OS/Debian/Ubuntu today I’d definitely try it. Most of my Pis are running OpenWrt though.

      • @trachesOP
        link
        English
        11 month ago

        Performance is all but irrelevant in this case

        • Possibly linux
          link
          fedilink
          English
          11 month ago

          You say that but when the system starts to lock up you might change your tune

          • Avid Amoeba
            link
            fedilink
            English
            1
            edit-2
            1 month ago

            Why would it lock up? ZFS will use as much RAM as you give it and it doesn’t seem CPU-bound unless you turn on encryption. It’s not a cluster FS like Ceph. Why do you expect ZFS to lock up and Btrfs not to?

  • @[email protected]
    link
    fedilink
    English
    2
    edit-2
    1 month ago

    Get a USB to SATA cable. This one works great with the Pi: https://a.co/d/8Jv2Erj

    Instead of having a warm spare, a better solution is to attach two drives and use them in a RAID1 config. Unfortunately, I don’t think the Pi supports RAID1.

    • @[email protected]
      link
      fedilink
      English
      21 month ago

      Unfortunately, I don’t think the Pi supports RAID1.

      I haven’t ran any Pi with hard drives, but I don’t see any reason why it wouldn’t work with software raid on linux.

      • @[email protected]
        link
        fedilink
        English
        1
        edit-2
        1 month ago

        The issue is that I don’t think its standard bootloader supports booting from RAID. I guess you could use a MicroSD for booting then have everything else on the RAID1. There’s unofficial ways to boot using GRUB, which should work with RAID1 too.

        • @[email protected]
          link
          fedilink
          English
          21 month ago

          Grub supports software raid just fine. The main issue is that you need to modify grub configuration to add bootloader on both drives, but even if you don’t it’s pretty simple to recreate needed files for second drive when the primary one dies.

          • @[email protected]
            link
            fedilink
            English
            21 month ago

            GRUB does, but Raspberry Pis don’t use GRUB by default. You should be able to install it, but it’s not officially supported.

  • Possibly linux
    link
    fedilink
    English
    01 month ago

    Why are you using a MicroSD at all? Get a used minipc with two sata ssds or a single board computer with eMMC or mpcie support

    • @trachesOP
      link
      English
      41 month ago

      Yeah, I definitely won’t be buying a new pi anytime soon for exactly that reason but I’ve had this one for awhile and would prefer to do something useful with it.

      • Avid Amoeba
        link
        fedilink
        English
        3
        edit-2
        1 month ago

        BTW in my anecdata I’ve yet to have a failure on any of my SanDisk Extreme Pro SD cards. I have 4 in active use on different Pi 4s. The oldest one is in use since 2018-ish. It used to be a NAS till 2022 so roughly 3-4 years of 24/7 use with a bog-standard OS. It’s now running OpenWrt which does fewer writes.