SD CARD Backup

I read about the most convoluted ways to back up SBC systems…. some back up only data, some use arcane commands to do the job – few if any are a single click job for a complete backup that can even handle larger or smaller SDs.

Except for Raspberry Pi SD Backup.


I don’t know how many of you are familiar with this but I have a number of Raspberry Pi 2 and 3 units and as well as liking to keep regular backups, I like to have snapshots before I try something new – one of my main machines is in Spain, currently a long way away and the other is in the house, away from my office.

In Raspbian from the GUI you simply go to accessories, SD card backup and press a button to back everything up to an SD card that has enough room to store everything. This card can be put in another Pi and will run – every single time I’ve done this it has worked with no data loss even though the Pis are actually running as I’m backing things up.

So two things for any budding wizards out there…

1. I cannot find a way to schedule this from the command line – it seems it only runs in the GUI

2. Why can’t other systems do this – for example Armbian?  Now, The so called Raspbian for the Orange Pi has the same feature but it DOES NOT WORK – I doubt anyone uses their software anyway because Armbian is better by some way… but really – simple backups means more experimenting means greater innovation, fewer heart attacks. PLEASE someone tell me I’ve missed something that does the job (and please don’t mention DD and other convoluted data only or multi-part solutions – I’m talking about a single command that makes a duplicate SD even if it is larger or smaller – that works without issue…

If Raspberry Pi people can do it – why can’t others, I wonder?


28 thoughts on “SD CARD Backup

  1. For a full SD card backup, you should be able to do a regular backup using dd for the whole SD card to an NFS or SAMBA server, and schedule it as a cron job on any Linux SBC.

    A script like:
    sudo mount nfs_server_ip:/nfs /mnt/nfs
    sudo dd if=/dev/mmcblock0 of=/mnt/nfs/opi-backup.img
    sudo umount /mnt/nfs

    You'd probably want something more fancy with the date in the backup file name.

    Then call this script from a cron job. Plenty of info on the web to set this up.

    1. I guess my blog title was a bit misleading... it isn't backup I'm after it is replication. preferably to another size SD... so that if the system fails I can replace the SD quickly. I can't by any means be the only one that needs to do this (any SBC-based home control setup).

  2. Two things: Raspberries boot completely differently, here no u-boot is involved, it's enough to create a FAT16/FAT32 partition of appropriate size and copy some files there. And then a second ext4 partition will be created and most probably the data copied over there with rsync. No need to deal with a sophisticated boot loader since booting is done on the proprietary VideoCore IV.

    Second and more important thing: it can NOT work reliably. Period. You can't clone a live system without active measures (do a google search for eg. Volume Shadow Copy Service (VSS) to get the idea what an OS has to provide to allow applications to save stuff in a consistent state to the file system). It's really that easy and since Armbian was more or less focused on server usage not that long ago and we don't want to fool our users we don't provide such a thing.

    Your argumentation "Never something went wrong" is like someone jumping from a skyscraper, passing 10th floor and claiming "Nothing happened so far, told you so!"

    To be honest: In Armbian we have an utility called nand_sata_install that does basically all the stuff 'SD card copier' does but compatible with u-boot setup on all the 40 SBC we support. But it's intended to move installations from SD card to NAND/SATA/USB/eMMC (not the other way around), it's assumed that this process happens pretty early (so not that much can go wrong) and we still don't want to fool our users so we don't advertise this as 'general purpose backup tool'.

    Again, it can't work reliably, that's the unfortunate thruth -- simply check lsof output (lsof == list open files). It might work with 99.99% of SBC installations but the 0.01% missing is a problem (of course not for RPi foundation, if there something goes wrong then they tell their users: it's your SD card's fault, start over from scratch)

    1. Having seen your writings elsewhere Tkeiser I'm not about to start an argument as I suspect I'd lose.. however, for the record - "up to now" - many dozens of transfers from one SD to another, as far as I'm aware, never lost a thing.

      Meanwhile, I have a FriendlyArm working installation of Android - home media etc etc.. and it is on a 32GB SD. All of my SDs are 16GB... I just have no sensible way to replicate this on a second machine that I know of... without ignoring my big pile of 16GB SDs and ordering another 32GB.. just seems daft.

      1. Pete, the problem are 'open files'. Imagine you run a database: then the state on disk does not necessarily reflect the internal state of the database. You would've to force the database to do a flush on disk first. But if you forget to do that and then start cloning your live system and chose a database that does flush to disk from time to time then you might realize probably way too late that you simply missed the last changes in your database.

        Even web browsers use databases (the heavy ones all have a few SQLite databases open to store history, places, whatever) but some programs deal better than others with the situation that such a file got corrupted (as the result of cloning a live system).

        It's a challenge to clone a live system, it will work most of the times and the inconsistencies that occur for sure from time to time are in most cases negligible. But also real data loss can occur and the traditional Armbian user base uses different services than IoT and such stuff. So we have to be extremely careful.

        Since we have nearly all the stuff ready we already thought about a '100 percent safe' approach. That could be a 2nd booting option (compare with NOOBS) that brings up a small system that is then able to clone the system to another media (since then all services are shut down and all files are closed this will work every time). But we're not there unfortunately.

        In the meantime we tried to ease offline cloning. As everyone knows 2 16 GB SD cards 'of same size' differ in reality by a few sectors. So recent Armbian images do not use the whole capacity of a freshly used card but leave some spare area. This way you can clone an installation from one 16 GB card to another even if the latter is smaller in size. We also provide a tool to boot H3 devices through USB to access the internal eMMC so this can also be cloned offline.

        But this is still WiP and what we will never do for sure is fooling our users and tell them things that can not work 100 percent reliable would work. SD card copier is a 99.99% solution which is simply 0.01% less to be useable by the whole Armbian target audience (we've a lot of users that rely on Armbian for server stuff on heavier devices than these small H3 gems)

    2. Ahah...TKaiser - so a somewhat unrelated question.. I have a Nanopi NEO Air with a perfect working Armbian installation on SD... 8GB SD... and that board has eMMC on it... I was wondering how to transfer the lot over to the eMMC.... care to enlighten??

        1. I did - found it (as I'm impatient) earlier - and ran it - and I now have a working NEO Air on eMMC which means I can set the other one up the same and claim back my SDs - MARVELOUS!! So best of both worlds - keep a master on SD (easy to back up to PC), clone to units.

        2. Comment and question. Ok, done one transfer to eMMC - doing second - working perfectly up to now.

          Notes: when you start, 2 things come to view.. firstly the very nice menu ends up as a bunch of ASCII characters when using WinSCP - which calls PUTTY for a terminal - any way to permanently fix that? - I've seen this before - should be nice lines - appreciate it isn't the lib you're using it's most likely Putty... secondly - while working - the first thing you see are two warnings about invalid disk labels... just to let you know.

          However, it does seem to actually work well. Oh, NanoPi Air - just updated the blog - used that tool to create two working boards from the original SD. I'm SURE they're faster...

          1. Sorry, can't help with Windows problems (I switched to alternatives prior to release of Windows 95).

            And then such a cloning process (one installation to many devices) might have some drawbacks: MAC addresses. This might affect Ethernet, WiFi and BT! We have some devices currently where drivers generate MAC adresses not by a unique ID (and on those small boards most of the time no EEPROM is present to store a manufacturer's MAC address).

            So now you might run into trouble due to duplicate MAC addresses. Don't know whether this here is really the case (AP6212) so just as a warning.

            At least there's some hope if we can convince board manufacturers to follow Xunlong's example: They listened to linux-sunxi community and start with OPi Zero and PC 2 to provide SPI NOR flash on the boards:

            Unfortunately it's optional on OPi Zero now but if we can convince more board vendors (FA for example!) to solder 8 Mb SPI NOR flash (costs literally nothing) by default then stuff like MAC addresses could be stored there and also the bootloader. My ultimate goal is to netboot a bunch of OPi Zero and power them also through PoE (see link above). This will add 3 bucks for a step-down converter to the 7 bucks for an OPi Zero -- no SD cards needed any more!

            Netbooting also eases the 'backup/clone' problem since all boards start from one central rootfs shared via NFS so snapshots can be done in a central location 🙂

          2. And yes, onboard eMMC is faster than the average SD card, especially random IO is magnitudes faster unless you buy Samsung EVO/EVO+/Pro or SanDisk Extreme Pro/Plus. There's a huge thread in Armbian 'Free' forum with test results for a variety of SD cards and eMMC.

            It's almost a shame how many 'good brands' show horribly low random IO performance (especially those recommended like Kingston)

            1. Thanks for the feedback TKaiser... and for clarity for the benefit of ohers - I've been through this whole SD thing - I would not DREAM of using anything less than Sandisk Pro or Samsung EVO - both of which have served me very well (flawlessly) up to now - the only reason I don't use the higher up ones is cost. Both of these are quite cheap on Amazon. I'll take a look at the Armbian forum results. I read such results a while back and Samsung and Sandisk both did well.

              1. I would not buy any SD cards from untrusted vendors: you see, these are very easy to counterfeit, and you can get a high margin... Too tempting for many Chinese online vendors, including on Amazon.

                1. I wonder if it it possible to test, say one sector to destruction to see if you have a duffer or not... but then if the chip has level wearing - I'm guessing that would get in the way of testing.

                  1. SD cards can be tested and should ALWAYS be tested DIRECTLY after purchase:

                    And you've to test every card, never trust in 'brands'. Currently in Armbian forum someone spotted counterfeit Samsung EVOs simply by testing performance (they were ok regarding capacity but obviously using a crappy controller chip).

                    If they have a horribly low random IO performance then they're not genuine and if you're lucky enough that sequential speeds don't match the 'speed class' you can immediately return them.

                    1. Excellent info -thank you. Sadly one program is Linux (unless you use Cygwin) the other is latest Windows 7 and appears to be in German. Any advance on SD testers guys - Windows in English would be nice?

    3. Quick question TKaiser - that nand_sata_install program works a treat on the Air - now have two AIRS running all my stuff from the original SD.. but... I kind of assumed that if you left the SD in, the Air would run from SD - and if you took it out - it would run of the internal eMMC.. but it is running off the internal eMMC even with the SD in... I don't suppose you know better? Any trick to get it to run the SD if wanted??

      1. SD card should have higher boot priority than eMMC but the SD card must then have a so called 'SPL signature' on it. In case you didn't clear the signature SD card should 'win', at least that was the case in all my tests.

        1. I was doing well until ou mentioned "SPL signature" . I would not know if I've cleared it as I don't know what it is. "Shared Parental Leave" as Google put it... Well, my SD is definitely not taking priority - any leads as to how to fix that would be appreciated.

  3. Can't agree more with @tkaiser... Doing live backups on a system with changing open files will certainly lead you to problems. The only way is to perform backups on a stopped system like suggested above, or to be able to take a "snapshot" of your live filesystem.

    1. Absolutely understand the issues - but for example if remote systems which are up all the time go down, 99% chance of recovery by SD swap is a lot better than none.. expecially when a long way away. Fully understand the open files issue - and to be honest had really expected issues with Pi - but not seen any despite a lot of copies...

      1. You just got lucky... Or more presumably, you don't have much activity going on with critical opened files, probably only logs... You can check with lsof. But gamble with some serious stuff like a database with random access, and you'll probably loose!

        Look for "linux snapshots" in Google, and choose the solution that you prefer based upon your requirements, knowledge and available time. You can find some tools that can be fully automated and even some that can be launched over ssh remotely.

        1. Yes but I just keep getting lucky - over and over and over again. I'm sitting here now with a backup of the entire house system - as the old backup was getting long in the tooth. I'm changing the domain name so I can run both together - I've checked the SQLITE database - once again everything is fine - of course- I'd be stupid not to take notice of people here... it is obvious that an open file could end up losing data... but I've done this many times on the Pi and so far, so good.

  4. Pete, it's not a problem for the backup writers - it's more do do with the operating system and the right way to go about archiving. Tkaiser's comment pointed out the OS issue quite well I think.

    I guess the thing to remember is that these tiny linux-based boards are actually running complex multi-process, multi-user workloads - and that means that to back them up properly, one needs to reach for good old-fashioned methods to archive them. In the end this means it's not really about archiving "at an early stage", the "right" way is to move the system to "single user" mode, and then archive. Unix was designed to work this way (and linux is a sort-of-clone). In single user mode, the system won't be running other services, so you can archive happily.

    Another way to solve your problem it is to have a script that stops the services that have data that you want to protect, then archive their data, and then restart the services. This is the classic way to do it and can be done from a cron job each night... A similar script could then be used to restore the data to a "virgin" SD card if something does break. Take at look at how the "emonpi" guys do their stuff - they have an archive / restore script that works quite well.

    Reach out if you would like to chat about this.


Leave a Reply

Your email address will not be published. Required fields are marked *