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.

  • Noxy@yiffit.netEnglish
    5·
    3 months 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…)

    • traches@sh.itjust.worksOPEnglish
      3·
      3 months 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!