SD CARD Backup

Update September 2018

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. That is except for RPI-Clone.

Below “Original article” was written back in 2016 – things have changed a little since then. Bill Wilson has revamped his rpi-clone project and the current version of this superb command-line tool for the Raspberry Pi is here.. https://github.com/billw2/rpi-clone

I cannot overstate how useful rpi-clone is. I use it to back up my Raspberry Pi projects (Pi2 and Pi3).  I have used this at the command line (no  need for the graphical environment, keyboard, screen etc, I simply ssh into the board as user Pi). Typically if I am unsure of the status of an SD card used for backup, I use this:

sudo rpi-clone sda –f –U

If on the other hand I’ve already made a backup to that card in the past and hence the partition structure is guaranteed:

sudo rpi-clone  sda –U

the –f option forces the program to initialise the card – and hence this backup may take some time. In the second method above, only incremental changes are made and hence a backup may take as little as a few minutes. MAGIC.

I’ve done this dozens of times on a live board without issue. –U simply means Unattended so the backup operates without asking questions and with only minimal output. Of course, there is always the possibility of losing live data, but as far as I’m, aware, I’ve not lost anything to date.

The challenge now is to get this to work with Orange Pi Plus 2E, however, despite the SD copy showing no obvious errors, I have had no joy yet here – I don’t think the copying is working on the first partitions (OP is different to RPI). I have Stretch running on the OPI +2E and it works a treat on the eMMC – however I have another OPI +2E with  very much updated code and need to back that up to the other board. The difference between easy backups or not decides if this board is of any use. Right now the Raspberry Pi wins hands down because of the backup facility despite the board being no-where near as powerful as the OPI +2E.

Original article

Raspberry Pi SD Backup

SD Card 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?

Facebooktwittergoogle_pluspinterestlinkedin

37 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: http://linux-sunxi.org/Xunlong_Orange_Pi_Zero#Tips.2C_Tricks.2C_Caveats

            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: https://docs.armbian.com/User-Guide_Getting-Started/#how-to-prepare-a-sd-card

                    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.

    4. Whatever our views on backup it seems clear you know more about the subject than me - so - question... Orange Pi +2E.... rpi=clone LOOKS like it works with this - the Author uses it on non-Pi systems as well,

      Using the -f -U options I originslly attempted to backup from +2E eMMC to SD in a usb holder and failed. It LOOKED like something was there but it would not boot. I've now tried with Xenial on SD - again cloning to SD in a card holder (ie SDA) - it LOOKS fine - but again won't boot.

      eMMC has mmcblk1 and on the eMMC is mmcblk1boot0, mmcblk1boot1 and mmcblk1p1, whereas the working SD original seems only to have mmcblk0p1 on mmcblk0 - odd... I don't understand where the boot partition ison the SD version. The clone I made of the SD on an SD in usb container ie SDA ie as follows.. sda is there again apparently with only SDA1... somehow even if not FAT I was expecting 2 partitions...

      1. I don't know why the author thinks it should work since I looked at his script and it clearly can not work on anything else than a Raspberry since he does neither care for u-boot nor SPL (secondary boot loader).

        Both u-boot and SPL do not live inside partitions or filesystems but are written with dd at the start of the media prior to the partition table.

        So rpi-clone might work if the target is an SD card or eMMC where an OS image containing u-boot+SPL has been already written to earlier. But it clearly lacks any ability to get anything else than RPi/VideoCore images bootable since it simply forgets about the most important thing called the bootloader on *real* ARM boards.

        In Armbian we have a tool called nand-sata-install to transfer images from SD card to eMMC, USB, SATA or NVMe: https://github.com/armbian/build/blob/master/packages/bsp/common/usr/sbin/nand-sata-install

        Our tools makes the target media bootable but this is not part of the script itself but of a generic Armbian part called /usr/lib/u-boot/platform_install.sh

        Since each and every ARM SoC family on this planet does it differently so you can't come up with one routine that is able to boot any SBC out there. They're all incompatible and what we've done in Armbian is collecting the knowledge and the code to deal at least with the SoC families we support.

        Also rpi-clone author might look at the StopRunningServices() function and that we call rsync twice. Since it's IMPOSSIBLE to cleanly clone open files. It's IMPOSSIBLE and it doesn't change much that an awful lot of people believe into the opposite.

        In my day job I deal with customers who believed into 'cloning a running system' being possible, telling you it worked all the time but suddenly not. Reality is: it's IMPOSSIBLE to do this reliably without special precautions. So time for some paid consultancy for the poor customer to recover from a broken system. I really don't feel comfortable promoting IT attempts that can't reliably work (like cloning a live system without something like database dumps, snapshots or Volume Shadow Copy Service on Windows)

  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.

    cheers
    Jason

    1. 2 years later and I'm still reliably duplicating Raspbian (now Stretch) using SD CARD Backup.... no problems. Meanwhile still no way to do this that I'm aware of (easily) on non-Pi machines.

      I just did three RPI3 boards and an RPI2, all armed with Node-RED and lots of other software.

      Easy backup or lack of it could well be a deciding factor in my future choice of devices.

      1. About 6 months ago I switched to store my RPI data on iSCSI with Synology NAS, and I love it. (I think almost any NAS comes with an iSCSI option)
        SSD RAID1 (Samsung 10 Years warranty), keep auto backups for every day for a month.
        If something goes wrong I can restore the whole image in 10-15 minutes remotely (no swapping SDCARD required )

        Here is the original article:
        https://www.berryterminal.com/doku.php/storing_your_files_on_a_synology_nas_using_iscsi

        1. I'll investigate that when I get back to the UK next month. I normally have a Synology NAS running 24-7 which would do the job, but as we moved house, there is no broadband there yet. Great.
          Wish I sould solve the Orange Pi problem sas they are great boards eith eMMC but that's essentially uselesss without easy backup.

  5. Right, not sure if this is really related to this but I am switching to SSD's on my pi's after having to much wear out issues. I bought a USB to mSATA adapter ($7) and a 32GB mSATA SSD ($14) from Aliexpress and followed the raspberry pi org article on how to boot from a USB device and that's it.

    Downside: This setup is slow to boot so you still need an SD card with bootcode.bin on it. But since that is the only file on the SDcard and read only it should not present any wear issues anymore. Once running there is no slowness that I can notice.

    This setup has been running for a month now on 2 of my pi's. I have ordered two more sets to do my other pi's as well 🙂

    P.S.: Didn't want to spam here but I can get you the links if you want.

    1. share links is always good, let us know what you bought 🙂

      anyway, my rpi3 is booting from usb with NO sd card in it at all... following info on raspberry site... you just need to modify the firmware as advertised (once and forever), and then modify the root device in your config.txt file if i remember well

  6. Ah, okay 🙂
    USB to mSATA https://bit.ly/2O7MxmK
    mSATA disk (various sizes) https://bit.ly/2qa6gZq

    I tried booting without SD card but the above disc and/or USB converter seems to boot too slow. From raspberrypi.org: "See this blog post (https://bit.ly/2O7Nag6) from Gordon Hollingworth for an explanation of why some USB mass storage devices don't work...". In the comments below that post there seem to be offered two options, one to enlarge a time out parameter and the other with an SD card containing only bootcode.bin. As I couldn't work out how to get the time out changed (not enough patience nor intelligence) I chose the latter. Since booting is needed scarcely and that SD card would be collecting dust from now on anyway, I don't mind using it for this purpose. Nevertheless, if you now how to extend that time out, please tell me 🙂

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.