Nightly Backup Rsync Errors

[mokanman]

I was hoping to use the same type of backups for my Armbian Minecraft Server as I currently use for my RASPBX system which uses Raspbian on a Raspberry Pi 3 and sucessfully updates a backup of the entire SD card every night.  I successfully modified and ported the RASPBX-BACKUP script to other Raspberry Pi's I have that are fulfilling other tasks and they also make backups just fine.  The are also running Raspbian.  I ported to my Le Potato running Armbian and when I try to run the initial backup it chokes with the following errors:

rsync: symlink "/media/bkup/boot/dtb" -> "dtb-4.14.52-meson64" failed: Operation not permitted (1)
rsync: symlink "/media/bkup/boot/uInitrd" -> "uInitrd-4.14.52-meson64" failed: Operation not permitted (1)
rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1196) [sender=3.1.2]
Error running backups.

I'm pretty sure these lines from the script are the offending code:

  rsync -aDH --partial --numeric-ids --delete --force --exclude '/dev' --exclude '/media' --exclude '/mnt' --exclude '/proc' --exclude '/run' --exclude '/sys' --exclude '/tmp' --exclude 'lost\+found' --exclude '/etc/udev/rules.d/70-persistent-net.rules' / ${MOUNTPATH}/
  if [ $? -ne 0 ]
  then
    echo "Error running backups."
    unmount_image
    delete_lo
    exit 1
  fi

Not being that familiar with what I'm doing it is likely that the problem is obvious (just not to me).  It may relate to the difference between the hardware or more likely the difference in the operating systems.  Anyone have a suggestion of how or where to debug this puppy?

[Igor]

7 hours ago, mokanman said:

Anyone have a suggestion

Try adding --keep-dirlinks parameter.

[tkaiser]

10 hours ago, mokanman said:

They are also running Raspbian.

 

That's irrelevant. They're all running ThreadX (that's bootcode.bin and the start*.elf stuff that has to reside on the 1st partition of the SD card that has to be FAT formatted since otherwise the VC4's primary bootloader can't load ThreadX). Raspberry Pis are no ARM SBC but VideoCore IV SBC (with badly integrated ARM cores that run a secondary OS, most of the times Linux).

 

The raspbx-backup script doesn't work with any SBC Armbian supports since it's designed for VideoCore SBC (that need a FAT partition with the closed source ThreadX on it). ARM SoCs work differently than VideoCore SoCs: here u-boot/SPL are written to the beginning of the SD card somewhere. It's not on a filesystem and therefore can't be copied with rsync that acts above the filesystem layer.

 

You can study how it's done per board family by checking the write_uboot_platform and uboot_custom_postprocess functions here: https://github.com/armbian/build/tree/master/config/sources (Le Potato is meson64)

 

TL;DR: ARM SBC are not VideoCore SBC and therefore tools that are designed to work with VC4 won't work on ARM SBC.

[mokanman]

9 hours ago, Igor said:

Try adding --keep-dirlinks parameter.

Thanks for the suggestion Igor.  Based on tkaiser's reply I won't be pursuing this method any farther unless you can think of easy modifications to the raspbx-update script to address the issues he mentions.  In lieu of this, I know you are a big proponent of mainly just backing up non-operating system changes but I want the whole enchilada .  My desire is to be able to burn a replacement so that in the event that my SD card becomes toast or my installation becomes so hosed that diagnosis is either too time consuming or just plain impossible (for me, anyway).  I'm guessing the use of DD would possibly be a route to go but I was trying to avoid copying the entire SD card each night.  Also, the complexities of designing something that would work on the fly is fraught with peril (as I've seen from posts over on some Raspberry Pi forums).  Are you aware of an existing method for doing this?  I currently backup my Raspberry's across the network to my NAS.  The NAS and network are 1 Gb but the Pi's alas are 100 Mb.  Unfortunately, so is the Potato (I thought I originally saw in the specs where it was 1 Gb but I just looked at their site and nope ).  Anyway, if you are aware of an existing method of on the fly backup of an entire Armbian based SD card I'm all ears.

[mokanman]

8 hours ago, tkaiser said:

The raspbx-backup script doesn't work with any SBC Armbian supports since it's designed for VideoCore SBC (that need a FAT partition with the closed source ThreadX on it). ARM SoCs work differently than VideoCore SoCs: here u-boot/SPL are written to the beginning of the SD card somewhere. It's not on a filesystem and therefore can't be copied with rsync that acts above the filesystem layer.

Thanks for the very informative response tkaiser.   It sounds like I need to find another approach.  My desire is to be able to burn a replacement so that in the event that my SD card becomes toast or my installation becomes so hosed that diagnosis is either too time consuming or just plain impossible (for me, anyway).  I'm guessing the use of DD would possibly be a route to go but I was trying to avoid copying the entire SD card each night.  Also, the complexities of designing something that would work on the fly is fraught with peril (as I've seen from posts over on some Raspberry Pi forums).  Are you aware of an existing method for doing this?  I currently backup my Raspberry's across the network to my NAS.  The NAS and network are 1 Gb but the Pi's alas are 100 Mb.  Unfortunately, so is the Potato (I thought I originally saw in the specs where it was 1 Gb but I just looked at their site and nope ).  Anyway, if you are aware of an existing method of on the fly backup of an entire Armbian based SD card I'm all ears.

[Igor]

17 minutes ago, mokanman said:

Based on tkaiser's reply I won't be pursuing this method any farther unless you

Thomas told you how things are. (I missed the part that you want to boot this backup copy) Nothing to add.

[tkaiser]

12 hours ago, mokanman said:

It sounds like I need to find another approach.

 

You just need to understand where the bootloader on ARM boards lives and how to transfer this to an image or another SD card. Usually all this stuff lives inside the 1st MB of the SD card so cloning the first MB with dd the first time should just work. But if then later u-boot updates are provided via our Armbian repo you won't get updates on your backup image.

 

Most probably the best idea is to merge the functionality present in our nand-sata-install tool with your backup script (since nand-sata-install has to take care about writing this bootloader stuff you can study there how it works -- it's the /usr/lib/u-boot/platform_install.sh include)

[mokanman]

21 hours ago, tkaiser said:

 

Most probably the best idea is to merge the functionality present in our nand-sata-install tool with your backup script (since nand-sata-install has to take care about writing this bootloader stuff you can study there how it works -- it's the /usr/lib/u-boot/platform_install.sh include)

Thanks for this.  I'll look into it and see what I can do with it.